Issue 1:
TLDR

If you render to a CubeCamera and

have renderer.outputEncoding != renderTarget.texture.encoding, at each render, for each material a .acuireProgram() will be called, which is slow. (Example) (covered by #19056)

have light-based materials, at each render for each material a new .initMaterial() will be called, which is slow due to .cloneUniforms()(Example) (covered by #13656, #14121 and now #19673)

Description of the problem

I noticed a severe performance regression when updating to latest THREE version (r117), causing my rendering times to increase from ~3ms to ~200ms. My scenes heavily rely on CubeCamera's, and I noticed an unusually high amount of material recompiles.

It appears that if you render a CubeCamera and you either

have renderer.outputEncoding != renderTarget.texture.encoding or

have a light based material in your scene

that lightsStateVersion property will flip/flop between the CubeCamera and main cameras renderStates, causing unnecessary calls to initMaterial. Even if the material does not need to be recompiled, the calculation of programCacheKey takes longer than usual, probably because it now involves cloning of the material's uniforms.

{
lightsStateVersion: 6,
materialProperties.lightsStateVersion: 5,
//^^^^^this causes the recompile^^^^^^

parameters.shaderID: "basic",
program: WebGLProgram {name: "MeshBasicMaterial", id: 81, getUniforms: ƒ, getAttributes: ƒ, destroy: ƒ, …},
program.cacheKey: "basic,highp,false,true,3000,false,false,3000,false,3000,false,,3000,false,false,3000,false,false,3000,false,false,false,false,false,false,false,false,false,false,false,false,false,0,false,,false,false,false,true,,false,,false,false,0,true,false,,8,4,false,0,0,0,0,0,0,0,0,false,1,0,false,0,false,false,0,0,false,false,false,3001,2,...",
programCacheKey: "basic,highp,false,true,3001,false,false,3000,false,3000,false,,3000,false,false,3000,false,false,3000,false,false,false,false,false,false,false,false,false,false,false,false,false,0,false,,false,false,false,true,,false,,false,false,0,true,false,,8,4,false,0,0,0,0,0,0,0,0,false,1,0,false,0,false,false,0,0,false,false,false,3001,2,...",
programChange: true
}

You can find an example here:

TextureEncodings

Light-based material

I didn't bisect the commit in question, but it appears to have happened between [r112,r115].

TextureEncoding

I don't expect all involved renderTargets to have the same encodings, but if that should be the case, I would recommend a corresponding warning message. On the other hand, IMHO the encoding of the renderTarget should not affect caching of the object's material at all? Although if it does, it might make sense to cache the material multiple times for each different encoding instead of flip/flopping between both encoding and causing a recompilation every time.

Thanks for investigating, please let me know if I can supply additional information.

Three.js version

Dev

r117

r116

[?] ....

r111

Browser

[?] All of them

Chrome

Firefox

[?] Internet Explorer

OS

[?] All of them

[?] Windows

macOS

[?] Linux

Android

iOS

Issue 2:
Description of the problem

Hi there,

I'm working on an application that renders the same scene twice in a single frame, once without post processing and once using EffectsComposer. The use case is basically an editor with a thumbnail preview of the scene with postfx.

This seems to trigger a shader recompilation, as has been discovered in a few other issues*. The advice so far has been to only use EffectsComposer and apply gamma correction as a pass in the effects chain, but this is pretty problematic for our use case as we use line rendering quite a bit for e.g. reference grids so losing hardware AA when using RTT results in unacceptable image quality.

A potential work around is setting the encoding of all render targets in the EffectComposer chain to use sRGB encoding, but I'm not certain what problems this might produce and feels brittle since there is no way to force every pass to use the correct encoding as far as I know. But results should still be correct, since my understanding of using sRGB encoding for a texture is that hardware then performs the appropriate conversions on reads/writes, so shaders can still run code as if the data was linear.

It seems that the necessary conditions to reproduce are:

sRGB encoding for renderer.outputEncoding

using two different cameras

RTT (EffectsComposer in this case)

Stepping through the code it seems specifically to do with the renderContext.state.lights version being different for each camera, which then triggers a check of the various properties against those when the program was created, which in will fail due to the different renderTargets and their encoding.

https://jsfiddle.net/BruOps/qy6o74pn/9/

Related:

#18893

#18699

#18355

#14121

Three.js version

Dev

r115

Introduced in r112

Browser

All of them

Chrome

Firefox

Internet Explorer

OS

All of them

Windows

macOS

Linux

Android

iOS

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

None