[Issue] Editor isn't responding when (Re)importing large projects

[kisstp2006]

Description

Hi!

I ran into a serious issue after changing my project's VRAM Compression settings to the values shown in the image below.

After applying the settings, the editor prompted a restart. I restarted the editor as requested and waited for the reimport process to finish, but after a few seconds the editor became completely unresponsive.
I left it running for over ~1 hour, and the progress remained stuck at ~1%.

Steps to reproduce

1. Open an existing (larger 1-2 GB) project
2. Change VRAM Compression settings to the values shown in the image below
3. Restart the editor when prompted
4. Wait for the reimport process

Result

• Editor becomes unresponsive shortly after restart
• Progress stays at 1% indefinitely
• No crash, no error message
• Editor must be force-closed

What happens when reopening the project

When reopening the project:

• The editor starts normally
• After a few seconds it becomes unresponsive again

(see screenshots below)

Expected behavior

• The reimport process should complete
• Or at least fail gracefully with an error message instead of freezing

Additional notes

• I am not sure if this is related to the project size or the amount of textures
• The issue only started after changing VRAM Compression settings
• This makes the project impossible to open again without reverting settings externally

Related context

This issue might be related to the texture import pipeline and how VRAM compression is handled during reimport.

In Godot 4, texture importing received significant improvements thanks to the introduction of the etcpak library and a multi-threaded importer, which greatly improves import speed and responsiveness during heavy reimport operations:

"You should also notice a significant bump in textures import speed thanks to the etcpak library, and the new multi-threaded importer...."

Reference:
godotengine/godot#47370

Screenshots

VRAM Compression settings used:

Project opening:

Editor becomes unresponsive:

[Relintai]

What's the resoluton of that .png that is on the pic?

[kisstp2006]

The rusty_metal... one?
2048x2048

[Relintai]

I sourced a few pngs of that size they import fine for me, so there is probably something more specific to it.

Is there some error message that stands out in the console?

Also you could try removing the .import folder and have the editor reimport everything, maybe that could work.

[kisstp2006]

Additional findings

I launched the editor from the terminal to gather more information and got the following output.
These errors and warnings did not appear to cause an immediate crash, but I’m including them for reference:

Pandemonium Engine v5.0.development.custom_build.83f957768 - https://github.com/Relintai/pandemonium_engine

WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
at: ObjectDB::cleanup (core\object\object.cpp:2099)
OpenGL ES 3.0 Renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2
Async. shader compilation: OFF

ERROR: Condition "register_funcs.has(p_name)" is true.
at: VisualScriptLanguage::add_register_func (modules\visual_script\visual_script.cpp:2550)
ERROR: Condition "!shape->is_configured()" is true. Returned: Variant()
at: PhysicsServerSW::shape_get_data (servers\physics\physics_server_sw.cpp:112)
ERROR: Invalid RID.
at: (servers\rendering\rendering_server_raster.cpp:89)
ERROR: Condition "!p_rid.is_valid()" is true. Returned: nullptr
at: RID_Owner<class BodySW>::get (core/containers/rid.h:142)
ERROR: Condition "!body" is true.
at: PhysicsServerSW::body_attach_object_instance_id (servers\physics\physics_server_sw.cpp:607)
ERROR: Invalid RID.
at: (servers\physics\physics_server_sw.cpp:1204)

.import folder test

After the editor froze for the second time (for ~30 minutes), I deleted the .import folder and tried reopening the project.
Unfortunately, the issue persisted and the editor still became unresponsive during reimport.

Important observation

When launching the editor using a .bat file with the following contents:

@echo off
pandemonium.windows.tools.64.exe
pause > nul

The editor did not become unresponsive and successfully completed the (re)import process.

[Relintai]

"The editor did not become unresponsive and successfully completed the (re)import process."

Well I guess it's solved for now.

I'll assume it's probably either a threading related issue, and / or could also be an issue with SSDs or HDDs. I've seen sporadic issues during c++ compilation where files appear a bit later than when the build system checks for them, maybe something related to that.

Either way, I'll need to be able to reproduce this to see what's going on.

[kisstp2006]

I'm going to create a 3D project and upload it to GitHub. If I experience the same issue, I'll send the repository here, and then it may be easier to reproduce.

[kisstp2006]

I think there's something wrong with threading. In my project, when I enable multithreading, the game preview doesn't start in the editor; it just hangs on the Pandemonium logo. There's a video demonstrating this issue. I don't know if it's a known issue. I just thought I'd share it. And its might be related to the freeze ...

The video: https://youtu.be/JMnk_P_DXLs

[Relintai]

These are unrelated. They will be fixed.