IK rigged elbows have unexpected "laggy" or "jumpy" behaviour when animated

Question

To keep this both as short and as informative as I can:

The character I'm animating has bones in his arms set up like this: The lower arm has a regular IK constraint with a hand controller as a target (chain length 2), and the upper arm has a regular IK with an elbow controller as a target. Both targets are custom shaped helper bones.

(I didn't use the "pole target" function because it introduces undesired twisting, and doesn't fix this problem anyway)

• The problem I have is that the elbow updates in a weird way during animation, as if the IK calculations were struggling to keep up. When you go to any frame, the elbow first appears in a wrong position. And only after about a third of a second it snaps into correct place by itself. Sometimes the difference is minimal, other times the elbow faces the other way completely. Because it takes that short while for the bone to correct itself, mostly the wrong positions show instead of the good ones when the animation is played normally in viewport.

I've made 3 animated actions in total with this same armature, and 2 of them work perfectly fine. Only this one has this problem, which is why I have no idea what the cause could be. So far I've tried to fix this by restricting bone rotations, re-rigging the arms to use the pole target function, changing position of the elbow targets, disabling animation of the elbow targets, and also baking all of the animation. None of that has however solved the issue.

If anyone will be able to make any sense of this and tell me what's wrong, I will greatly appreciate it. The blend file can be downloaded from here: Blend file on Google Drive

Answer 1

So by messing around I managed to find my own mistake, and hopefully this answer will help others avoid it.

As is the standard with most IK setups, I have 2 bones in the place of the Hand:

1. The actual deforming Hand bone, which is child of the Lower Arm bone
2. A helper "Controller" bone, which occupies the same space as the Hand bone, but is not a child of the skeleton.

The Lower arm bone has a regular IK with the hand Contoller as a target, the deforming Hand bone then has a Copy Rotation constraint, so that it always has the same orientation as the hand Controller.

And here's where I made my mistake:

• I wanted to add some extra realism to my rig by adding a Copy Rotation constraint on top of the IK to the Lower arm, 0.5 weight and limited to Y, so that the forearm would twist slightly as the hand bone turns. But I've set the target of this constraint to be the deforming Hand bone, and not the Controller bone.

• That means the IK solver had to compute a lower arm bone, which rotation was dependent on the hand bone, which rotation was dependent on the controller bone. The rotation of the Lower arm basically had to be calculated in two steps, which is most likely what caused the strange Elbow desync as seen in that gif above.

I've discovered this by the elbows suddenly fixing themselves when I muted the lower arm's copy rotation constraint.

So the solution is following:

• As ironical as it is compared to the length of my descriptions, the solution was as simple as changing the target of the Lower arm's Copy Rotation constraint from the Hand bone to the hand Controller bone. That way the rotation for the lower arm is only calculated once, and the problem disappears.