GLTFExporter: Mesh Names Not Updated in Exported GLB File

[ImoValentine]

Description

When renaming meshes in the Three.js Editor (e.g., from mesh_id7 to socks_mesh), the updated names are correctly displayed in the editor's UI. However, after exporting the scene as a GLB file, the mesh names in the exported file remain unchanged (e.g., mesh_id7, mesh_id11, mesh_id14) when inspected using tools like gltf.report. This issue prevents applications that rely on mesh names for functionality (e.g., texture mapping) from working as expected.

Steps to Reproduce
Open the Three.js Editor at https://threejs.org/editor/.
Import a GLB file containing multiple meshes. For example, I used a model (use.glb) with three meshes representing a jersey, shorts, and socks.
In the editor, select each mesh in the scene hierarchy and rename them:
Rename the first mesh to socks_mesh.
Rename the second mesh to jersey_mesh.
Rename the third mesh to shorts_mesh.
Verify in the editor UI that the names are updated in the scene hierarchy.
Export the scene as a GLB file using the editor's export option.
Open the exported GLB file in a GLTF viewer like https://gltf.report/ to inspect the mesh names.
Expected Behavior
The exported GLB file should reflect the updated mesh names in the meshes array of the GLTF structure:

socks_mesh
jersey_mesh
shorts_mesh
Actual Behavior
The mesh names in the exported GLB file remain as their original default names:

mesh_id7
mesh_id11
mesh_id14
However, the nodes array in the GLTF file does show the updated names (e.g., socks_mesh), but the meshes array does not. This discrepancy causes issues in my application, which relies on the meshes names to apply textures correctly.

Screenshots
Three.js Editor (Before Export): Attached a screenshot showing the scene hierarchy with the updated names (socks_mesh, jersey_mesh, shorts_mesh).
GLTF Report (After Export): Attached a screenshot showing the mesh names in the exported GLB file as mesh_id7, mesh_id11, and mesh_id14.
Environment
Three.js Editor Version: r176 (as shown in the editor UI on May 19, 2025).
Browser: Chrome 126.
Operating System: [Specify your OS, e.g., Windows 11, macOS 14, etc.].
Time of Issue: Reported at 10:38 PM SAST on Monday, May 19, 2025.
Additional Information
No errors appear in the browser console (F12 > Console) during the renaming or export process.
The issue can be worked around by manually editing the exported GLTF file to update the name fields in the meshes array, but this is not ideal for workflows relying on the editor.
My application (productselection.jsx) uses @react-three/fiber and @react-three/drei to load the GLB file and applies textures based on mesh names (child.name === 'socks_mesh', etc.). Due to this bug, the texture mapping fails unless I manually fix the GLTF file.
Impact
This bug disrupts workflows where mesh names are critical for downstream processes, such as texture application or animation. It affects usability for users relying on the Three.js Editor for quick edits and exports, requiring manual GLTF editing as a workaround.

Suggested Fix
Ensure that the Three.js Editor's export functionality updates the name fields in the meshes array of the GLTF file to match the names set in the editor UI, aligning them with the nodes names during export.

Reproduction steps

Steps to Reproduce
Open the Three.js Editor at https://threejs.org/editor/.
Import a GLB file containing multiple meshes. For example, I used a model (use.glb) with three meshes representing a jersey, shorts, and socks.
In the editor, select each mesh in the scene hierarchy and rename them:
Rename the first mesh to socks_mesh.
Rename the second mesh to jersey_mesh.
Rename the third mesh to shorts_mesh.
Verify in the editor UI that the names are updated in the scene hierarchy.
Export the scene as a GLB file using the editor's export option.
Open the exported GLB file in a GLTF viewer like https://gltf.report/ to inspect the mesh names.
Expected Behavior
The exported GLB file should reflect the updated mesh names in the meshes array of the GLTF structure:

Code

// code goes here

NA

Live example

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

Screenshots

Version

latest

Device

Desktop

Browser

Chrome

OS

No response

[donmccurdy]

However, the nodes array in the GLTF file does show the updated names (e.g., socks_mesh), but the meshes array does not.

The root of the issue is that the THREE.Mesh you're renaming in the editor doesn't necessarily represent a glTF "mesh". In glTF, unlike three.js, a mesh is a resource that can be attached to multiple nodes in the scene graph, and doesn't have position/rotation/scale of its own. Somewhat like three.js BufferGeometry. So given this naming in the Editor...

... the exported glTF will have a parent node named "my_group", a child node named "my_mesh", a mesh (unnamed), and a mesh primitive (unnamed).

If I modify the glTF and assign the name "x" to the mesh, the load that glTF back into three.js, there is no object in the scene graph named "x", because of #29768. Supposing that were resolved, and the name "x" were assigned to the mesh AND the node, one of those names would have a numeric suffix appended after loading back into three.js, because GLTFLoader enforces unique names on objects in the scene graph.

A fix for #29768 would make this behavior more predictable than it is today, but the mapping from three.js meshes to/from glTF meshes is not 1:1 in any case. I'd be hesitant to rely on round-trips through the editor to preserve unique names and structure as you're suggesting; a tool like Gestaltor (which represents the glTF structure 1:1) would be more reliable for that purpose. Hypothetically, an editor based on three.js and @gltf-transform/view would have the same ability.

Another possible workaround might be to assign .name or .userData on nodes, and consider any THREE.Group or THREE.Mesh under the target object to be "part of" that object.

Sorry it isn't a simple answer; I hope that offers some options!