Modification stack to nodes

[fire]

Fixes: godotengine/godot-proposals#4863

Work in progress.

Using https://github.com/fire/godot-skeleton-modifier as the test project.

• Change to set pose.
• Use radians internally and degrees in the editor
• QA all the modifications by restoring the demo.
• Add a quality of life bindings of the bone suggestions.

---

List of issue possible closed by completing this implementation (SkeletonModificationStack issues related to 4.0):

• PhysicsBone3D and Skeleton Improvements #41322
• Freeze when opening SkeletonModificationStack3D.set_modification_count #54234
• SkeletonIK rotates bones by 180 degrees #54891
• Skeleton TwoBoneIK and FABRIK odd bone behavior #59554
• Skeleton IK 3D Interpolation #60180
• Fixed the TwoBoneIK Skeleton Modification having unintuitive rolls at different target positions #61259
• Ballhead constraints for FABRIK  #62003
• typing in bone_name field goes backwards in SkeletonModification3DLookAt #62876
• Fix backwards input in skeleton modification stack #63694
• Wrong behaviour SkeletonIk3d. Godot 4.0.alpha15 #65167
• Items in the SkeletonModificationStack2D behave incorrectly when attempting to remove them #65265
• SkeletonModificationStack3D stops working when made unique and local to scene. #67669
• All inverse kinematic options in Godot 4 seem broken #69752

[akien-mga]

CC @TwistedTwigleg

[fire]

@lyuma is working on the pr, so the current code isn't accurate. The proposal is still broadly accurate.

[TwistedTwigleg]

I don’t have the time to review the PR, but I agree with the general change (not that my agreement is needed - it’s all Godot code now 🙂 ). Moving it to nodes is MUCH closer to my original GSoC proposal and based on the work I did for my IK plugin for Godot 3.0, it is much more stable and easier to maintain as well. It should also make the workflow less confusing and reduce the number of clicks to get something working on screen.

Now just need to make those Bone3D nodes and have the modification nodes use the Bone3D nodes to fully fit the original proposal 😉

In all seriousness though - I think the general change is good. It will make the modification stack completely unnecessary and I think that is where a lot of the pain came from. It also will untie it from the Skeleton3D node code, making the modifications standalone.

Also, and I know I do not say this enough: Huge thanks to everyone who has continued to work on the IK stuff! I haven’t had any time and energy at all to work on much in spare time as of late and so I’m glad and thankful that others have continued to work on it and improve it.

[fire]

The git branches for this work is at https://github.com/lyuma/godot/tree/modification-stack-to-nodes-wip-full and https://github.com/lyuma/godot/tree/modification-stack-to-nodes-wip

[lyuma]

@TwistedTwigleg I've updated this PR with a mostly feature-complete PR. This is now a two-commit PR. The reason is I don't know how to preserve the rename metadata if I make it all in one commit since so much code was rewritten, so it makes review easier to do it this way.

I haven't tested anything at all. There is likely a lot that could have broken, but the existing implementation already has many features broken during alpha.

As a future PR, there are still some methods that I would like to clean up in BoneAttachment3D related to update order and the pose_updated notification. I also find the external_skeleton feature to be confusing.

Regarding what is in this update... I added documentation for all the new and renamed methods/members.

@TokageItLab I addressed the biggest feedback items.
I removed the following functions:

    void clear_bones_local_pose_override();
    Transform3D get_bone_local_pose_override(int p_bone) const;
    void set_bone_local_pose_override(int p_bone, const Transform3D &p_pose, real_t p_amount, bool p_persistent = false);

    void update_bone_rest_forward_vector(int p_bone, bool p_force_update = false);
    void update_bone_rest_forward_axis(int p_bone, bool p_force_update = false);
    Vector3 get_bone_axis_forward_vector(int p_bone);
    int get_bone_axis_forward_enum(int p_bone);

    Basis global_pose_z_forward_to_bone_forward(int p_bone_idx, Basis p_basis);

    // Modifications
#ifndef _3D_DISABLED
    Ref<SkeletonModificationStack3D> get_modification_stack();
    void set_modification_stack(Ref<SkeletonModificationStack3D> p_stack);
    void execute_modifications(real_t p_delta, int p_execution_mode);
#endif // _3D_DISABLED

get_bone_rest_forward_vector and global_pose_z_forward_to_bone_forward were migrated to SkeletonModification3D as helper functions.

I have made all calculations strictly based on get_bone_pose and set_bone_pose. Modification nodes do not depend on skeleton update or dirty and ignore global pose override.

I have removed bone_property_suffixes and used a const_cast to permit calling into GDScript from _validate_property. I would rather _validate_property be exposed the same way as get_property_list and others, but this should be good enough for now.

[lyuma]

I have decided to mark this as draft so that we can focus on other more pressing priorities for 4.0 beta, and fix some of the design issues with this that came up during testing.

For now, I will submit a new PR that marks all of the existing SkeletonModification resources and SkeletonModificationStack as Deprecated (planned to move to modification nodes) and unexposes some skeleton APIs only being used by the modifications such as "global_pose_z_forward_to_bone_forward" so it will be easier to remove

[fire]

We're also marking SkeletonIK to Deprecated too?

[ghost]

please add this issue too #54891

[Riteo]

What's the status of this PR? It'd be great to see this before 4.0 stable if this level of API breaking is accepted. Right now IK is unusable.

[RedMser]

I did some initial testing (after fixing merge conflicts) and the new system is a lot more intuitive to use and set up. Great work!

I only tested FABRIK in 3D so far, but it seems like the math is no longer correct, as the target node is not being reached anymore:

It looks like the algorithm results in global transform per bone, but is applied in local space (see how each bone rotates by 90°):

Let me know if you need a simple repro project.

[RedMser]

Not having any tip node/bone selected should not show a warning if automatic length calculation is successful.

[RedMser]

When creating a new FABRIK3D node, assigning skeleton, then assigning target node, I get following error + a crash on this line:

ERROR: Index p_index = 4294967295 is out of bounds (count = 0).
   at: LocalVector<struct Transform3D,unsigned int,0,0>::operator [] (B:\Godot\core/templates/local_vector.h:168)
[1] SkeletonModification3DFABRIK::execute (B:\Godot\scene\3d\skeleton_modification_3d_fabrik.cpp:549)

[lufog]

I guess this will close #65265 unless it's an inspector-specific bug.

(funny, on first attempt to send a message, I got the error You can't comment at this time., and on second attempt it was sent twice)

[lyuma]

I have repurposed this PR into #71137 and removed SkeletonModificationStack3D, so we will not port to nodes in time for 4.0.

2D modification stack works and will not be removed for now.

3D modification stack will hopefully return in a future 4.x in a different form. Stay tuned.