Dragging a meshlibrary file hangs the editor for several seconds.

[GustJc]

Tested versions

• Reproductible in v4.3.rc3.mono.official [03afb92ef]
• Reproductible in v4.2.2.stable.mono.official [15073afe3]

System information

Windows 10 - Vulkan (forward+) - dedicated

Issue description

Trying to drag a meshlibrary file into a gridmap file makes the editor hang for several seconds depending on the size of the file. It also repeats the hang everytime you mouseover the slot dropbox.

If the file is small 30Mb~ it is manageble. Just feels clunky.

https://github.com/user-attachments/assets/d725e86c-c1be-43de-aaf9-16fdbd4f2425

Big it becomes unusable if the file is bigger than around 80MB

https://github.com/user-attachments/assets/62941182-9196-469e-b4c5-8db5628b9be4

---

I'm also not sure if the mesh library size is a bug itself. A mesh library of kenny platformer kit (142 files totalling 2 MB glb files) --> Meshlibrary of 9 MB But then using KayKit halloween bits (63 files totalling 1.47 MB) ----> Meshlibrary of 88 MB Both saved as .meshlib format.

It feels like a bug but it might also be the mesh library is horribly optimized for specific cases. From the size reduction of 130 MB to 5 MB with a simple .zip with the MRP, the Meshlibrary itself doesn't seem to use much compression to it, even using .meshlib or .res files.

Steps to reproduce

From the MRP:

• Open world.tscn
• Drag & drop "mesh_really_bad.meshlib" Result: Editor hands for several seconds
• Drag & Drop "mesh_bad.meshlib" Result: Lags and hands for a few miliseconds each time mouse over gridmap slot while holding file.

From a blank project:

• Save a scene file with lots of glb scenes children.
• Select export as meshlibrary.
• Add a gridmap to a new scene
• Try Drag and drop a meshlibrary file into the gridmap slot ( lags if file is 30MB, unusable at 80MB)

Minimal reproduction project (MRP)

Minimal project. bug-meshlibrary-drag.zip

[smix8]

All the original assets were imported with embedded material textures stored in a very ineffcient way inside the mesh surfaces instead of external. So everytime things are loaded / saved / changed half that stuff gets cache invalidated or needs to be rewritten dragging performance down. E.g. the major stutter on first load is because all the embedded textures are processed.

So what you need to do to fix the performance is use assets that have their subresources not embedded. Instead save the materials, shaders and textures to external resources.

[GustJc]

All the original assets were imported with embedded material textures stored in a very ineffcient way inside the mesh surfaces instead of external. So everytime things are loaded / saved / changed half that stuff gets cache invalidated or needs to be rewritten dragging performance down. E.g. the major stutter on first load is because all the embedded textures are processed.

So what you need to do to fix the performance is use assets that have their subresources not embedded. Instead save the materials, shaders and textures to external resources.

Oh wow... I didn't realized that was what was happening. I have my defaults as import using embeded basis to avoid having tons of duplicated exported textures for prototype assets. And only do proper external materials without duplication for final assets.

After re-importing the assets with extracted textures now the meshlib size went from 80MB to a normal 2.5MB, so no more lag or hangs now.

Thanks for that! I was seriously considering ditching the gridmap entirely if the meslib files were that uncompressed.

I guess this issue now could be changed for the lack of a warning message. Maybe saying to avoid using embeded textures for meshlibraries?

[smix8]

MeshLibrary is just a simple wrapper bundle for other resources, the issue is not specific to it.

The issue at core is a common user knowledge-gap with understanding the Godot resource system explained in the documentation here https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html

The rule for performance is to save everything you can to an external binary file (e.g. .scn, .res) outside of maybe the most mundane small things (or if you have a version control fetish a text format but those are slow to load/save with heavy assets).

I am not sure where this can be better placed so that this information reaches more new users before they fumble needlessly with performance in their projects.

What I mean by that is ... a lot of new Godot user projects suffer from poor editor gui responsiveness because users embedded their sophisticated themes and styles including fonts into scene files. Everytime the scene gets saved or reloaded all those resouces get reprocessed. Same for projects where users embedded their TileMap TileSets, or navigation meshes, or basically any resource that is data heavy or requires costly processing for the first time setup. All those projects suffer from poor performance that could be fixed by a simple "save as" button click.