WebGLRenderer: Remove inline sRGB decode.#23129
Conversation
I guess we can replace this later with a GPU approach? @kenrussell suggested creating a |
|
I've tried using render targets however this will making the code way more complex. The problem is that we can't trigger a render within Ideally, we don't have to go down this path and just use |
|
Thanks! |
and when is that, @Mugen87 |
|
see #22689 (comment) |
This reverts commit 05fc79c.
This reverts commit 05fc79c.
This reverts commit 05fc79c.
This reverts commit 05fc79c.
This reverts commit 05fc79c.
This reverts commit 05fc79c.
|
I'm not a big fan of the CPU WebGL1 fallback - doing that sRGB -> linear conversion into an 8-bit texture is likely to introduce pretty severe banding artefacts that wouldn't be apparent with the conversion in the shader. |
…e conversion This commit drops the support of pre-r137 (Jan 29, 2022) This compat code used to be required to compensate for changes in shader codes that happened in r137 mrdoob/three.js#23129 Because of the recent changes related to color spaces, we found that it's difficult to maintain the compat codes

Fixed #23109.
Description
This PR removes the sRGB inline decode in shaders. There are now new policies for sRGB workflows:
EXT_sRGBand the respective unsized formats. However, this only works by disabling mipmapping. IfEXT_sRGBis not supported, a (slow) CPU decode is performed.@sunag I've updated the node related code so that the examples still work. However, the node systems require some cleanup since methods like
fromDecoding()andgetTextureEncodingFromMap()should not be used anymore.