Page 1 of 1

Apparent Armature Limits Bug?

Posted: Mon Dec 19, 2005 9:49 pm
by Bischofftep
I've been working on a new armature setup that takes advantage of the range of motion Limits function. I'm seeing a problem that I'm not sure if it's a bug or me doing something wrong. (MacOS X 10.4.3, Blender 2.40rc1)

Here is the rest pose of the armature:

Here it is after I grab the IK solver at the end of the "arm" and pose it. (Note that the range of motion limits work fine at this stage.)

The problem shows up here. When I grab (GKEY) the IK bone a second time after the first pose... it immediately jumps to this position.

This makes tweaking the pose, or moving to a new one from there, impossible. I have to clear rotations and start from scratch for everything. It looks to me as though the problem is that the IK bone immediately jumps to the end of its range of motion limit rather than everything staying right where it was until motion is read from the mouse & translated.



Posted: Mon Dec 26, 2005 3:32 pm
by osxrules
2.4 works fine for me under 10.4.3 with the bone limits. Do you have some keyframes set on the bones? That tends to snap things back into position.

More Info

Posted: Fri Dec 30, 2005 5:15 pm
by Bischofftep
Well, this seems to be something to do with the use of an IK Solver without a target. Perhaps I'm doing something very wrong.

If it helps, here is the .blend file I'm working on. Any thoughts on how I can improve the rig?

Click Here for the .blend file

Thanks for any help!


Posted: Mon Jan 02, 2006 4:47 pm
by osxrules
The IK target was missing. When it shows a red symbol, that means Blender can't resolve the constraint. To make the IK work, you just had to add a bone to the end of the foot and then make that the foot's target. The new bone at the end is your ik handle/target and it shouldn't be parented to any bone in the ik chain. You correctly set the chain length to 4.

What might have happened is that you named one of the mesh objects "Body" so it changed the armature name to "Body.001". I renamed it "Armature" in the file.

I wasn't sure if you wanted the foot to stay flat of the ground or have the tip on the ground so I did it both ways. I suspect it was the tip you wanted and that is in the second file. ... ...

One thing to note is that because the IK chain you set up has similar degrees of freedom on some adjacent bones, this means that the ik solver gives them equal freedom. Specifically, the z-rotation of the ball joint and the z-rotation of the upper leg bone. When I put the foot in front of the robot, it made the leg rotate at an angle.

To correct this, I put a stiffness value of 0.5 on the ball-joint z-rotation to give the upper leg more influence and that fixed it (set it to 0 with the foot in front to see what I mean). I also set a stiffness on the foot to keep the tip on the floor more often.

You can adjust the stiffness values as you like to get the walk you want.

Concerning the ik handle, I always leave them unparented from the armature because it stops the feet sliding. It also means that if you move the root bone of the armature (also called "Body") then it means the feet stay planted on the ground.

edit: I just noticed the bone roll angles weren't consistent. It's better to select the bones and hit ctrl-n to get the axes facing the same way before setting joint limits. Turn on bone axis display to help. Here is an updated version with the roll angles set on the front right leg: ...