Can anyone give me some tips or reading material for an elegant rig to this frog’s rear leg. I’ve tried a few things, but I don’t seem to be approaching this right. How would one go about rigging a leg like this with multiple joints that point opposite ways? My TrackTo constraints don’t seem to do what I want in this situation.
hey. i’m curious on this one too. the blend looks cool but i have no clue how to do that. Are there any good rigging tutorials out there for stuff like this and more complicated?
Thanks. I’ll check it out.
Thanks a million! I was way over complicating that as usual.
Gee I guess you must be in a hurry … I was going to answer in your first post but since this got rolling …
The “Z” type of leg joint does not need the scale bone to control its movement . The entire point of the scale control bone is to keep the various bones along a single arbitrary axis (as defined by the scale bone) where as parts of the frog’s legs anatomically has more then one axis along which it bends . The “hand” bone/joint folds underneath the legs and also has some rotation that it is capable of . Also if you notice in the picture you provided of the frog the lower leg is twice as thick as the upper leg or the “palm”/hand part of the leg . This is because : 1) species specific - some frogs do not have such proportions especially the thinner upper leg - most frogs in non tropical regions have fatter upper legs, and 2) the lower leg has like our lower legs and arms have two bones in them (all vertebrates have this set up or at least vestiges of this) - this two parallel bone set up gives the “child” bone (to use armature speak) a degree of rotation and flexibility to the joint .
You might have better luck just using a simple IK solver along the length of the leg then applying a scale control bone to the entire series of bones . Like in Fligh’s example except that you need to add targets (bones, empties what ever as long as it has a center) for you to animate it . Without targets for the IK solver you cannot simply key the constrained bone - it will do nothing (OK it will key the rotation but not the IK calculations) unless you select all the bones in the chain and key them together like with Auto IK .
Here : http://uploader.polorix.net//files/307/FrogLeg1.blend is a bit of revision of Fligh’s blend (hope you don’t mind Fligh) with IK targets and changing the “up/down” IK control bones he put in at the shin/thigh joints into non-“use tip” (or as I told you up in the finger rig post of yours what used to be called "Null"bones) bones and with a slightly dodgy technique I call “inverse target parenting” to control the motion with a single bone (the Foot_target bone - all the other targets in the leg chain are children of this target bone) … This has a similar effect as the scale control bone in some ways in that you only have to grab/rotate (as opposed to scale/rotate in the scale control set up) to move the various parts along the axis defined by the parent/control bone (the Foot_target bone) when you rotate but also has some flexibility in that you can pose the child bones in various positions independently of the parent (though you should do this carefully as it can get confusing very fast if you do not keep track of what you are doing - if you get mixed up though you can always Alt-G or Alt-R and the bone will snap back into place relative to the parent bone) … BTW there is a short 61 frame action keyed if the Action editor window doesn’t cue you in … Just Alt-A …
About the track to constraints you have applied to your set up … well unfortunately as of now the IK solver will override any other constraints that is applied along the IK chain length … this does not effect the chain when you have not applied any transformations to the IK target (when you initially add them they effect the bones as expected) but once you start moving /keying them the other constraints get thrown out the window in favor of the IK calculations …
Until and when and if this gets “corrected” in the code, the best solution is to arrange/pose the armature in Edit Mode so that you do not depend on other constraints to “shape” the behavior of your armature . For example, the “bend” that is in Bassam’s hand rig actually controls the direction of the IK solver . Once you have that bend in an IK chain, it is almost impossible to have the joint bend against it . This is not apparently Blender specific, as I have seen comments on the CG Society site in the rigging section advising of the same thing using other software . The only exception to this would be to apply another IK solver within the chain . But be aware that you need to play with the chain length value so as to not “break” your rig - if the chain length values conflict, the IK calculations will resolve themselves independently and actually disconnect bones even if they are connected in the armature in Edit Mode … And I did try to substitute IK solvers in the place of the Track to constraints but it still does not work properly … that really has more to do with the initial pose you have of your frog … see below …
And actually another workaround that sometimes (often) works is to do what Fligh did in his file - that is to set the IK solver perpendicular to any other IK solver in the chain though you still need to manage the chain length to keep the IK solver from breaking your rig .
(This was going to go in your last post)
You might also consider setting the rest pose at a more neutral point, that is, somewhere between full extension (like you have now) and contraction (what the picture shows - the characteristic crouch of a frog). This might give you better control when you apply the IK solver in Pose Mode …
Or as Fligh posted a more crouched pose … Though I only suggested the above because I would make it somewhat easier to model your mesh without trying to figure out how not to clip against your mesh etc…
You need to introduce more 3 dimensionality into the armature itself to get it to pose/behave in 3D . Right now you have your frog pinned in space like a high school biology project . You need to introduce “bends” like I described above to control the IK solver’s behavior in certain ways . I also moved the “knee” and “ankle” out of the plane that it was in Fligh’s original blend to give you an example of what I mean …
Awesome, Thank you very much for the post. Very informative.
Funny you say to pull him to a more neutral pose, I just kinda realized this naturally I guess because I started modeling him to the sitting position and the deformations worked out much nicer, good advice.
Check out how it’s coming if you want:
http://studentweb.eku.edu/mark_ballenger/frog6.blend
I think I’m going to go with Fligh’s simpler solution though for this project. It seems easier to control and get the poses I would like. Your solution seems very interesting and elegant however, just not as intuitive for my feeble mind at this stage in my rigging career 
After playing with it for 20 minutes, I felt like I was still fighting to get it to go where I want in certain positions. Though I definitely plan to keep this on file so I can come back to it and learn from it. Very interesting.
Thanks
I am glad that you my long winded post found it helpful . But apparently it was a bit took long and confusing for you to pick up on an important point I made :o . The reason why I altered Fligh’s original blend was because he did not set a target for any of the IK solvers … not to improve his basic design . As I said above you have to have a target for the IK solvers otherwise you cannot properly key the IK solvers for animation . At best you can key the rotation of the constrained leg, but not the entire chain without an IK target for the constraint . Or you need to key the rotation for all three bones (like in Auto IK) .
You certainly do not have to use my “inverse target parenting” (yes it does sometimes get confusing at some view angles) but you should add targets for the IK solvers if you intend on animating your frog .
In fact if you want to keep some of the control that is in Fligh’s rig and give the IK solvers targets you have to convert the perpendicular IK bones into targets for IK solvers that you have to move to the Shin and Thigh bones and you also have to unlink them from the IK chain as this will cause cyclic dependencies otherwise …
Here is a version of your frog with the changes : http://uploader.polorix.net//files/307/frog7.blend
And yes I know it doesn’t quite behave like Fligh’s but that’s the price I guess for having IK solvers embedded within each other . But the real main control target bone in this set up is the Foot_IK_L bone that I added . The other two now target bones can be used to tweak the position or rotation of the leg as before only now they don’t “stick” to the bones as before which can be confusing somewhat (and don’t try to make them stick either like with the copy location constraint - you’ll only create cyclic dependencies - that’s why my hack of “inverse target parenting” - you can somewhat keep track of the children) …
If you do not intend on animating your frog Fligh’s solution is fine … even if you do intend to animate it if you keep in mind that you need to key the entire leg for every keyframe then it will work also . It is just that technically speaking not having targets for the IK solver is not the “correct” way doing things (with Fligh’s method you are essentially creating a “local” auto IK setup) … And also it may slip your mind that you do need to key the entire leg sometimes …
ahhhhhhh I see what you mean now. Well thanks for the reply, that would have save me some confusion later.
Actually, I think I’m starting to get the jist of this leg rig. Although it’s not as intuitive at first, it animates the legs extending motion quite nicely (by letting leg and thigh decompress sooner than the foot bone does). That will save time when in the animating process instead of having to key multiple solvers for that kind of movement, i’ll just need to do one.
Thanks again, I think I’ve learned much already for this little example you supplied.
Unfortunately I still struggle on certain poses with this setup… It seems because of a lack of control over where the end of the thigh bone points. the thigh follow bone doesn’t seem to make the thigh follow as expected. It would be nice to have control over that, is there a way?
[EDIT]: I’ve tried to remedy this by adding two constraints to the setup. I’ve somewhat made progress… I say somewhat because what I added to the setup has issues. I feel I’m just over complicating what was there, and I’m hoping theres a simpler solution.
What I added:
-another follow for the foot (so that I can control the foot bone independently when needed)
-another follow for the thigh (so that I can gain control on where that crazy thigh bone is pointing at)
http://studentweb.eku.edu/mark_ballenger/FrogLeg2.blend
My main concerns are that having so many follow bones could cause a headache in the animation process. With so many follow bones floating around, plus the fact that on certain movements the new follows end up in unintuitive places, which could be confusing on trying to figure out which is which. Please let me know what you think or suggest. You’ve been quite a good instructor for this.
I think you are over complicating the rig at this point … It looks like you combined the “straight” nested IK chain that I put in your blend the last time with the “modified” version of Fligh’s setup … I don’t think you need both set ups together like that because at this point you might as well scrap the IK solvers and just pose using FK since you have more target bones then you have bones in your leg … I think the thing to do would be to let the IK solver do most of the work for you and then use auxiliary bones to tweak the pose if needed …
And perhaps I should have explained better the whole “inverse target parenting”(from here on ITP) hack … First of all you do not have to use this method, but the reason why I do in a lot of my set ups is :
- in a nested IK solver situation the constrained bones do not “stick” to the auxiliary target bone as is usually the case with the IK solver when it is not nested, so firstly it is a method of keeping track of the auxiliary bones (this despite the fact that I do put all my target/control bones in its own bone layer - which is good practice BTW- it can still get confusing even with only a dozen bones, even though you could use the custom draw function to distinguish the various bones but there are other benefits to doing this as well)
- and also because the auxiliary bones are children of the parent/main target bone if you get “lost” somehow you can always Alt-G or Alt-R to snap the auxiliary bone back into place relative to the parent/main target bone and not back to where it would be in the Rest Pose which means that you don’t loose the general pose you were happy with just the tweaking you did with the auxiliary bone . Or if you need the main control bone to be at a specific point in space but you want to alter the pose …
- And in some setups because the auxiliary bone moves with the main target bone you can get the desired motion by using this technique … of course the flip side is that in some situations because the bone moves with the parent you can also get unwanted motions as well … it all depends on the context and if you feel comfortable with and can learn that at a certain point the motion created by the relationship is predictable after you get used to it .
Also you do not have to keep the target parenting hierarchy as I set it up (I think I set it up in a “radial” manner with the foot_target bone being at the center of the hierarchy in Fligh’s set up) but you can try any combination you’d like or get rid of it all together …
Here are two modified and more simpler versions of the leg :
Version 1) : http://uploader.polorix.net//files/307/FrogLeg1A.blend Is just the modified Fligh set up with just a different ITP . The parenting is “straighter” in that it goes Foot_target parent to Shin_target to Thigh_target . But more importantly I wanted to point out that with these nested IK set ups that after a while you realize that certain auxiliary target bones creates a somewhat predictable motion in the rig . For example the Thigh_target bone in this set up has the most effect when moving along the Z axis in this case . It also creates some erratic poses too because of this but once you realize that you can manage this (like by going in to top view when posing the master Foot_target bone then tweaking it from the side or any other view) .
Version 2) : http://uploader.polorix.net//files/307/FrogLeg3A.blend Is a super simplified two target set up that lets the IK solver do most of the work but with an auxiliary target bone to tweak the position of the knee . You do not have direct control over where the heel goes but you can by using the thigh_target bone move it . I have use the ITP hack on this but feel free to get rid of it (just tab into Edit Mode and make the thigh_target the child of nothing in the Armature Bones panel) - with a simplified set up like this you don’t always need it . And the auxiliary thigh_target bone in this case controls the roll of the Thigh bone very clearly … This is another reason not to clutter up a rig with too many constraints/target bones it makes it easier to see what effect a target is having on the rig . Also I have locked the knee joint to one DOF (degree of freedom) along the Z by locking the X and Y axes in the IK locks/limits in the Armature bones panel because knee in general usually only have one DOF .
But in general you shouldn’t try for total control over every bone if you are going to use IK solvers . You should use it to help you save time by generally getting it to behave as a particular real life analog (such as a frog leg) might with as few target/control bones as possible . I mean I think you’d prefer to just move one bone to pose your frog (if that were possible … actually it is with the Action constraint … but that’s a topic for another day) then have to move a dozen bones … That’s why we have IK solvers in the first place …
Hope this is clearer then my other long winded posts … :o
Cool. FrogLeg1A is basically like what I had, but much more efficient and less complicated (nearly half the bones and IK Solvers). I think I see where I fell short, the shin IK I added just was unnecessary and led me to running in circles adding unneeded bones to get back to square one. This one will be the setup I use. Now if I can just come up with solutions like u seem to intuitively, without a crutch. I think I’m starting to grasp it, however every time I think this I am proven wrong.
Though your posts are long, they are thorough, which has been quite useful.
Also, you mentioned letting the IK solver do the work. Yes, most of the time I will have no need for complete control of the knee, but for the project I have planned I will need to place it for seldom poses. I just want to be sure that I will have capabilities to do so by planning ahead.
Thanks again!