WebGPURenderer: Fix instance meshes that shares the same count

[RenaudRohlinger]

Description
Currently, if two InstancedMesh objects have the same count, the second InstancedMesh incorrectly inherits the matrices of the first due to a shared cacheKey. This happens because the cacheKey is solely based on object.count.

Fix:
By incorporating the uuid of the InstancedMesh into the cacheKey, we ensure that each InstancedMesh maintains its own unique cache, preventing the unintended sharing of matrices.

Example for test if needed:
instance_webgpu_issue.glb.zip

This contribution is funded by Utsubo

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
685.1 kB (169.6 kB)	685.1 kB (169.6 kB)	+0 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
462 kB (111.5 kB)	462 kB (111.5 kB)	+0 B

[sunag]

I think the next step would be to use and improve referenceBuffer() for this instead of adding the buffer()/instancedBufferAttribute() directly as is done in InstanceNode. Then we could share the same NodeBuilderState.

[mrdoob]

Is object.count still needed in the cache key when we are adding uuid?

[RenaudRohlinger]

I think the next step would be to use and improve referenceBuffer()

On that note, I recently conducted extensive benchmarking on the WebGPURenderer. The performance significantly lags behind the WebGLRenderer mainly due to syntax such as this.node.value = value; in updateValue() of ReferenceNode.

For example, a slightly complex GLTF scene running with WebGPU takes about 10ms per frame to render:

More worryingly, it runs at 30fps with 6-7 frames dropped per loop in the WebGLBackend:

In contrast, the exact same setup with the WebGLRenderer takes about 3.5ms per frame (almost 3 times faster than WebGPU) and runs at a steady 144fps+:

So far, the culprit appears to be anything related to the use of custom setters/getters, such as this.node.value = val or return this.node.value in NodeUniform or similar cases:

I haven't opened an issue yet, as I want to fully explain the current problem and propose a solution. I'm openly brainstorming here, but a GLTF scene with 300-400+ meshes runs 2-3 times slower in both backends compared to the WebGLRenderer.

I don't think it's a major issue, just a necessary cleanup to catch up after building so much new content recently! /cc @sunag @Mugen87

[Mugen87]

I think it would be helpful to have some kind of webgpu_performance_* demo that allows us to measure the performance when rendering scenes with complex object hierarchies and many draw calls. Ideally we have the same example for WebGLRenderer so it's easier to compare both renderers.