@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)
- Using
EffectComposer
with only 1RenderPass
:
- again, looks properly and respects
renderer.outputEncoding = THREE.sRGBEncoding
- Using
EffectComposer + RenderPass + CopyPass
:
-
The Problem Case:
DoubleGamma
appears andrenderer.outputEncoding = THREE.sRGBEncoding
is no longer respected.DoubleGamma
simply 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 copyPass
from initPostProcessing
function (line 147) to see changes.
https://github.com/DolphinIQ/compressed-cubetexture
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