R132 -> r133 darkened scene

[Usnul]

I’ve been trying to wrap my head around this for a while. Here’s what the scene looks like in r132:

and here’s the same in r33:

moreover, if I update all material in the scene with material.needsUpdate = true I get this:

Indicating that there’s some problem with how lights are calculated.

There are 3 light sources in the scene:

• 1 DirectionalLight that casts a shadow. White intensity 0.8
• 1 AmbientLight, white with 0.4 intensity
• 1 PointLight that’s black and has 0 intensity and 0 radius (distance)

There is an environment map on the whole scene, here’s how it’s loaded:

/**
 *
 * @param {string[]} paths URLs to faces of the cubemap
 * @returns {Promise<void>}
 */
async function loadEnvironmentMap (paths) {

    /**
     * 
     * @type {THREE.CubeTexture}
     */
    const cube_texture = await load_cube_texture(paths);

    cube_texture.encoding = sRGBEncoding;

    // generate pre-filtered cubemap
    const pmremGenerator = new PMREMGenerator(this.renderer);
    pmremGenerator.compileCubemapShader();

    const cube_rt = pmremGenerator.fromCubemap(cube_texture);

    // cleanup
    cube_texture.dispose();
    pmremGenerator.dispose();

    // assign environment
    this.scene.environment = cube_rt.texture;

}

I’ve tracked changes to envMap in r133:

Environment Maps from CubeCameras break on Standard Materials in r132+

but it doesn’t look like this applies to my case. Also, with the light setup that I have this level of darkness just doesn’t make sense. I spent many hours on this so far, any clues would be welcome.

For the sake of completeness, here r133 without the environment map (slightly darker still):

[looeee]

How does r132 look without the envMap? And can you compare the two with only the envMap to check whether the issue is with the lights or the envMap?

[Usnul]

Hey, thanks for checking in, here is 132 without envMap

just a tad darker as well

[looeee]

Hard to tell, but it seems like the envMap is probably correct then?

Seems unlikely that its the lights though since nobody else has reported anything like this when upgrading

[Mugen87]

Maybe related: We use EXT_sRGB with r133. Notice that many textures looked too dark in earlier three.js versions due to the GLSL inline decode. More information in this comment: glTF conformance: khronos-TextureLinearInterpolationTest · Issue #22483 · mrdoob/three.js · GitHub

Although this does not explain why your scene is darker with r133.

[Mugen87]

BTW: You can write loadEnvironmentMap() like so now:

async function loadEnvironmentMap (paths) {

    /**
     * 
     * @type {THREE.CubeTexture}
     */
    const cube_texture = await load_cube_texture(paths);

    cube_texture.encoding = sRGBEncoding;

    this.scene.environment = cube_texture;

}

[Usnul]

@Mugen87

Maybe related: We use EXT_sRGB with r133 . Notice that many textures looked too dark in earlier three.js versions due to the GLSL inline decode. More information in this comment: glTF conformance: khronos-TextureLinearInterpolationTest · Issue #22483 · mrdoob/three.js · GitHub

Although this does not explain why your scene is darker with r133 .

That’s a cool tip, thanks for that, I’ll investigate the possibility

[gloriousjob]

Are you using sRGBEncoding as your outputEncoding? I thought I figured out a fix for a problem I was seeing and found that it worked until r133, then worked in r135 and broke in r136 again. Looking at the merge that @Mugen87 referenced, I see that it enforces LinearEncoding when you use sRGBEncoding.

WebGLRenderer: Enable usage of `SRGB8_ALPHA8` again.

This might cause the problems that you’re seeing, as it does cause similar problems in the case I’m using.