Dragging files (textures, ...) is extremely slow to their respective fields in the Inspector.

[viksl]

Godot version

4.1 b2

System information

Windows 10, Nvidia GTX 1660Ti, Vulkan

Issue description

When you drag a texture to albedo or normal or anything for the standard material from the FileSystem to Inspector, or an HDRI texture to Panorama sky material and so on it's extremely slow depending on the texture size.

Extreme example is an HDRI texture which has tens or hundreds of megabytes which is not a great test case for actual games but it shows the problem well: https://polyhaven.com/a/little_paris_under_tower

Real test cases are mesh textures a 2k or 4k texture which are not that uncommon for 3D are slow to drag too.

You have to drag the file, wait seconds while holding a button waiting if it actually works or not and then if the file appears under your mouse cursor you can then drag it to the appropriate place. If you release the mouse anytime before it shows the drag which can take several seconds then it won't work.

I assume godot is loading the file in some way or so when you drag it to figure out what it is or something? Would it be possible to cache somewhere what the files are so the editor knows where they can and can't go and then do the final load/processing after it's been dragged, please?
I understand that for smaller files it's not an issue but 2k or 4k textures are nothing unusual for 3D games and it's taking forever to texture the models and so on.

Steps to reproduce

Download the link above, add a PanoramaSky and drag the EXR file into the panorama's texture field.
(I understand the EXR file is huge but that's the purpose of this report, to make sure no one misses how it works, the same issues happens with any regular texture, I assume not just textures but other file types as well)

Minimal reproduction project

I'll add one with the texture, I have to leave right now but wanted to log this in.

[BSSM7]

Same issue here. (Windows 10, Ryzen 5900x,Radeon 6950xt)

[Calinou]

This is due to how the drag-and-drop system works in the 3D editor viewport. cc @SaracenOne

HDRI texture import is expected to be slow due to the time it takes for VRAM compression of those textures to be performed. We could defer the VRAM compression to only occur after you're done performing the drag-and-drop operation, but it'll require importing the texture twice, which actually makes the whole process slower.

I assume godot is loading the file in some way or so when you drag it to figure out what it is or something?

When the cursor moves to the 3D viewport, the texture has to be loaded so it can be previewed on materials you drag the texture onto. (OpenEXR textures can also be used as material textures when you need high precision, not just HDRIs.)

I understand that for smaller files it's not an issue but 2k or 4k textures are nothing unusual for 3D games and it's taking forever to texture the models and so on.

Instead of using drag-and-drop, it's recommended to texture models in your 3D DCC, and then have materials be exported with glTF. Alternatively, you can export dummy materials and override them with BaseMaterial3Ds saved to .tres files in the Advanced Import Settings dialog. Also, consider using ORM textures in an ORMMaterial3D (instead of StandardMaterial3D) to speed up the texture assignment process. See also godotengine/godot-proposals#2316.

[viksl]

@Calinou yeah I do make dummy materials but I'm working what I have from various sources ;).
ORMMaterials would certainly be nice, I'll check if there are some tools to compile the textures together.
Even than it is just slow, with a 4k texture triggering the drag functionality takes seconds, I don't have the high end computer but it's also not a complete low end either, which makes it difficult to drag anything anywhere and even when you drag it keeps "lagging" for loss of better words while you drag it around - what is happening during the drag if the texture is already loaded at this point?
Btw I don't move the texture to the 3D viewport at all, below is my layout, I only drag it form the FileSystem to the Inspector straight:

Anyway, one thing is how slow it is to initiate the drag which is due to some processing, the second issues is that dragging itself is incredibly slow and freezes for moments all the time too.

I haven't tried it over the 3D Viewport yet :D.

I wonder if the processing could start after the file enters the 3D Viewport only instead of straight away and when it's assigned to a material slot instead of so early?

EDIT: I understand that at some point the processing will stall but right now it's stalling all the time during the whole operation, right now half the time I drag something around doesn't reach it's slot since it takes a while and getting info about the drag also takes a while and with the described above issues it just doesn't always land :).

[Zireael07]

1. Can't we defer stuff (whatever it is, not just VRAM compression) AFTER drop is done?
2. Have a switch off for the 3d viewport behavior for some textures (maybe a case by case setting, maybe per size cutoff?)

[viksl]

@Zireael07 I think it makes more sense to do it after rather than special cases for textures/file sizes. The cutoff would be heavily dependent on the user's HW so it would solve much for some people even with smaller file sizes.

I think something like processing only after it's been dragged feels the most fluid or have it cached somewhere. This way at least the user has confirmation that something should be happening and they understand what they/the engine are waiting for while keeping the drag&drop fluid without a break. Second issues is that it's "freezing" even during drag so there's something weird happening even after the file is processed (?).

[quackmarx]

I would like to re-open this discussion as the issue persists and at least in my experience is a fair annoyance whenever you deviate from using materials with packaged textures in gltf.

In my eyes, Godot supports alternative workflows because there can be many reasons not to use embedded textures; prototyping, fast texture iteration (eg. not having to re-package through another software to update a texture), custom materials with custom shaders, using 3rd party assets that you don't have control over without having to add the extra and definitely more cumbersome step of streamlining them in a DCC. Supporting these workflows but having the editor hang up when using them is in my opinion not ideal. After all, dragging and dropping textures to a custom material is an expected thing for a user to do in most engines these days.

Also, wait-time is expected during development, but I think the goal should be to never have this occur during UI/UX operations, but rather as a result. That to me is just good design.

I'm uncertain about the technical fix required, but I personally think that reducing hang ups in the editor is more important than a live preview in the viewport. Although hopefully there is a possible solution that encompasses both. This is perhaps a dumb question, but is it possible to do these things upon importing the asset so they are already cached during the usual wait-time?

[Calinou]

VRAM compression should be greatly sped up with #95915 in 4.4, so this should be much less noticeable now.