Mesh Library Export silently ignores some meshes

[danielbarla]

Godot version

4.1.2.stable.official [399c9dc]

System information

Godot v4.1.2.stable - Windows 10.0.22621 - Vulkan (Compatibility) - AMD Radeon RX 6800 (Advanced Micro Devices, Inc.; 31.0.14037.17019) - AMD Ryzen 7 5800X3D 8-Core Processor (16 Threads)

Issue description

Description

When using the "Scene -> Export As -> MeshLibrary" functionality, some meshes seem to be consistently ignored, while others are successfully exported. The editor does not seem to give any indication of any issues encountered, leading the user to think the export was perfect. In some cases, the resulting .tres or .meshlib file is mostly empty (containing only some boilerplate).

What doesn't work

The export itself is incomplete. In one case, when exporting a scene with 20 assets, I end up with a mesh lib with 12. In the repro case below, I have a scene with 1 asset which results in a mesh lib with 0 meshes.

How do you expect it to work instead?

• The assets I've encountered this with were very simple low-poly meshes from Kenney.nl; my expectation would be for the export to work in general.
• If there's any kind of failure during the export, I'd like to detect it at the earliest possible moment. Having a warning message show up in the debugger would be a good low-effort way to achieve this. Having an easy way to drill into the root cause of the failure (e.g. some inconsistency in the mesh data, etc), perhaps via a warning message containing further information about how to enable debug diagnostics for the export feature would be great.

Scale and scope

Unsure, but all GLB assets from Kenney's City Kit seem to suffer from this issue, while none of the GLB assets from their City Builder starter project seem to have this issue. Both the difficulty with the export itself and the silent way it fails are issues, though they are actually separate.

Existing / similar issues

The issue seems most similar to the following unanswered topic on ask.godotengine: https://ask.godotengine.org/152903/anyone-have-issues-exporting-meshlibraries-before . The main difference seems to be that in that question, the nodes have an icon indicating they are of type MeshInstance3d, while in my case (both in situations where the export works and where it doesn't), they are simply Node3D.

Steps to reproduce

(shortcut: use the attached repro project which has the two assets mentioned below)

Unhappy path

• Create a new Godot project
• Download the City Kit - Commercial by Kenney (the name "commercial" here means "commercial buildings", the assets themselves are free. At the moment the version of this asset kit is 13/10/2021.
• Find the Models/GLTF format folder inside the zip. Extract small_buildingA.glb to the Godot project.
• Create a new 3D scene
• In the above scene, drag the small_buildingA.glb from the "FileSystem" area directly as a child node of the root node.
• (At this point the model successfully shows up visually in the editor)
• Save the scene, then export if as a mesh library via Scene -> Export As -> MeshLibrary. Select a brand new filename, and hit save.
• Notice: the exported file does get created, but is ~80 bytes, and does not contain any assets.

Happy path

• Starting from the end of the above steps, remove the small_buildingA node from the 3D scene.
• Instead of the GLTF folder, this time find the DAE format and extract the small_buildingA.dae to the Godot project.
• Drag the dae file from the File System area to the root node
• Repeat the export (to a unique file name to work around any potential issues with merging of mesh libraries)
• Notice: the exported file is around 225KB, and if opened, actually contains 1 item.

Minimal reproduction project

MeshLibExport.zip

[smix8]

The problem is the node setup in the inherited scenes from the .glb files.

You start your mesh_lib scene with a Node3D and add your .glb file. Now that .glb file is just another Node3D , and inside is another Node3D, and .... the MeshInstance3D with the actual mesh is 2+ layers deep buried in other GLTF imported garbage.

The MeshLibraryEditor scene parser does not parse the entire node tree recursive so if the meshes are buried in garbage nodes they are not found. The parser only goes the first 2 SceneTree layers deep as is the setup visible in the documentation.

As soon as you remove the useless extra Node3Ds from the .glb file the export works again with no problems.

[danielbarla]

Thanks for the info and timely response @smix8! I can confirm that this seems to be the root cause, and the fix of editing the .glb and making the meshes root-level does seem to work.

Please allow me to reflect on the issue from the perspective of a new(ish) Godot user: the editor shows the mesh just fine, and the export also runs without complaint. Both the rule and the presence of the issue is hidden from the user - I can neither see that the .glb contains unnecessary nodes (from the Scene editor, that is - I'm just adding pre-made assets), nor that this would cause an issue. It's fairly surprising and perplexing behavior to troubleshoot. As such, I would recommend perhaps looking at this issue from a UX perspective rather than a "bug" perspective. Could it perhaps warrant a warning during the export? I'm completely OK with the issue being closed if you think not!

[jsjtxietian]

Related to #81850 , same problem for importing. @aaronfranke mentioned that #82792 (comment) we should allow MeshLibrary as one of the resource import options. I guess the export part should be changed too.

[aaronfranke]

Yes, see this proposal: godotengine/godot-proposals#7494

I hope to get this done for Godot 4.3. In the meantime, I have some PRs open that work towards this goal. The stepping stone PRs have not been merged yet, so this is not done for Godot 4.3.

Export could be considered a different issue, but it's also heavily related, so I might do that right after.

Also note: In Godot 4.3 and later, once #79316 is merged, you will be able to select other root node modes at export time, including the ability to treat the scene root as the scene name instead of a node in the scene.