Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fog and scene.background not affected by gammaOutput=true #15382

Closed
donmccurdy opened this issue Dec 6, 2018 · 2 comments
Closed

Fog and scene.background not affected by gammaOutput=true #15382

donmccurdy opened this issue Dec 6, 2018 · 2 comments
Labels

Comments

@donmccurdy
Copy link
Collaborator

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.

@WestLangley
Copy link
Collaborator

Fog is not affected by gammaOutput=true

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?

@donmccurdy
Copy link
Collaborator Author

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.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants