You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not entirely sure they should be affected, but this surprised me a bit when refactoring A-Frame to automatically call .convertSRGBToLinear() on user-provided colors before passing them to three.js objects.
The text was updated successfully, but these errors were encountered:
Correct. The fog fragment follows the encoding fragment.
My recollection is that since the clear color is not affected by output encoding, and one would normally want the fog color to match the clear color, fog is not affected either. This can be changed, of course.
scene.background is not affected by gammaOutput=true
It should be. I implemented that in #15186 and #15187.
Can you provide an example to demonstrate where it is not working?
since ... one would normally want the fog color to match the clear color, fog is not affected either.
Ah, that makes sense.
Can you provide an example to demonstrate where [scene.background + gammaOutput] is not working?
Oh, I was referring to a solid color, like scene.background = new THREE.Color(0x4285f4). Now that I check the docs, it just sets clear color anyway, so that explains that. :)
I won't suggest changing this, then. As we discuss an API to replace gammaInput/gammaOutput, this behavior seems fine. I'll get inconsistent results when setting #4285f4 on fog vs on a material in the scene, but if anything I think that's an argument to reconsider how color inputs to materials are handled, rather than changing this.
I'm not entirely sure they should be affected, but this surprised me a bit when refactoring A-Frame to automatically call
.convertSRGBToLinear()
on user-provided colors before passing them to three.js objects.The text was updated successfully, but these errors were encountered: