More on bones?

I have just completed my first two (entirely different, though visually similar) tests using character rigging with bones. Most works well, even if the results are still a bit funny-looking, but that’s a fault of design, not of function. What did become very noticable is that Blender bones seem a bit harder to control and predict than many other 3D packages I know. Not so much placing limbs with IK, but predicting the movement in between the animation (IK or FK) keys.

This test shows pure bone usage in arms and legs. Despite extensive adjustment, joints flail about uncontrollably as soon as complex motion is or even has been introduced. Notice that the legs go absolutely crazy after the character gets up from grabbing the box under the bed.
http://www.crispquality.com/monkey/AnimTest1.wmv

In the second test, TrackTo handles are used for both knee and elbow joints. The results are markedly better, but the animation work itself showed that the bones seem to make some very random turns, especially around their own axis (both singular and plural; the axis of the limb as a whole, and of individual bones). Note that each arm and each leg is a seperate Armature / bone set; they are not part of one big rig.
http://www.crispquality.com/monkey/AnimTest2.wmv

I was wondering if there are some good and in-depth explanations of the workings of Blender bones. If I am to work efficiently, I need to be able to predict how animated bones act in between animation keys, especially when IK solvers are in use.

If needed, the animation test using TrackTo handles (‘targets’) can be found here: http://www.crispquality.com/monkey/AnimTest.blend

The link for the blend file is broken.

Getting IK chains to work predictably can be a challenge in many programs.
Here is a pretty good tutorial: http://mediawiki.blender.org/index.php/BSoD/Introduction_to_Rigging

Whoops, misplaced the file. Got it fixed now. Would be mighty greatful for any responses (warning: The scene is a bit of a mess, on account of my trying to fix bone problems and, well, making more mess out of it with every try…)

There aren’t any extensive tutorials / info that I’m aware of, however you could try P.M’ing Aligorith, as he has done quite a bit of programming with the Blender animation system. Then perhaps you can post your results of your conversations.

I haven’t noticed any great differences in Blender’s bone behavior from other packages.

I’m looking at your file now.

Note that each arm and each leg is a seperate Armature / bone set; they are not part of one big rig.

Hmm, have you done that, just to try and isolate the problems? … Or if you’ve had it setup that way maybe it is causing the problem. I can’t imagine why you’d want a rig setup this way otherwise, will be a nightmare trying to coordinate / use the Action / NLA editors with.

EDIT

Still looking at the file, I would recommend using bones in the same armature for IK targets instead of empties, that way the IK targets are included in the Actions that are created, much easier to manage.

EDIT

I see that all your IK constraints have ChainLen set at 0. Maybe that’s why you decided to create all the separate armatures? If you set them to the correct chainlen (usually 2 or 3), then you’ll find having one single armature will work.

Also, you’re extensive use of empties is interesting, but makes the rig really difficult to use. Using bones and all in the same armature is much much easier.

Mike

Hmm, have you done that, just to try and isolate the problems? … Or if you’ve had it setup that way maybe it is causing the problem. I can’t imagine why you’d want a rig setup this way otherwise, will be a nightmare trying to coordinate / use the Action / NLA editors with.
Ditto for me too . It looks like you used hooks/empties to control your mesh and a LOT of them (over 214? based on your vertex groups all named bone.001 etc…) . It looks like you do get pretty good control and it is an interesting way to do it … but like Mike_S said you have way too many variables to control doing it this way … I guess you could group the hooks into something more coherent but even so I’m not sure how you would go about animating it properly with out running into more weird unforseen difficulties … It would be more straight forward to use a single armature and weight your vertex groups to it . It would be a lot more straight forward to animate then your current set up . I mean you would only have to pose/keyframe just one object and its parts as opposed to the potential of fiddling with nearly 200+ objects with your hooks set up …

By the way RobCozzen’s link isn’t to a blend file it is to last year’s BSoD (Blender Summer of Code) documentation project on rigging in Blender . Here is the index page to last year’s documentation project . You might also want to look at “Introduction to Character Animation” as well .

There are several things that could be making things as crazy/hard to control as you describe:

  • A cyclic dependancy somewhere in your rig
  • Multiple ik-solvers affecting the whole armature (chainlen == 0)Otherwise, you are most likely experiencing problems caused by the way Blender handles rotations/quaternions.

Aligorith

I am indeed using the current setup to isolate components and make it easier to track. I never realized how many Empties I was using to hook the skin, but very unsurprisingly, around half are just for the hands; I rigged them fairly inefficiently, and have yet to improve that. Also, I find that hooks are easier to control than Armature skinning, and most of the empties are never going to be handled directly. In fact, I am considering making the vast majority invisible. (Note: Fingers are rigged with IPO drivers, set up in a ‘control board’ a little outside the actual animation area!)

I will strongly consider making IK targets bones. I feel a bit uneasy with Blender bones still, but the many differences I noted seem to be a matter of the default settings set in Blender, not the actual functionality. Once I get the hang of those defaults (and/or reset them to something more natural for me), having bone IK targets wold maybe ease things. Oh, and yes, the chainlen’s are 0 because each limb is an individual, isolated rig to contain problems. “Divide and conquer” is not just for military strategists :wink: Once I feel more in control, a full one-armature rig might become appropriate again, yes.

Vertex Pusher: What kind(s) of grouping mechanism exists to group the hooks?

And it seems there are no cyclic problems, and multiple IKs are eliminated by the isolation of limbs into single armatures. But the rotation/quarternions problem is 100% correct, and I believe the root of all my eviils lies there somehow!

The major use, IMHO of bones is the IK feature, allowing hand and foot placement to be independent of the central rig. If not for that function, I doubt I would even use the armatures. But it is a central necessity to me (logically, or I’d have very stiff character movements), and it is causing my problems. The things already posted here have pushed me significantly forwards, though, and I am humbly scrutinizing every word of yours in the matter. I am grateful for the help, and am open to any and all suggestions, even if I forget to respond to them (or seem hesitant in my responses. We all have habits, and I am trying to push mine aside and listen to reason :smiley: )

Have you tried manually assigning verts to vertex groups instead of using armature weights/envelopes. This method allows for much better control over skinning than weights/envelopes currently do.

Aligorith

Was this test done with your “separate armatures” rig? … or a single armature?

If it was a single armature and you had the Chainlen at 0 I suspect that’s the problem.

I don’t see any random turns in the second video or the blend file.

Download any of the rigs in my “best of blender” thread, they’re all single Armature rigs …(.well Ludwig and AJ have separate Facial armatures), and I’ve done lots of test animations and haven’t seen any weird motion like is displayed in the first video.

Even if you keep using the hooks, I’d recommend parenting the hooks to bones. If you create a separte armature for the face controls, for example, you can select all the bones in that armature, press alt-g (or alt-r/s) and that will reset all the facial controls.

Mike

I’ve been pushing and prodding the IK system a bit to figure out its logic. I have now hit what might be the FINAL snag before it bends to my will:yes:

http://www.crispquality.com/monkey/BasicIKRig+JointHandle4.blend

The file contains a basic IK armature, with three bones rigged for bending in a single joint, Y and Z locked to get full control over the third axis of the bones, and a single joint handle (an Empty called TARGET, which the root bone has a TrackTo constraint towards) to decide which way the knee/elbow joint points. It is, effectively, a fully controllable joint, ready for inserting into my character as knee or elbow.

But it retains one rather odd problem. If you try moving the joint handle around in order to point the joint in different directions, you will find that although it does, indeed, turn, it does so with a very strange relation to the target! If the IK target (which basically controls the wrist/ankle of the armature) is idrectly below or above the root of the armature, the joint will obediently point towards the TARGET Empty. But as soon as the IK target (wrist/ankle) is moved, moving the joint target makes the joint spin either too slow or too fast, alligning correctly only when the direction coincides with a (global) axis which both IK target and root are on.

I have set a camera to rotate according to a small cube that tracks the IK target from a position at the armature root. This means that the camera is always looking “down” the armature, at a 90 degree angle to the ‘plane’ that the joint is circling. This way, it becomes possible to move the joint handle around the armature as if the IK target was directly beneath the root. And yet, moving the joint handle around continues to make the joint spin at odd ratios; moving to what would be a 45 degree turn of the joint direction might produce a turn of 60, 20, or any other degree of the actual joint. It does not follow the joint handle proportionately unless the armature’s IK target is directly above or below the root.

I am trying to find the logic that drives the way the armature IK joint follows the joint handle around, but it is eluding me completely. There seems to be a correlation with how the armature looks in edit mode (i.e. with the IK target directly beneath the root), but even that seems to be only occassional. This means that I cannot, for example, rely on the joint handle when I do the “crawling on the floor” movement of the character in the animation. Moving the character’s foot or hip would simply send the direction of knee joints off in some unpredictable direction!

I think that is actually what I’ve been trying to do with the hooks. Off hand, I’d say the results would be the same, but your method would probably be easier to get a clear overview over, so I will try that in the very next version!

EDIT: Just spent a few hours(!) having fun with Ludwig. You really have something going there, Mike!! I still distrust using shapes (even if driven) for facial animation, but you did a damned fine job of that little fellow. And I whole-heartedly agree with you that Blender has the properties to become a solid character animation tool, it just needs to be fully applied. I have nibbled a few inspirations from Ludwig for my own work, and if things work out even borderline right, I should have a usable base character next week. Maybe making him public domain will help people dabble in character tools for Blender?

Vertex Pusher: What kind(s) of grouping mechanism exists to group the hooks?
Just grouping them (Ctrl G) . Though it all that would do is to make it easier to select them from the outliner as groups (more for editing purposes I think then for animation) .

But it retains one rather odd problem. If you try moving the joint handle around in order to point the joint in different directions, you will find that although it does, indeed, turn, it does so with a very strange relation to the target! If the IK target (which basically controls the wrist/ankle of the armature) is idrectly below or above the root of the armature, the joint will obediently point towards the TARGET Empty. But as soon as the IK target (wrist/ankle) is moved, moving the joint target makes the joint spin either too slow or too fast, alligning correctly only when the direction coincides with a (global) axis which both IK target and root are on.
That’s because for some reason you have have a track to constraint on the root bone not because of the IK constraint . I’m not sure why you need the track to constraint on the root bone but that is what is causing the odd flipping behavior . After a certain threshold of motion is reached (depending on the axis it is tracking) it will “kick in” and force the root to point (track) at the empty .
Is there a purpose for this ? Because I can’t think of why you would want to add this constraint to at this point in the armature … Usually you use the track to constraint on legs to prevent them from bending the wrong way with the old auto IK solver in armatures …
If you don’t want it to bend in certain ways you can just use the axis lock/limit option in the Armature Bones Panel that appears when you apply the IK solver constraint . Just hit the “limit” button and two fields “MinX : -180, MaxX: 180” will appear as well as a colored circle (in this case red for the X axis) radiating out from the root end of the selected bone in the 3D window . You can just adjust the two values to limit the range of motion (minX value has to be always be negative, maxX value always positive; both can be set to zero) and when you do that it will show up in the 3D window as a colored arc representing the range of motion the bone is capable of as a part of the IK chain . This works for all three axis but the line thing does not display for the Y axis for some reason … though if you limit all three a sphere appears representing the range of motion for that bone . It’s kind of kool when you limit the range of the all three as it gets represented with semi spheres that illustrate where the tip of the bone can move to .
Unless there is some other reason you needed the track to constraint there I suggest removing it and using the limit axis option .

EDIT: Just spent a few hours(!) having fun with Ludwig. You really have something going there, Mike!! I still distrust using shapes (even if driven) for facial animation, but you did a damned fine job of that little fellow.
Err… I don’t think Mike_S made Ludwig . I’m sure he’d be the first to correct this … I’m sure I could look up who did … but I’m too lazy … But I think Ludwig was the first “public” Blender rigged character . If you liked that one I’d suggest you play around with “Mancandy” by Bassam (he was the lead animator/rigger for Elephant’s Dream) and Calvin’s rig (if you don’t like a lot of shape keys) . Both I think are in the “Best of Blender” link under Mike_S’s signature .

I did not create that rig, or any of the others in my “Best of Blender” thread !

I’ve just collected the links :slight_smile:

My first name IS Mike, not Jason …or “Sketchy” :slight_smile:

Ludwig “Support” thread"
http://blenderartists.org/forum/showthread.php?t=66476&page=6&highlight=ludwig

Mike

I don’t completely understand how trackTo’s and IK chain interact, but I’ve seen TrackTo’s or “pole vector’s” used in other 3d software. It’s always been my experience a matter of adjusting both the end effector and the “target” (pole vector) to get desired rotations.

I think with Ludwig, the “pole vector” / trackt to was avoided by the way the rig was initially built (forward leaning bones). And similar functionaly to “target” bones is achieved by just moiving the thigh bone if it’s out of position.

Mike

I think with Ludwig, the “pole vector” / trackt to was avoided by the way the rig was initially built (forward leaning bones). And similar functionaly to “target” bones is achieved by just moiving the thigh bone if it’s out of position.
Funny … Ludwig is the only rig I haven’t looked at … I should study it too I guess .

And it’s not only the track to constraint that will get you that jerky effect; copy rotation does something similar when the bone that the constraint is copying is too close and it crosses the constrained bone’s center (i.e. it’s root tip) .
I made an arm rig with a radius bone that had a copy rotation applied to the humerus . The constraint followed a child bone of the radius bone and the humerus, ulna and radius were a part of an IK chain . Everything was fine until the child bone crossed the root tip of the humerus bone then the whole arm would whip around the root tip of either the humerus bone or the child bone of the radius (I couldn’t tell which) like a helicopter .
I fixed the problem simply by moving the child bone slightly and adjusting the influence slider really low and still got the effect I wanted (which is the rotation of the radius around the ulna - which flips your palm prone or supine - effecting the rotation of the humerus slightly like in a real arm ) . Though there is still a sight tremor sometimes in that “sweet spot” - I can live with for now .
Which in a long winded way is saying (I think):

It’s always been my experience a matter of adjusting both the end effector and the “target” (pole vector) to get desired rotations.
I really don’t have any experience using other software in so far as rigging goes, but Ton’s documentation on the Blender site on reworking the armature/animation code gave me a good “under the hood” concept of working with the armature system .

And as far as how the track to constraint is affecting Cognis’s set up and for that matter you can generalize from both his and my examples : If you have an IK chain and a bone in that chain also has another constraint that is axis based (the “Copy” rot/loc/scale and track to) be aware that in some situations where the the center/root tip crosses which ever axis the constraint governs you will probably get some unwanted results . Avoid them where possible . But if required you can always adjust the influence value and/or move the constraint target far enough to where they are not likely to cross . (And yes I know it is very unlikely the copy location constraint would cause such problems - in my experience the IK just ignores it but you never know what some of these crazy kids will come up with . As for the copy scale … well I haven’t so far had a situation where it was a problem in an IK chain - NOTE TO SELF: try this - … but I have had another situation where a slightly wonky result happened … and since apparently I’m feeling quite “type drunk” … )

Ok as far as odd effects with the copy scale constraint goes it happens in conjunction with the stretch to constraint . And it’s more of a reminder to Ctrl A your armature before adding constraints to it then anything else . It really doesn’t give you odd effects per se but does leave you with an odd rest length to the stretch to bone which can give you problems with your mesh .
Using the combination of the copy scale and the stretch to constraints you can “automate” parts of your armature, i.e. you can affect one part with another without having them be a part of an IK chain or even be connected at all …
The stretch to constraint (which I sometimes like to think of as the "bastard"constraint because so few people seem to utilize it for some reason) if applied to a bone before you apply scale/rotation (Ctrl A) and then is linked to a copy scale (and probably others though I have not experienced it ) on another bone will, when you finally get around to Ctrl A, wind up with an odd bone roll and a rest length that will not be what it should be (1.0) though you can reset the rest length easily relative to the to the armature (it will snap into place when you hit the “R” next to the text field and you have reset the bone roll value to zero in the armature in Edit Mode) if the rest rest length is not 1.0 then the part of the mesh affected by the bone also will not be the correct size (actually this is conjecture on my part since I am working from armature to mesh I shouldn’t be affected by this though this seems logical) … So remember to Ctrl A your armature before you apply constraints ! … :stuck_out_tongue:

And since I am so type happy :spin: :

There are several things that could be making things as crazy/hard to control as you describe:

* <b>A cyclic dependancy</b> somewhere in your rig

Thank you Algorith ! :yes::yes::yes: