Newbie flummoxed by hand-rigging problem

Hi,

This looks like a great site, and I’m excited to be getting familiar with Blender, which seems like a terrific piece of software. I’m having problems rigging a character right now and I hope somebody might be able to help.

Basically, I am rigging two hands. I am using IK solvers and NULL bones at the finger tips, which I have constrained to copy the locations of five target empties for each hand, so that I can position the fingers while in object mode. Further, I have an empty set up at the wrist to rotate the hand/bend the wrist, and I have the main hand bone constrained to copy the rotation of that empty (that empty in turn is constrained to copy the rotation of the forearm, by default). I have another empty set up at the wrist to control the IK solver for the arm. The wrist-rotation empty is a child of the arm-location empty. Lastly, the finger empties are all children of the rotation empty.

This seems to be working fine for the left hand. When I bend the arm using the IK solver at the wrist, the entire hand follows along nicely.

On the right hand, which I thought I had set up the same, the fingertip IK solvers do not fully follow the fingertip empties when I move the parent (hand) empty. They follow the fingertip empties otherwise. But when I move the hand empty, the fingertip IKs sort of drag behind the fingertip empties, and of course the fingers become mangled. I can’t make sense of the way the IK bones are dragging behind the empties here.

I think you should be able to find the blend in question here:

http://s17.yousendit.com/d.aspx?id=25LBEHB19U9LZ2D8457IG04PI6

If you try to move the hands using the large empties on the wrists, you should see the difference in behavior. I’d be very grateful for any help. Also, of course, if this seems like a ridiculous way to rig hands, please let me know. It’s based on some tutorials I read, but I’ve taken a few liberties.

Thanks a million,

Tony

The targets of the lefthand fingers are parented to the LeftHandTarget

The targets of the righthand fingers are parented to the RightWristTarget

I haven’t tried to correct it but it makes sense if one has a Rotation constraint and the other not.

%<

Thanks very much for the reply.

The targets of the lefthand fingers are parented to the LeftHandTarget

The targets of the righthand fingers are parented to the RightWristTarget

This doesn’t seem to be the problem in this case, unfortunately. All the fingertip empties seem to be parented to the wrists, which are then parented to the hand target. Unless I’m really missing something, the parent relationships are correct.

Furthermore, the fingertip empties are moving to the right place, but the IK solvers aren’t moving with them… although they move with them fine when I manipulate the empties directly.

T

[/quote]

Maybe related, maybe not but I suffer a serious update problem with your file. If I Grab either the Left or Right hand target and just move it forward quickly, they leave all the finger IK bones behind and they don’t update unless I then nudge the target a little more. If I move them very slowly into position, the fingers seem to keep up. Even when dragging slowly, there’s a lag and the finger trail behind (gives a wonderful waving effect but not quite the way you’d want it done)

The file also takes an incredibly long time just to load (2.37a & 2.4a2), even after I deleted the particle hair, yet it doesn’t look that complex. This may say more about my system than your model but it’s simpler than lots of other files I’ve downloaded and messed with so it may indicate something?!

Not to frustrate you even more but the use of null bones is pretty much redundant in 2.4 because the tip of the IK solver bone can now be set as part of the IK chain (which is what the null bone was used for before).

Hi, thanks for the reply.

Maybe related, maybe not but I suffer a serious update problem with your file. …
The file also takes an incredibly long time just to load (2.37a & 2.4a2),

I’d noticed the same thing about the loading time, although being unfamiliar with Blender I hadn’t known if it was out of the ordinary. I would be really grateful if anybody could suggest what might be wrong in this respect also.

Not to frustrate you even more but the use of null bones is pretty much redundant in 2.4 because the tip of the IK solver bone can now be set as part of the IK chain (which is what the null bone was used for before).

Actually, I’m not too frustrated. I think I want to get as good as I can at 2.3- while it’s stable and well documented (plus the hardcopy 2.3 book just arrived in the mail…) rather than getting started with 2.4 just yet. But from what I’ve been reading, there are a lot of cool developments in 2.4 that I’ll be looking forward to. I’m already expecting to have to unlearn a few things, but that’s okay.

Update:

Well, now I’m frustrated. After about 15 hours straight of working on this, including completely redoing the armature from scratch, I am no closer to having this working.

I guess I ought to generalize my question to be: what are the common pitfalls in using constraints on armatures? It is clear to me that either there are bugs in Blender’s constraint processing or that I am missing a lot of the nuances in how to use constraints properly. I admit it’s probably the latter. How do constraints interact with each other? If, for example, a child is rotated indirectly, by its parent, should I expect that rotation to carry through to bones constrained to that child via copy rotation? It seems I should, but it’s not happening. At least, not consistently.

The copy rotation constraint especially seems very tricky, but I can’t think of any other way to make sure that the hand follows the rotation of the forearm generally but can still be independently manipulated. Is there any thread in here describing (in more detail than the manual does) some of the potential problems that can arise in slightly more complex armature building?

I’m not going to bother posting my more recent blends for the time being, because they are just variations on the screwed up theme of the first one. If I could figure out what’s actually wrong with that one, I think I’d be back on track.

Hi again,

I’m trying a different tack. One problem I’ve been having is unscrambling the armature after adding a copy rotation constraint. I would like to make sure that the bone and the target object start off with the same rotation, so that when I add the constraint the bones don’t get all wack. However, it seems that control-C only copies parameters between objects. I can’t find out how to copy the rotation from a bone to an object. Furthermore, the N key also seems to work on objects, so I don’t know how to explicitly find out the numerical value of the rotation of a single bone.

This doesn’t exactly answer my questions above, but it might help me find a workaround. Very grateful for any responses.

T

Final update: I seem to have solved the problem by upgrading to 2.4… Things are now behaving as expected, although I now am getting that slow update effect that Andy refered to. But I can live with that for now.

Armatures are still very much a mystery to me but I suspect you’re relying too much on automating everything (Although I deleted all the constraints from your model and it still loads very slowly). As I understand it, most automation with armatures is usually done via actions each of which can then be driven by a bone or added to the NLA.

So, for example (and this is a generalisation, not a set of instructions) you would create a new Action (Action Window) then key a pose at frame 1, say with fingers straight, then key a pose at frame 11, with fingers fully bent and label this Action something like Finger_Curl.L. Then you could apply an action constraint to just one bone (either a finger bone or a spare bone somewhere else all together) which invokes this short animation. If you roate this bone, the action plays relative to how far you rotate it. Then you can animate the controller bone.

There is a sample arm around somewhere posted recently by Gabio. This shows a simple hand/arm action setup in 2.4.

Pre-built actions (including things like walk cycles) can also be added to the NLA and repeated, sped up, slowed down etc where you want them. Actions affecting different bones can be added concurrently so he could walk and wave at the same time.

Maybe you know all this and this is only vaguely how I understand it at this point. And that’s for regular animation - if he’s for a game then that could be entirely wrong.

Hi Andy,

Thanks a lot for the advice. Actually I didn’t know any of that… I was just going to go on to start figuring that stuff out about now. I will try to track down the post you mentioned.

T

Well, you are surely not alone with riging frustrations. Also don’t be surprised if you’ll find out that is not your fault for some armature malfunctions. I’m also in searching for some ‘working new armature samples’, documentation and news… What can I say, stay tuned for new armature samples, documentation and bug fixes. :smiley:

Meanwhile you can bookmark this ‘temporary’ links: