WebGPURenderer/NodeMaterial: material/shader rebuild when adding a second InstancedMesh with identical geometry & material

[AndreyPrakhov]

Description

Even when using the same material and the same geometry, adding a new Mesh or InstancedMesh causes the node material to be rebuilt and the shader to be recompiled.

This can be clearly seen in the profiler screenshots: as soon as the second object with the same geometry and material is added, a new material build and shader compilation happens, even though the resources are identical.

Reproduction steps

After starting the example, spikes will be visible in the profiler.

Code

// WebGPURenderer({ forceWebGL: true })
const geometry = new THREE.BoxGeometry();
const material = new THREE.MeshStandardNodeMaterial();

setTimeout( () =>{
    const mesh = new THREE.InstancedMesh( geometry, material, 100 );

    for (let i = 0; i < 100; i++) {
      mesh.setMatrixAt(i, new THREE.Matrix4().makeTranslation(i, 0, 0))
    }

    scene.add( mesh );
}, 3000 );

setTimeout( () =>{
    const mesh = new THREE.InstancedMesh( geometry, material, 100 );

    for (let i = 0; i < 100; i++) {
      mesh.setMatrixAt(i, new THREE.Matrix4().makeTranslation(i, 0, 10))
    }

    scene.add( mesh );
}, 3100 );

Live example

https://jsfiddle.net/eqLwa08c/3/

Screenshots

Version

^0.179.1

Device

Desktop

Browser

Chrome

OS

Linux

[Mugen87]

This is currently the expected behavior because we use the UUID to provide unique cache keys per instanced render item.

What is the use case for using two identical instanced meshes? Wouldn't it make more sense to consolidate and just use one?

[AndreyPrakhov]

Suppose the following situation: the instance has run out of matrix slots, and it becomes necessary to recreate a new mesh with a larger capacity. As a result, we end up hitting a freeze.

[AndreyPrakhov]

The following situation: the scene is divided into clusters, and each cluster contains instances. Instances can share the same geometry and materials, so it is expected that adding a similar instance (with different matrices) to a neighboring cluster should not cause extra slowdowns.

In WebGLRenderer, these cases are handled smoothly — once the shader is compiled, everything works fine.

By the way, a similar freeze can also occur with a regular mesh.

[Mugen87]

We have to refactor how instancing is implemented on node level so instanced meshes can share the same node builder state. That is a requirement for sharing the same shader. See #29066 (comment) for more details.

Let's use this issue to track the addition of this feature.