When I switch from the standard encoding (probably Linear) to sRGBEncoding in a WebGL1 example, the minFilter and magFilter don’t seem to work anymore. This seems to have been introduced with version r137.
Example:
Look for the LOOK HERE command to comment out the encoding and see the difference.
And yes, I know the creation of the WebGLRenderer can be done differently, but this is just our use case, or at least a simplified version of it.
Cheers, Michael
Due to the introducing of SRGB8_ALPHA8 in WebGL 2, the WebGL 1 code path was limited in features.
When using a sRGB encoded textures, the engine tries to use the EXT_sRGB WebGL extension for decoding sRGB textures. However, mipmaps are not supported in this process which explains the loss in texture quality. A CPU side sRGB decode (without the WebGL extension) is very slow and even more problematic than the texture quality issue.
If possible, try to avoid the usage of WebGL 1 since sooner or later WebGL 1 support will be removed completely from three.js. If you still have to support WebGL 1 for some reasons, avoid using a sRGB workflow or stick to an older version of three.js.
Thanks for letting me know about that!
I completely get that WebGL 1 is an afterthought for you, but is there no way of keeping the existing features that were already working in WebGL 1 alive?
Still, thanks a lot for your answer!
Cheers, Michael
The change in behavior was caused by the removal of the GLSL (inline) decode of textures. This approach had some downsides. It produces wrong colors (they were too dark) and the related implementation in the renderer was complex. Removing this code path and relying on a SRGB8_ALPHA8 was the better alternative for the project. Sometimes it’s important to get rid of “old” stuff so one can focus on more important and future-proof topics.