Ali Şahan Yalçın
DocsNested IK bones

How it works

Nested IK bones

Why the order matters when one IK bone hangs off another.

On the mannequin, one IK bone hangs off another:

code
1
ik_hand_root -> ik_hand_gun -> ik_hand_l, ik_hand_r

ik_hand_gun is itself baked, from hand_r. So by the time ik_hand_l is written, its parent has already moved.

Why that matters

An animation track stores local transforms. A bone ends up where its local transform puts it relative to its parent. If the parent moves and the child's local transform was worked out against where the parent used to be, the child lands somewhere neither of them intended.

For ik_hand_l under a baked ik_hand_gun, that error is the size of the right hand's motion, so the hand IK bones drift off the character entirely.

What the plugin does

Pairs are baked parents before children against a single working pose, so a child's local transform is worked out against its parent's baked transform rather than the one it started the frame with.

Source bones are read from an untouched copy of the pose, so a bone that has just been written cannot drag a later pair's source along with it.

The result is what the hierarchy was designed for: ik_hand_r sits exactly on ik_hand_gun, and ik_hand_l is stored relative to the weapon anchor.

INFO: The feet are not affected by any of this. ik_foot_root is never baked, so ik_foot_l and ik_foot_r always had a parent that stays still.