Effect Composer Gamma Output Difference

@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 :face_with_raised_eyebrow:
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:

  1. Using only renderer:
  • looks properly and respects renderer.outputEncoding = THREE.sRGBEncoding (changes its color space accordingly)
  1. Using EffectComposer with only 1 RenderPass:
  • again, looks properly and respects renderer.outputEncoding = THREE.sRGBEncoding
  1. Using EffectComposer + RenderPass + CopyPass:
  • The Problem Case: DoubleGamma appears and renderer.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 :smiley:
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 :sweat: