Emissive color is not applied when using Bloom

[cx20]

Is your feature request related to a problem? Please describe.

I want to get the effect of Bloom similar to Babylon.js.
cx20/gltf-test#621

Describe the solution you'd like

I would like emissive color to be applied when the following glTF model is displayed.
https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/EmissiveStrengthTest

Describe alternatives you've considered

I have prepared a similar sample to compare whether three.js can achieve the same effect as Babylon.js.
Babylon.js Bloom Test : https://jsfiddle.net/cx20/ky0tcgr6/
three.js Bloom Test : https://jsfiddle.net/cx20/x1g2j07y/

However, in three.js, the emissive color set in the glTF model is not reflected, resulting in a white bloom effect.

Additional context

Library	result
Babylon.js
three.js

[donmccurdy]

For reference, from KhronosGroup/glTF-Sample-Models/2.0/EmissiveStrengthTest:

The basic emissive color of all the cubes is [0.1, 0.5, 0.9] in the glTF file, which is expected to undergo the usual linear-to-sRGB transfer before being shown to the viewer. The cube on the far left has no emissive strength extension (1x), and each subsequent cube doubles the strength (2x, 4x, 8x, and 16x).

Unfortunately, our post-processing stack does not implement HDR fully. I think you'll find that a lower bloomThreshold will display the emissive color in the glow on the left boxes up until the lowest component, R, is ≥1, after which point the glow is simply white:

Two problems here are straightforward, and I've attempted to fix them in a fork of the JSFiddle:

1. Tone mapping compresses the dynamic range of the RGB components (as it should) and clamps them to the closed domain [0,1] (maybe unnecessary?). Neither the compression, nor the clamp, can happen before a bloom pass — disable renderer.toneMapping. If you'd like to add ACESFilmicToneMappingShader or another tone map after the bloom pass, I believe that's OK.
2. The default WebGLRenderTarget used by EffectComposer has type: UnsignedByteType. This again clamps RGB components to the closed domain [0,1], and will break the bloom pass. Use a custom render target with type: HalfFloatType or type: FloatType instead.

https://jsfiddle.net/donmccurdy/jmfc9wgs/

Unfortunately the effect remains incorrect, for what I assume are limitations in the current post-processing stack. It would be interesting to see whether https://github.com/pmndrs/postprocessing has the same problem, though I haven't tried that experiment yet. /cc @vanruesc as FYI.

[vanruesc]

Looks as expected in postprocessing with a hard lum threshold of 1.0 and bloom strength 1.0:

[donmccurdy]

Thank you @vanruesc!

@cx20 I think I would use the postprocessing package for the bloom effect comparison here. Planning for HDR support in three.js post-processing and how that relates to the postprocessing package is a longer discussion.

[cx20]

@vanruesc Thank you for trying it.
The execution results you have tried are similar to the Babylon.js execution results and look good.
Is it possible for me to try that sample with jsfiddle?

@donmccurdy Thank you for clarifying the issue.
I kind of understand why the bloom effect is whitening.
I need to learn more about EffectComposer and tone mapping as I don't understand enough about it.

[vanruesc]

@cx20 https://jsfiddle.net/2b95fL1c/

[Mugen87]

This issue is fixed with r153 which contains a number of improvements of the FX pipeline (HDR, tone mapping and color spaces with EffectComposer are now properly supported).

https://jsfiddle.net/t1hyvjge/