@Mugen87 Oh so thats where
GAMMA_FACTOR comes from. That’s good to know, but unfortunately setting it to 2.2 only enforces the ugly effect, which I now believe to be gamma correction applied twice. However Im not entirely sure as its hard for me to trust the code at this point
Further in this post, I’ll refer to the undesirable second output as
DoubleGamma, for convenience sake.
So after a bit of testing, I believe I’ve found some strange behaviors:
- Using only renderer:
- looks properly and respects
renderer.outputEncoding = THREE.sRGBEncoding(changes its color space accordingly)
EffectComposerwith only 1
- again, looks properly and respects
renderer.outputEncoding = THREE.sRGBEncoding
EffectComposer + RenderPass + CopyPass:
The Problem Case:
renderer.outputEncoding = THREE.sRGBEncodingis no longer respected.
DoubleGammasimply occurs, regardless whether you set the encoding to sRGB or not.
(note: In the 3rd case
CopyPass can be any pass, be it FXAA or Bloom,
DoubleGamma still occurs. I’ve chosen to use
ShaderPass( CopyShader ), since, as far as I understand, it’s supposed to return exact copy of the previous pass, and it doesnt, so it presents the issue clearly)
@looeee Im using r112 - the newest and shiniest version of three.js
My postprocessing setup is the simplest possible.
Please have a look at the issue through this repo. I’ve updated it to use postprocessing. Uncomment
initPostProcessing function (line 147) to see changes.
PS. You will have to apply a tiny change from this PR in order to be able to create a
CubeTexture out of 6 compressed images.
Did something break during the last syntax update? Forgive my ignorance, but I feel like there is no way this behavior is intentional. The colorspace conversions are giving me a headache