You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
The current import workflow consumes too much time and storage.
For GLB/GTLF w/textures the Godot Editor is extracting textures to separate files by default. This is pretty fine - the loading time is fast, reusing textures is available OOTB. But extracting materials creates *.tres files with copies of these textures inside, but saved in text file in super inefficient serialization format - comma separated decimals in ascii for each byte. This slows down the editor, slows down loading and saving times, and makes editor crashing more often.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Reuse already extracted textures. That would solve described issue.
Avoid implicit saving binary files into tres files for any extracted/imported resource.
Show a warning message for big files (using a threshold configured in the editor settings, default set to 10kb).
Just let's assume that storing binary data in text files is wrong by design, and allow doing that only for special cases like storing PackedArrays of hand crafted meshes in the editor.
The above suggestions will solve other similar issues, like storing complex meshes in text files.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Already exported resources are well known for the editor. It should just reference them if they exist instead of serializing same assets into tres file.
If binary resources do not exist as a separate files, extract them first.
Warn user if the editor is going to store "big" binary data into text file.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No. This is core of the editor and is always used.
Note: the godotengine/godot-proposals#3443 proposal is handy but will not solve this one, because I'm talking here about default behavior.
Is there a reason why this should be core and not an add-on in the asset library?
As above.
The text was updated successfully, but these errors were encountered:
Calinou
changed the title
Saving materials from advanced import results in unexpected redundant storage of textures in tres files
Use extracted texture files when saving a mesh's material to a file in Advanced Import Settings
Feb 17, 2023
Hi, I transferred this issue to an issue on godotengine/godot, because it is a bug and not intended behavior.
I have a proposed fix at #75636: I expect it should be possible to address in 4.0.x for all newly extracted materials without breaking compatibility, so there's no need for a feature proposal.
Describe the project you are working on
Trying to make 3D demo scene with multiple assets
Godot 4 rc2
Describe the problem or limitation you are having in your project
The current import workflow consumes too much time and storage.
For GLB/GTLF w/textures the Godot Editor is extracting textures to separate files by default. This is pretty fine - the loading time is fast, reusing textures is available OOTB. But extracting materials creates *.tres files with copies of these textures inside, but saved in text file in super inefficient serialization format - comma separated decimals in ascii for each byte. This slows down the editor, slows down loading and saving times, and makes editor crashing more often.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Just let's assume that storing binary data in text files is wrong by design, and allow doing that only for special cases like storing PackedArrays of hand crafted meshes in the editor.
The above suggestions will solve other similar issues, like storing complex meshes in text files.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
No. This is core of the editor and is always used.
Note: the godotengine/godot-proposals#3443 proposal is handy but will not solve this one, because I'm talking here about default behavior.
Is there a reason why this should be core and not an add-on in the asset library?
As above.
The text was updated successfully, but these errors were encountered: