WebGLLights state and its hashing produce unintended material reinitialization

WebGLLights is used to store lighting state. WebGLLights.hash property is used to determine whether or not a material needs to be re-built.

https://github.com/mrdoob/three.js/blob/bd63a6cc8dd7fe11b530410fab9f67a9de359be8/src/renderers/WebGLRenderer.js#L1479-L1482

The way hash is built, it includes unique reference to WebGLLights instance: https://github.com/mrdoob/three.js/blob/efeb95f10790ab4755171584139d5344177f2713/src/renderers/webgl/WebGLLights.js#L319

constructor: https://github.com/mrdoob/three.js/blob/efeb95f10790ab4755171584139d5344177f2713/src/renderers/webgl/WebGLLights.js#L103-L111

this means that if you have 2 instances of WebGLLights and they are identical, except for id - you will end up rebuilding materials as you switch between these instances - inefficient.

Another problem with the current approach is that it is probabilistic, it’s possible that hash remains the same even though lighting has changed.

I propose following:

• remove id from hash calculation
• use a fast hashing function to compute 64bit hash(javascript number is IEEE 64-bit Float) instead of using a string
• pass more than just number of lights into the hash (as long as that makes sense).

[Mugen87]

The renderer has changed at various places since this issue was originally reported. The performance of initMaterial() was improved via #19673, render states (and lists) are only created per scene now (#20422, #21254) and light uniforms can now be updated without triggering initMaterial() via WebGLLights.setupView(). WebGLLights also performs no string concatenation anymore (#14588) and simplified the usage of the internal hash (#16581).

Overall I think it’s best to close the issue and open a new one if there are still performance issues.

[Mugen87]

Anyway, I have the feeling this discussion went a bit off-topic. Besides, the implementation of WebGLLights has slightly changed. It does not compare hashes anymore (materialProperties.lightsHash !== lights.state.hash) but just a single version number.

I actually like the idea of making initMaterial() faster when no shader compilation is required. Such optimizations might be valuable for #15047.