GLTF: Don't duplicate textures when importing blend files

[demolke]

blender imports will always start with res://.godot/imported because we first convert the blend to gltf, store it in res://.godot/imported and run the import from there, so resources linked from blend files end up with duplicate textures after #96778

Use simplify_path to differentiate between resources actually in the imported folder vs resource relative to GLTF in imported folder.

Introduce a new state where the resource exists on the disk but has not been imported yet.

Fixes: #98932

[fire]

I think this makes sense, but what was the original problem being solved?

[demolke]

This is the issue #96778 (comment)

After #96778 all textures imported from blend files will get duplicated in the res:// folder.

[demolke]

Ah, me and github - I've uploaded only a part of the change, let me switch it to draft while I try to fix it.

[lyuma]

Please file a new issue for the bug, with an attached reproduction project, and link to that bug in this PR.

A link to a PR comment makes it difficult to have a meaningful conversation on this issue, and there is enough nuance with this issue that I don't want to merge a PR without an issue

---

I'm missing some information here. For example, the issue purports to affect blend files, but the PR here only touches gltf_document code, which means that the issue must be reproducible from a standalone gltf file. I want to understand what cases are being changed.

Generally speaking, there are two cases for gltf:

1. either the images are embedded, in which case they are extracted with the model name prefixed (texture inside model.gltf is extracted to model_texture.png), or
2. the images are referenced externally from the gltf file, in which case, they are not extracted since they are external references. In this case, model.gltf would directly reference texture.png which already exists.

This PR is hinting at a possible third case, which I do not understand, in which model.gltf (or model.blend) references texture.png but somehow the gltf_document code also extracts model_texture.png.

I am skeptical about this fix, and we should also keep in mind that when blender gltf exports embed a texture file, there is sometimes a reason for it. I believe that, for example, blender will at times make modifications to the texture and embed it to comply with the gltf spec or to handle certain shader nodes.

Found places that need improvement.

[demolke]

The part about blender is somewhat significant, because .blend will get converted to .gltf and placed in res://.godot/imported - something the #96778 considers as impossible to import

godot/modules/gltf/gltf_document.cpp

Line 4089 in 77d6283

if (!p_base_path.begins_with("res://.godot/imported")) {

so what happens we fail this check because texture linked from a blend file is considered as placed in imported folder and we fall through to writing it to the disk.

(It's very much possible to trigger this if you call gltf import methods yourself with paths relative to res://.godot/imported but no one is probably doing that.)

https://github.com/user-attachments/files/17640095/nonembed.zip

So on disk it looks like this before the image processing

.godot/imported/model.gltf
assets/model.blend
assets/texture.png

The code above will get res://.godot/imported/../../assets/texture.png dismisses it as unimportable, writes the data to the disk res://assets/model-texture.png and imports that.

This PR is hinting at a possible third case, which I do not understand, in which model.gltf (or model.blend) references texture.png but somehow the gltf_document code also extracts model_texture.png.

Yes, exactly - that's the behavior #96778 introduced.

I'll port it into an issue - #98932

[demolke]

The change

• does uri.simplify_path(); to make uri absolute
• removes the p_base_path.begins_with("res://.godot/imported") check - I think it's meaningless - ResourceLoader will tell you if the texture has been imported or not
• if I've would have left _parse_image_save_image as is, all un-imported textures that have valid uri would get read from the disk and then written back for no reason

[aaronfranke]

In the future, please make a new branch for your PRs, instead of using master.

Thank you for working on this. It makes sense to separate the must_write and must_import booleans. And yeah, I completely forgot to consider the case of res://.godot/imported/../../ which results in things being not inside the res:://.godot/ folder after all.

However, this doesn't seem to work in practice. PR #96778 was designed to be a GLTF-only PR to make way for PR #96782.

With only PR #96782, the unpacking works correctly (the GLTF material points to the imported texture):

With both PR #96782 and this PR, it errors and does not extract (the material's texture is directly loaded an image):

The test file here is the MRP in issue #82455 with "Materials -> Unpack Enabled" set to false (this option should be renamed to "Unpack Originals" in the future).

[demolke]

@aaronfranke thanks for the pointer. I only tested it with embedded textures and unpack enabled, so will take a look.

[demolke]

I think I've addressed all the permutations. Added a couple of tests, but they do not capture the full breadth of the problem (that would require blender installation during unit test) - only some of the basic use cases. I am not very happy with them - they write to disk, so are not idempotent. I'm wondering if to include them at all. It would be nice if we had memory backed res:// support.

One interesting thing to note is that there is a race condition in _parse_image_save_image with "Materials -> Unpack Enabled" set to true (i.e. the implicit default) even before #96778. On first run the blender gltf export will create textures directory which will not be scanned by the time we try to parse it, so EditorFileSystem::get_singleton()->reimport_append will not find those files. On the import we will load the textures directly and on the second re-import the folder will be found and the resource linkage succeeds.

[demolke]

Thanks for the review and the suggestions.