Godot: Re-importing Collada deforms the mesh

[MilosLukic]

Godot version:
3.2 alpha 1

OS/device including version:
Windows 10

Issue description:
Reimporting .dae breaks existing scene (deforms mesh), even though the file stays the same. Everything is ok in 3.1, breaks in 3.2

Steps to reproduce:
I exported a mesh from blender using better collada (Blender 2.8), I import it in godot, open it, everything works perfect. I choose a new inherited scene, save it as .tscn, click "reimport" on the .dae, close the .tscn scene, it asks me whether I want to save - probably due to the reimport, save or don't - the result is the same. Close godot, open it (I think you can also just close and open the scene again, without restarting godot), open the .tscn scene and you get this beauty (it's supposed to be human):

Tried it in 3.1 and it works, so the problem is just in 3.2 alpha.

Minimal reproduction project:
Try it on the unit_2.dae in this project.
sample_project_reimport_bug.zip

[akien-mga]

I can reproduce it on Linux in the current master branch (3ca1296b8). Note that one should follow the steps to reproduce closely, simply reimporting the .dae is not enough to trigger the issue, one should also have an inherited scene open and save/close it.

[slapin]

This is caching issue. Importer gets instanced/duplicated object from cache instead of what it normally should get. Which is already maimed/modified by importing so mess happens (actually lots of kinds of mess happen) and this object does not relate to file on disk you import, so what kind of mess you get varies. Some people do not care about that at all.
ESCN and dae import are in the same boat (I think all importers are, but it is just not noticed).
You don't need to have inherited scene, any referene in project or just opening/closing is enough, just letting Godot know of object is enough whatever way that is. For clean session you need any resource reference in any of your tscn or tres files. This way the reimport will break immediately without any manipulation.

The only workaround is removal of .import directory for reimport to succeed (Godot exiting is highly recommended but sometimes not required if you're very agile with alt-tabbing or doing that from terminal then alt-tab to Godot, but did not work for me sometimes). This might work as solution as long as somebody gets interested enough to fix this bug if at all.

[rhossack]

Gonna add to this, as this bug has been tripping me up for the last few days.

If you import a glb file, Godot will automatically unpack its materials into separate files. If you then import another glb file that references materials with those same names, even if you changed those materials in this second file you're importing, it will not re-unpack them over the originals, as you likely intend; it will simply load the existing ones. So if you want to re-import fully, you have to delete not only the original file you imported, but any built-in files that Godot unpacked from it. This is in 3.2 alpha 2 btw.

[fire]

@rhossack That is a separate issue, can you make one for materials not being rewritten. I believe it's part of some workflows that materials don't change import, while the geometry changes.

[akien-mga]

I bisected this as a regression of #32275, CC @reduz @marstaik.

[akien-mga]

I bisected this as a regression of #32275, CC @reduz @marstaik.

The first bad commit in the PR is d81ddaf33ecddab1c83bc964b0bee4328b7f7b06.

I assume that this removal is what breaks Collada: https://github.com/godotengine/godot/pull/32275/commits/d81ddaf33ecddab1c83bc964b0bee4328b7f7b06#diff-f4c0a679eb47b23489fb761cc8c98821L179

[RevoluPowered]

I am having this issue with FBX too but in my case initial mesh is wrong on reimport, but clearing .import/ fixes the issue.

[reduz]

Although this issue should be fixed, you may need to manually erase the broken Skin resource in the MeshInstance affected in scenes that inherit or instantiate the dae.