Editor: all colors/textures washed out in r102

[peteshea]

In latest version of three.js/editor materials & textures are appearing very washed out as if overly lit or gamma set way too high. This occurs both with lit materials like Phong and with BASIC material with no lights in scene.

Existing scenes we have been using for prototyping & testing lighting now have very washed out looking textures/materials as of version r102.

Three.js version

• [ x] r102 Editor

Browsers

• [x ] Chrome
• [x ] Firefox

OS

• [ x] macOS

Hardware Requirements (graphics card, VR Device, ...)

Mac Book Pro OSX 10.11.6
2.8 GHz Intel Core i7
Intel HD Graphics 3000 512 MB

[donmccurdy]

See #15858.

@mrdoob for gammaOutput=true to be a good default in the editor, we'll need more settings available or set by default:

• color maps should use sRGB encoding
• hex colors provided in the UI should be considered sRGB

Without that, I get different results dragging in a glTF model (which sets encoding correctly) as opposed to adding the texture through the Editor UI manually (which provides no option for this).

As discussed in #11337, I actually think both of the changes above would be beneficial to the library itself, not just the editor. But because that is a complex change, a temporary fix in the Editor – or reverting this change – may be needed.

[mrdoob]

@donmccurdy

I think I would prefer keeping the current change but also implement:

1. sRGB to Linear to sRGB conversion automatically in the UI.
2. Treat maps as sRGB by default (except normal, etc)
3. Script (either accessible from UI or pasteable in console) that fixes current scenes.

[donmccurdy]

Ok 👍

sRGB to Linear to sRGB conversion automatically in the UI.

I'd like to see this eventually be implicitly part of THREE.Color, perhaps with some colorManagement flag to disable it. When the user provides a hex code, it's implicitly sRGB, whereas fromArray() etc. would implicitly be linear. This will make it easier to match CSS colors and get more intuitive lighting values. The challenge is that some things are affected by gammaOutput (material.color) and others are not (fog.color, scene.background).

[WestLangley]

Just a few clarifications...

scene.background is currently affected by gammaOutput only if it is a texture.

gammaOutput will be renamed outputEncoding or outputColorSpace at some point.

[Usnul]

I got caught out by this too. Still trying to figure out the whole color space conversion flow. It's a bit of a nightmare so far, trying to adapt my old ShaderMaterial. Would be nice if there was a bit of an explanation on this. Here's my trouble, might help others:
https://stackoverflow.com/questions/55077909/faded-color-in-shadermaterial-due-to-encoding-frament/55081355#55081355

[makc]

@Usnul I assume RawShaderMaterial is not affected?

[Usnul]

@Usnul I assume RawShaderMaterial is not affected?

That's correct, I haven't seen this issue in RawShaderMaterial. In fact, I have only seen this when trying to write ShaderMaterial using shader chunks from three.js

[Mugen87]

@Usnul This is the related question at stackoverflow, right?

https://stackoverflow.com/questions/55077909/washed-out-color-in-shadermaterial

[Usnul]

@Mugen87 yeah, I still don't really understand what's going on there. My basic understanding is that there are interlocking hooks between pieces of standard material shader and the renderer itself so when you try to use them in a custom ShaderMaterial - things just don't work. One example is code injection for texture encoding mentioned in that stack-overflow post.