Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Irreversible broken Skeleton3D in editable children but new instances looks fine #91211

Open
ydeltastar opened this issue Apr 26, 2024 · 7 comments · Fixed by #91122
Open

Irreversible broken Skeleton3D in editable children but new instances looks fine #91211

ydeltastar opened this issue Apr 26, 2024 · 7 comments · Fixed by #91122

Comments

@ydeltastar
Copy link
Contributor

ydeltastar commented Apr 26, 2024

Tested versions

v4.3.dev.custom_build [c7f56d3]
Test with #91122 to avoid crashes while reimporting.

System information

Windows 10 - Forward+

Issue description

Skeleton3D can become irreversibly broken throughout the back-and-forth process of modifying the source model and reimporting when using Editable Children.

Probably, the issue happens when bone hierarch changes and the glTF reimports.
The button on the scene toolbar Skeleton3D > Reset All Bone Poses doesn't fix it. There are no properties in the inspector that I can modify or reset to fix it either.

New instances of the glTF look right.

image

Steps to reproduce

  • In the MRP, if you reimport x/x.gltf while actor_x.tscn is the focused scene in the editor, the skeleton doesn't fix.
  • If you reimport x/x.gltf while main.tscn is the focused scene or actor_x.tscn is closed, the skeleton looks fixed in the editor but broken at runtime.
  • If you reimport x/x.gltf while main.tscn is the focused scene and then change the focused scene to actor_x.tscn, it also fixes at runtime. This behavior is inconsistent. It can fix it or not, depending on the order in which you open the scenes, the number of iterations, or scene complexity. In my large project, for example, this or any other method I tried doesn't work and I'm stuck with the broken skeleton.

Minimal reproduction project (MRP)

broken-skeleton.zip

@ydeltastar ydeltastar changed the title Irreversible broken Skeleton3D in editable children but new instances looks fines Irreversible broken Skeleton3D in editable children but new instances looks fine Apr 26, 2024
@ydeltastar
Copy link
Contributor Author

ydeltastar commented Apr 26, 2024

By the way, test with #91122 to avoid crashes while reimporting. I added it to the description.

@ydeltastar
Copy link
Contributor Author

#91122 was required to reimport without crashes but it doesn't fix this issue.

@fire
Copy link
Member

fire commented Jul 24, 2024

Some fixes were done to the reload scene system, I'm not sure how it interacts with the bug.

@ydeltastar
Copy link
Contributor Author

Tested with latest. The issue still happens.

@akien-mga akien-mga modified the milestones: 4.3, 4.4 Aug 8, 2024
@SaracenOne
Copy link
Member

Okay, I'm looking into this now. It seems to be a complex edge case based around unique qualities of the skeleton node in relation to how the scene importer attempts to save and restore state. It seems that the wonky bone hierarchy has become embedded in the actor_x.tscn in the same fashion as any other modifiable property in scene. One key difference with the skeleton inspector is none of the direct bone properties are revertable (they probably should be though if those changes are serializable). This problem kind of has different levels to it though. By the rules of the system, those bone hierarchy changes actually SHOULD attempt to preserve these changes, so the behaviour observed when reimporting with the actor_x scene open seems the most correct.

Why these changes occur in the first place in another matter though and will require further investigation. May take some time and may require a bunch of special case code when dealing with armatures. It's supposedly just a natural occurance of modifying the base model with editable children open, right? In which case, this is all likely a byproduct of Skeleton3D all being contained as editable node properties when it probably should have been data and subject to similar safety checks I implemented for other imported types to prevent edits and corruption.

@SaracenOne
Copy link
Member

SaracenOne commented Aug 28, 2024

@ydeltastar
The two PRs I've referenced do attempt to address two aspects I've observed in with this issue:
The change to the reimport behaviour should resolve the reimported model appearing demangled (but actually is still mangeld in game or upon reloading the scene), and the reset support added to the skeleton editor will at the very least give the user a means to easily demangle a model without having to manually edit a scene file in a text editor.

The only issue that now remains is the underlying cause of the mangling which is mentioned as when bone hierarch changes and the glTF reimports. Could more information be provided about this? Ideally, from what I understand, the system shouldn't mangle the the skeleton, even with editable children is enabled unless the bone hierarchy was modified manually. The changes to the reimport system might fix this, but I require more information.

@ydeltastar
Copy link
Contributor Author

ydeltastar commented Aug 28, 2024

@SaracenOne I'm not sure how it happens. My only guess is that when I reparent bones. For example, the original skeleton was imported with an upper arm and a bottom arm. Then if I add an elbow bone between them and other similar edits, the skeleton could break when reimported.

As long as I iterated between Blender and Godot, characters eventually got broken when using this multiple editable children scene setup. Now I avoid this scene setup and it hasn't happened since.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants