Spinning hand problem. What causes this and how to fix?

So i have an animation of three keyframes, for now. First and last keyframe are identical

The middle frame is made by copying the first pose, and using “Paste X-Flipped pose”. This sometimes results in the left hand being oddly bent back, sometimes not. i can’t seem to figure out exactly what causes that. When it does, i fix it by rotating the hand into the proper position on its local X axis

In any case, this usually happens


Here’s a slowed down version:

Notice the left hand spinning through the wrist. thats its X axis Clearly this shouldn’t be.

I can sometimes fix this problem by screwing around with the rotation of it. sometimes not. Right now it seems to be sticking.

What causes this, and how can i fix it? as far as i understand this isn’t gimbal lock. It seems to be the hand picking the wrong direction along the X axis, to spin. The longest direction oddly.

I just had a weird problem with a suddenly deforming elbow beyond a certain point, and it turned out to be the combination (sum) of bone roll and rotation taking it past the -180 degree point. Basically I think Blender is interpolating the wrong way around the circle there, which would imply that your angles imply that.

This is most likely correct, and yet still leaves me confused.

how can i fix the problem?

Well, I can’t see enough information in your shots to say what is going on. Lemme ask you this: what’s the rotation mode of the hand? Euler or Quaternion?

If you’re using euler rotations, I would say it’s gimbal lock. If you’re using quaternions (blender’s default for bones), then you can rule out gimbal lock.

Next, I’d say your bone roll might be your problem. In edit mode, does the z-axis of each hand match? Can you rotate one hand, copy the pose & paste the flipped pose and everything looks correct? If that works, then I don’t think it’s a bone roll issue, but I don’t know what the problem is…

If it’s not one of those two problems, post up the file so someone can take a look…


Warkirby, what I mean is I think you’ve got a rotation from (say) -170 to +170 degrees which should go the short route of 20 degrees total, but instead it’s going via zero, which is 340 degrees the long way round. What are the actual local rotation values on the keyframes?

Or maybe he’s just annoyed at having boards strapped to his hands and feet.

It is xyz euler now, but it was quaternion when this started happening. I’ve tried switching back to quaterniion and rekeying, didnt fix anything

They’re opposite hands on opposite sides of the body, i don’t think they should be exactly the same. In any case they look like this: (left top, right bottom)

Trying to upload my file, will post soon


I don’t think that’s happening here, but maybe im wrong. check the uploaded file in post #8

the boards are just for easy selection. the IK targets are parented to them, and the hands/feet copy their rotation

anyone there? ive uploaded a file, still needing some help

Something to try - have you copy/pasted the first position to get the last in a sequence? I have found that if you do this the bone will sometimes take the “long way round” rather than go back the way it came. This may be due to one hand rotating positively to get to a position and other rotating negatively to do the same effective move, bearing in mind it is actually a “mirror move” as far as the bone is concerned, since the X axis for each bone points the same way even if you mirror the bone. So for me, if I want to rotate a bone thus: Z axis 30, Z axis 60, Z axis 90, Z axis 60, Z axis 30, back to start, I would always keyframe the back to start as a rotated move rather than copy/pasted the first. You may find that a bone is crossing the -180 to +180 threshold, where these type of problems tend to occur. One way round this is to rotate the offending bone 180 degrees in Edit Mode, then keyframe a start position where you want it. For example to bones as hands pointing away from you, the X axis of both bones points to your right, rotate the right bone 180 in Y, the Z moves are now both positive to rotate the hands outwards using Z axis rotations.

Remember bones obey the Left Hand Rule as far as their axes are concerned, hold the fingers of your left hand with you thumb up, first finger away from you and second finger to your right. Thumb is Z, first finger is Y and second finger is X, all bones obey this rule, as do all axis systems (prove me wrong if you know better) and you can always align your hand to match the bone placement in your file to work out its axis orientation and therefor where positive and negative rotations are, positive is clockwise with the finger pointing away from you. You might like to build a simple armature to experiment with this principle until you fully understand it, rather than getting frustrated and seemingly annoyed, with a large, complex model to prove a point.

anyone there? ive uploaded a file, still needing some help

Also please note “Patience is a virtue - possess if if you can” - Piers Plowman, Geoffrey Chaucer, et al

Some of us live in a different time zone to you. We know this can be frustrating, but we have other things to do as well.

Cheers. Clock.

I think it’s that fangled rig where you’ve got the arm IK bone doubling as controlling the hand bone, so it’s not inherting the rotation of the arm (if you delete the middle keyframe, it doesn’t move at all) and doesn’t know which way to rotate to get where you’ve keyframed it. The IK bone shouldn’t be controlling hand rotation; it should just control the position of the wrist, and you should keyframe the hand separately.

I believe i understand what you mean. The cumulative movements of a sequence taking it so far from the start point that it goes around instead of back. But no, i belioeve that isn’t happening here. Because the sequence is only two frames long, and the change in the hand’s rotation between them is relatively minor, about 90 degrees on the local x axis

Okay here’s my findings so far:

for the first and second positions, the X rotations are approximately 42 degrees, and -56 degrees. So a total rotation of 98 degrees, which crosses over 0

Now on the timeline, the values for this are correct. The rotations ARE going the correct direction. It goes 41.7, 41.2, 39.6, 36.9 and so on, until it reaches the target. If i grab it and rotate it myself, this is unquestioningly correct.

As far as i can tell, the problem is entirely visual. it’s simply SHOWING the hand rotating in the opposite direction from where it’s actually going. The rotation values are interpolating in the correct direction. In order to get the visual effect of the hand spinning through the wrist, i have to grab it and rotate it the OTHER way up to 304 degrees.

However, if i keyframe 304 as the X rotation in the second frame (a value which is in the wrong direction) the hand will appear to rotate in the correct direction as it interpolates

I have no clue wtf is going on T_T

I give up with this thread…

I got it to throw some Dependency cycle errors to the console. A dependency cycle is a loop via parenting and/or constraints. It’s like a feedback loop. It makes bones go crazy (usually) or maybe just screw up sometimes in certain situations. It’s a major rigging flaw either way.

The console doesn’t always clue you in on these. It often takes something to trigger the error readout (move a bone, toggle a setting, etc.) and sometimes it will only do it for you intermittently. Always check the console while rigging/testing to hopefully catch any loop errors early on.

While analyzing the rig I noticed the forearm.L IK constraint had its Stretch feature off, but the forearm.R had it on. So I toggled the left one on. Sirens went off, printers shot out reams of paper, people went running and screaming. It was total mayhem. Well, not really (I miss the mainframes).

Enable that setting and look at the console. You should see “Dependency cycle detected” errors (2 of them) and the path of the loops, bone by bone. Now remember, that stretch setting alone isn’t the issue. It just caused Blender to finally recognize the dependency loops and print the error readout to the console.

I can’t say for sure that’s the cause of the flipping hand mystery but it probably is. The right arm seems OK. It’s not going haywire and no errors in console no matter what I did with it. If the left is rigged differently you may be in luck and an easy fix will sort it out.


I finally found the solution!

If you are using Quaternion rotation, The problem might be that the axis from the first frame is passed 180 degrees. There’s a simple neat trick you can do to change the path the rotation takes by just simply going to Pose > Flip Quats (Shortcut: Alt+F) while the affected frames are selected. Now the rotation path for those frames will be inverted into the path that you wanted.

Hope this helps!

Flip Quats