Cool PR

I have adopted the name IKModifier for the base class.

The justification can be that the names of the subclasses could be shortened versions of TwoBoneIKModifier3D, ChainIKModifier3D, and so on.
(not suggesting to rename these to that, clarifying just in case)

@ettiSurreal Considering the possibility that SkeletonIK may become available in Godot 5 and rename this to that, I assume the child classes can remain as-is.

Now:

@AThousandShips Thank you very much for the large amount of proofreading. I appreciate it, as reviewing this much must have taken a lot of time. Regarding line break spacing, it wasn't marked as outdated since diffs don't detect it, but I should have fixed it.

Thank god for this. LookUpModifier3D ain't it.

Let's combine this with master!

Thanks!

@TokageItLab Also, if SkeletonIK3D does get removed in the future, I think we should just keep "IKModifier3D" as this modifier's name. I think it works better than "SkeletonIK3D", is more consistent with other modifiers, and by that point users will be used to the name of the new modifier.

So I gave this a test, but the results seem far less stable than the existing SkeletonIK3D. I think part of the problem might be that there's no way to to make the IK target follow the rotation of the target, like the "Override Tip Basis" setting on SkeletonIK3D. Though I just turned that off and the rotation of the target still impacts the bones on SkeletonoIK3D, while with your IK modifiers the rotation seems to be completely ignored. With a long tentacle type object it just sort of freaks out and goes loopy. This is with the Fabrik one, which I would expect to behave most similar to SkeletonIK3D:

And here's with SkeletonIK3D:

So I gave this a test, but the results seem far less stable than the existing SkeletonIK3D. I think part of the problem might be that there's no way to to make the IK target follow the rotation of the target, like the "Override Tip Basis" setting on SkeletonIK3D.

@jitspoe As I mentioned in the description, we consider this to be the role of BoneConstraint rather than IK, so it is supplemented by #110336.

Another possible cause is when the change of the bone pose position or scale from the bone rest is included in the chain, but that needs to be supplemented by #111815.

FYI, in FABRIK, setting the Angular Delta Limit to 180 degrees (means no limitation) should make the rotation more similar to old SkeletonIK3D.

Try this:

test-different-ik.zip

I made a simplified example. SkeletonIK3D goes straight to the target, but the FABRIK3D meanders and twists around.

@jitspoe As mentioned above, meanders twisting is related to the angular delta limit.

The old SkeletonIK has no rotation limit per iteration, making it equivalent to setting an 180-degree angular delta limit.

And another difference between old SkeletonIK vs IKModifier3D's FABRIK is whether it is deterministic or not (IKModifier3D's FABRIK is non-deterministic).

As mentioned in #110120 (comment), resetting rotation every frame to the rest makes deterministic results. But this increases the number of calculations required to reach the result, depending on the angular delta limit, impacting performance. In other words, after resetting the rotation in the beggining of the each frame, if the angular delta limit is set too small with less iteration, the end bone will never reach the target, no matter how many frames are progressed.

However, in cases without the limitations mentioned above, such as setting the angular delta limit to 180 degrees, performance should not be significantly affected (since a large number of iterations is not required). Therefore, I believe deterministic behavior can be added as an option (I already discussed this with @lyuma during the review meeting).

@jitspoe @ettiSurreal @lyuma I sent a PR #112524 to add deterministic option, so you can test it.

Ok, setting the angular limit to 180 seems to make FABRIK work, but the Jakobian on just spazzes out like crazy, especially when it's near the max range or out of range.

@jitspoe The JacobianIK requires a small angular delta limit for stable results, so this is expected behavior (although the behavior outside the range might be stabilized a bit more). I assume we should document the recommended settings somewhere.

Edited:
Sorry, the gradient of the distance was not applied to angle correctly. I've sent the fix in #112573. Please test it if you can. It should be more stable as far as the end can reach the target. But in any case, large angular delta will cause the oscilation in JacobianIK.

Hi

I'm currently using Godot 4.6 dev 4, and I'm doing some tests for the new IKs system. While I'm pretty happy with the results when it comes to bones positioning, I don't see anything related to rotation (For example, rotating the hand of a player model in a way the entire arm will react to the changes of the hand) . I wanted to know if I'm missing something or if it's not in the scope of this PR in the first place.

Thanks ahead!

@YahelBaram That is considered more the role of BoneConstraint than IK, and we agreed it upon during the animation meeting.

For example, when the twist axis is +Y, the propagation of hand rotation can be fulfilled by transferring the +Y rotation of the hand to the +Y axis rotation of the LowerArm/UpperArm using BoneConstraint(Copy/ConvertTransformModifier3D). See also #100984, #110336 and #111367.

When propagating a child's rotation to its parent using constraints, a final constraint for canceling by self-references is required (as above image, processing the sequence that UpperLeg 0.25 of Foot -> LowerLeg 0.5 of Foot -> Foot -0.75 of Foot), but it should work as intended as long as the rotation does not exceed 180 degrees from rest.

Hi

I've been playing around with TwoBoneIK3D in 4.6 dev 4, and it's been working great so far. However, today I built master from commit 235a32a to test out #110336 and some other changes, and now TwoBoneIK3D logs repeatedly:

ERROR: The vectors must not be zero.
   at: Quaternion (./core/math/quaternion.h:140)

@TokageItLab have you tested TwoBoneIK3D against a more recent master? If it's not happening in your tests, let me know and I can put together an MRP.

I built Godot with:
scons platform=linuxbsd use_llvm=yes linker=lld debug_symbols=yes

System info:

System:
  Kernel: 6.8.0-87-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0 clocksource: tsc
  Desktop: Cinnamon v: 6.4.8 tk: GTK v: 3.24.41 wm: Muffin v: 6.4.1 vt: 7 dm: LightDM v: 1.30.0
    Distro: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble
CPU:
  Info: dual core model: Intel Core i3-7100 bits: 64 type: MT MCP smt: enabled arch: Kaby Lake
    rev: 9 cache: L1: 128 KiB L2: 512 KiB L3: 3 MiB
  Speed (MHz): avg: 800 min/max: 800/3900 cores: 1: 800 2: 800 3: 800 4: 800 bogomips: 31199
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660] driver: nvidia v: 580.95.05 arch: Turing pcie:
    speed: 5 GT/s lanes: 16 ports: active: none off: DP-1,HDMI-A-1 empty: DVI-D-1 bus-ID: 01:00.0
    chip-ID: 10de:2184 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X: loaded: nvidia
Info:
  Memory: total: 32 GiB available: 31.3 GiB used: 5.54 GiB (17.7%)
  Compilers: clang: 18.1.3 gcc: 13.3.0 Client: Cinnamon v: 6.4.8 inxi: 3.3.34

@x0r-b0t It seems to be an issue with the dynamic bone axis direction calculation by mutable_bone_axis. I'll take a look.

Edited:
I sent a fix as #113055.