Importing a large 400mb gltf/glb file crashes at 99%

[zedrun00]

Tested versions

4.4 dev3

System information

win10 21H2,Vulkan API 1.2.0

Issue description

Godot Engine v4.4.dev3.official.f4af8201b - https://godotengine.org
libpng warning: iCCP: cHRM chunk does not match sRGB
Vulkan 1.3.242 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 3080

ERROR: Basis [X: (1, 0, 0), Y: (0, 0, 0), Z: (0, 0, 1)] must be normalized in order to be casted to a Quaternion. Use get_rotation_quaternion() or call orthonormalized() if the Basis contains linearly independent vectors.
   at: (core/math/basis.cpp:725)
ERROR: FATAL: Index p_index = 620 is out of bounds (count = 620).
   at: operator[] (./core/templates/local_vector.h:177)

================================================================
CrashHandlerException: Program crashed with signal 4
Engine version: Godot Engine v4.4.dev3.official (f4af8201bac157b9d47e336203d3e8a8ef729de2)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] error(-1): no debug info in PE/COFF executable
[2] error(-1): no debug info in PE/COFF executable
[3] error(-1): no debug info in PE/COFF executable
[4] error(-1): no debug info in PE/COFF executable
[5] error(-1): no debug info in PE/COFF executable
[6] error(-1): no debug info in PE/COFF executable
[7] error(-1): no debug info in PE/COFF executable
[8] error(-1): no debug info in PE/COFF executable
[9] error(-1): no debug info in PE/COFF executable
[10] error(-1): no debug info in PE/COFF executable
[11] error(-1): no debug info in PE/COFF executable
[12] error(-1): no debug info in PE/COFF executable
[13] error(-1): no debug info in PE/COFF executable
[14] error(-1): no debug info in PE/COFF executable
[15] error(-1): no debug info in PE/COFF executable
[16] error(-1): no debug info in PE/COFF executable
[17] error(-1): no debug info in PE/COFF executable
[18] error(-1): no debug info in PE/COFF executable
[19] error(-1): no debug info in PE/COFF executable
[20] error(-1): no debug info in PE/COFF executable
[21] error(-1): no debug info in PE/COFF executable
[22] error(-1): no debug info in PE/COFF executable
[23] error(-1): no debug info in PE/COFF executable
[24] error(-1): no debug info in PE/COFF executable
[25] error(-1): no debug info in PE/COFF executable
[26] error(-1): no debug info in PE/COFF executable
[27] error(-1): no debug info in PE/COFF executable
-- END OF BACKTRACE --
================================================================

Steps to reproduce

1. create new project
2. importing glb file
3. 99% crash

Minimal reproduction project (MRP)

issue page upload file max size 25MB. so, download file look at this.

[fire]

validator.txt

The glb file from Unreal Engine 5.4.4 is not a valid gltf file.

https://github.khronos.org/glTF-Validator/

[fire]

Blender 4.2.3 cannot open the glb either.

blender.txt

[fire]

Godot should fail to import the file and not crash.

[zedrun00]

@fire

Blender 4.2.3 cannot open the glb either.

use Blender3.6 open file.
I have tried importing Blender 4 exported glb files into godot
Godot cannot be imported, but Blender 3.6 is normal

ps:

It looks like this can be imported
UE glb -> import Blander3.6 -> export glb -> import godot

[fire]

We cannot expect new developers to use a old blender version to import and the gltf file is invalid.

Can you try contacting Epic Games too?

[alecmeyer]

Godot should fail to import the file and not crash.

Hello. I'm a university student and first-time contributor to Godot. I am trying to create a PR for this issue.
I have reproduced the bug on my computer: Importing the file provided in the MRP to the FileSystem causes Godot to become unresponsive.
I am trying to find where the crashing exception is caused and catching it. Once I do so, I expect that it would be desirable to create a notification of some sort, but I do not know how.

Any advice on in which files of the engine to look for the crashing exception, or how to idiomatically create an error notification for the user? I'm in the process getting Visual Studio to do breakpoints in the project while I run it.

[alecmeyer]

I have observed that, upon importing the provided "quarry slate" glb file to a new project for the first time, it becomes unresponsive indefinitely. When the project is reopened, Godot scans the FileSystem and attempts to reimport the file. Only on the second time will Godot reach a breakpoint instruction and more obviously crash. It is worth noting that it takes a matter of minutes to reach said breakpoint instruction after the import arrives at 99% progress.

I'll describe the call stack at the moment of the crash for my own benefit and the benefit of any other collaborators reading.

editor_file_system.cpp
bool EditorFileSystem::_update_scan_actions()
line 947

At a very high level, the FileSystem begins reimporting files that need reimporting.

editor_file_system.cpp
void EditorFileSystem::reimport_files(...)
line 3158

At this moment, reimport_files[i].path resolves to "res://Quarry_Slate.glb". The FileSystem begins reimporting the provided glb file.

editor_file_system.cpp
Error EditorFileSystem::_reimport_file(...)
line 2765

resource_importer_scene.cpp
Error ResourceImporterScene::import(...)
line 3078

After importing each part inside of the glb file (ex. png texture files) and working until the onscreen dialogue reaches 99%, the editor begins generating the mesh geometry for the glb file.

resource_importer_scene.cpp
Node *ResourceImporterScene::_generate_meshes(...)
line 2643

resource_importer_scene.cpp
Node *ResourceImporterScene::_generate_meshes(...)
line 2574

I have no idea what is happening anymore.

importer_mesh.cpp
void ImporterMesh::generate_lods(...)
line 427

Resolving this square brackets operation eventually causes the breakpoint instruction in the local_vector.h header file, when unsigned integer j is out of bounds.

local_vector.h
class LocalVector
line 177

error_macros.h
CRASH_BAD_UNSIGNED_INDEX_MSG()

It appears that in the debug build of Godot that it will ignore the breakpoint instruction if allowed to continue, which will later cause an assertion presumably only present in the debug build to fail, causing Godot to crash and terminate as opposed to only remaining unresponsive.

The trouble with this breakpoint instruction is that it does not cause any exceptions to be thrown or cause any of the methods to return an error object with an error status as appears to be most conventional inside of Godot. My current plan is to add a check that (m_index) < (m_size) as in CRASH_BAD_UNSIGNED_INDEX_MSG(), but instead located in importer_mesh.cpp before each square brackets operation. If I find that the unsigned integer is indeed bad, I will throw an exception. I was thinking of adding a try catch block to where I have screenshotted inside of Error ResourceImporterScene::import(...), and if attempting to generate the mesh geometry results in an exception then I will return from import() with an error object with the appropriate error type and status.

I believe this will create an error notification on screen for the user to see. I am concerned that it will not totally revert the project to the clean state before the reimport operation was initiated. I am also concerned that this design does not fit the conventional pattern for throwing errors. Additionally, I would like to know what type of exception and what type of error object would be most appropriate.

Any feedback and advice is greatly welcome. I will begin working on a pull request very soon that implements the solution as I described to serve at least as a more formal starting point.

[alecmeyer]

I have authored a pull request at #99914 to begin addressing this issue.

[alecmeyer]

My pull request was insufficient to address this issue. To whom it may concern, I am no longer actively working on it.