Closed vfig closed 2 years ago
This is likely because the import remapping for the file isn't included in the exported project for some reason. Does this occur if you instance icospher.obj anywhere in your project before exporting it?
The export works correctly if I do one of:
load()
the .obj mesh in _ready()
instead of preloading it.But it does not work if I do one of:
load()
-ed in the main scene's _ready()
(but not otherwise referenced)*.obj
to the "Filters to export non-resource files/folders" in the export dialog.Can confirm it's a very serious bug - also the textures seems to be affected too (and probably other resource types).
Duplicate of #56343, it's fixed in 4.0 beta 2.
What beta 2? O_o
Godot version
v4.0.alpha9.official [fc18891db]
System information
Windows 10
Issue description
A script uses
preload("res://icospher.obj")
to preload a mesh, before later putting it on a MeshInstance3D. When running the game from the editor, this works as expected. But after exporting the project (to a .exe in this case), the mesh fails to load, and the console shows the following errors:When writing the script, the autocomplete suggested the
"res://icospher.obj"
, so I inferred that was the correct way to reference the resource, even though the actual file loaded is buried in the.godot/imported
subdirectory.Using a hex editor, I can see the converted mesh resource is present in the exported .pck, but under the name "res://.godot/imported/icospher.obj-ea174b856465bb90893e7d64ea383677.mesh".
Steps to reproduce
Run the MRP from the editor. You should see the icosphere in the viewport.
Export the sample project (or use the .pck file in the MRP), and run it. No icosphere.
Minimal reproduction project
bug_export_noobj.zip