GLTFLoader: meshes with multiple primitives and multiple instances have non-unique name

[Mirei3D]

Description

The GLTF loader (to my understanding) attempts to assign unique names to all nodes it parses.
However I noticed that duplicated names can appear in meshes created for nodes in certain cases. When a GLTF mesh has multiple primitives the GLTF loader will create one THREE.Mesh per mesh primitive under a THREE.Group. When instantiating this GLTF mesh multiple times, the THREE.Group seems to usually receive a unique name, but the meshes under the group have the same names in each instance.

This can be problematic in software that manipulates parts of 3D scenes based on mesh names (e.g. user selected mesh names).

I'm not sure what the intended behaviour from the THREE.js maintainers here is, so apologies if this should have been a feature request.

Reproduction steps

1. Open https://threejs.org/editor/
2. Import this GLB test file: MultiInstanceMultiPrimitiveCube.glb.zip
3. Inspect the scene hierarchy, particularly the mesh names under Cube and Cube001

Code

// code goes here

Live example

• jsfiddle-latest-release WebGLRenderer
• jsfiddle-dev WebGLRenderer
• jsfiddle-latest-release WebGPURenderer
• jsfiddle-dev WebGPURenderer

Screenshots

Version

r171

Device

No response

Browser

No response

OS

No response

[mrdoob]

The GLTF loader (to my understanding) attempts to assign unique names to all nodes it parses.

@donmccurdy Not sure that's true?

[donmccurdy]

Assigning unique names to each node has been the intention, yes. Originally this was done because animation track assignments would require it. Since then it's become necessary for R3F's gltfjsx and Threlte's gltf as well, although they might have the additional option of pre-processing the model so that names in the source file are already unique and don't require changes from three.js.

Same issue reported in:

• GLTFLoader Animate Wrong Mesh #27051

More comments in:

• GLTFLoader: assign unique names to children of cloned refs in _getNod… #30091 (comment)