Add BoneTwistDisperser3D to propagate IK target's twist

[TokageItLab]

Add BoneTwistDisperser3D.

As commented in #110120 (comment), using BoneConstraints can provide a solution for propagating twist to the parent to some extent. However, in cases where the twist axis does not align with the XYZ basis, the solution is not as straightforward. Furthermore, since the canceled twist must be applied to the target itself, it is not easy to use for not advanced users.

This allows them to automate these processes by creating a chain. Of course, it can be used even without IK.

dp.mp4

ik_test_match_target.zip

[TokageItLab]

There is request for a curve editor from @lyuma, so now it is implemented.

Thereby, twist weight has been changed to twist amount without normalization. Also, it has been added to the documentation that the auto assigning amount except for DISPERSE_MODE_CUSTOM are monotonically increasing.

Whether twist_amount is read-only depends on the existence of the Curve resource.

---

Can be considered the future follow up

The horizontal axis of the curve currently represents the index rather than the bone length, but since this implementation is the same as SpringBoneSimulator3D, it could be improved as a follow-up in the future .

The same applies to improvements for extracting twists greater than 180 degrees; this should be fixed at the same time as ConvertTransformModifier3D.

[TokageItLab]

As I've mentioned several times before, the IKModifier itself only changes the joint placement/rotation using only Swing , without Twist. So these modules for the twist may become that IK enhancement as option.

For example, it should be interesting to see how the behavior of IK can be quite varied due to configuration differences like the following:

---

• Simple non-deterministic FABRIK:

simple_fabrik_and_target.mp4

---

• Pre-twist the root using aim
• Further pre-twist the target and then sparse
• Finally, performing deterministic FABRIK can stabilize the bend direction to some extent

combination.mp4

ik_combination.zip

In other words, a rich IK component has these nodes as member options (like bool to call internal function) for IK.

However, since these calculations are also useful outside of IK, having them as separate nodes makes sense IMO. Especially when using custom IK, reusability is a big benefit. Although we will need to prepare several tutorials and demos later on - or we can provide a wrapper component as an addon to automate these configurations.