Skip to content

Conversation

@Mugen87
Copy link
Collaborator

@Mugen87 Mugen87 commented Sep 15, 2025

Fixed #31903.

Description

When two meshes with shared geometry and material share the same node builder state, rendering ends up wrong because the second meshes uses the (referenced) morph target influence values from the first mesh.

Unless this is somehow fixed on the node side by not coupling the uniform buffers directly to a specific mesh, RenderObject must make sure to return different cache keys for such meshes.

There was also a bug in NodeMaterialObserver that did not update the cached morph target influence values to detect changes which is fixed with this PR as well.

@github-actions
Copy link

📦 Bundle size

Full ESM build, minified and gzipped.

Before After Diff
WebGL 338.24
79.14
338.24
79.14
+0 B
+0 B
WebGPU 584.32
161.46
584.41
161.49
+94 B
+28 B
WebGPU Nodes 582.93
161.22
583.02
161.25
+94 B
+28 B

🌳 Bundle size after tree-shaking

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

Before After Diff
WebGL 469.7
113.74
469.7
113.74
+0 B
+0 B
WebGPU 653.67
176.96
653.77
176.99
+94 B
+32 B
WebGPU Nodes 607.78
166.14
607.88
166.16
+94 B
+27 B

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Sep 15, 2025

@sunag I'm not sure but below code does not seem to work as expected:

influence.assign( reference( 'morphTargetInfluences', 'float' ).element( i ).toVar() );

If this should make sure to use the morphTargetInfluences data from the current mesh, something else is broken. The UBO is not correctly updated and always uses the data from the "first" mesh.

@sunag
Copy link
Collaborator

sunag commented Sep 15, 2025

If this should make sure to use the morphTargetInfluences data from the current mesh, something else is broken. The UBO is not correctly updated and always uses the data from the "first" mesh.

The verification is failing in NodeMaterialObserver.containsNode() because the system is not yet unified when it comes to binding updates, code refactoring should follow this path soon #26673 (comment) This should not happen if the user uses a non-built-in node (custom) in material.

As soon as I finish this inspection I will pay attention to this, the tool should be useful for this refractoring.

@sunag sunag added this to the r181 milestone Sep 15, 2025
@sunag sunag merged commit b641d6d into mrdoob:dev Sep 15, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Objects that share geometry but have different morph value will not render correctly.

2 participants