2
$\begingroup$

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. WeirdIK 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

$\endgroup$
  • $\begingroup$ Just FYI, I just opened your Blend file on my laptop (Win7) which has the slowest processor ever and there's absolutely zero lag. It runs at 24fps all day long. $\endgroup$ – bertmoog Aug 1 '17 at 1:54
  • $\begingroup$ Well you are not wrong, the fps isn't the problem here. The animation runs at 24fps for me as well. The problem I have is that the IK that doesn't behave as it should. As seen on the gif above, the elbows jump around even though they shouldn't be, going first to a wrong place when you enter a frame, and then snapping back into the correct place without any sort of input. But I've explained that in the text... My apology if it wasn't clear enough. $\endgroup$ – Kochich Aug 1 '17 at 20:40
  • $\begingroup$ No, it's my fault if anything's misunderstood. I was just looking at your gif and seeing that there's a stutter step that I can't replicate, even by stepping through frames. How were you able to capture that in the gif? If it was some kind of calculation lag, I just wanted to let you know that it was running smoothly on my machine, just so you would have a troubleshooting data point. $\endgroup$ – bertmoog Aug 1 '17 at 21:53
  • $\begingroup$ The gif was captured by "Active Presenter", kinda regular screen capture software, it shows quite exactly how the elbows behave for me. This is interesting, if the issue doesn't appear for you with the same file, then it might be some kind of a glitch on my side. $\endgroup$ – Kochich Aug 2 '17 at 6:41
  • $\begingroup$ I have managed to find the source of the problem, This IK glitch seems to be caused by a second constraint that I have on the lower arm bones: There is the main IK constraint, and then I also had a Copy Rotation contstraint, so that the bone's roll would partially follow the hand to avoid twisting. With this constraint removed, the bones no longer behave like on the gif. $\endgroup$ – Kochich Aug 2 '17 at 12:56
3
$\begingroup$

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.
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.