The Hind Leg

The hind leg of a quadruped is quite a bit different from a standard biped leg. Technically the anatomy is similar, but for a dog, unlike a biped, their “heel” doesn’t rest on the ground. For riggers and animators, this is kind of like having an extra knee to deal with. Most rigs, I’ve generally found, just treat this setup the same as an inverse foot, locking the orientation of that last joint to the ik control and supplying an attribute to rotate it manually. That’s not a bad solution, because for animators it’s consistent with other types of rigs, and for riggers it can usually be built quickly with existing tools. So it works, but I’ve never been completely happy with that type of setup because the ankle requires a lot of attention just to get it moving properly with the rest of the leg. Many running quadrupeds, including dogs, have a pretty tight relationship between the knee and ankle, and I wanted a setup which automated that motion as much as possible, without sacrificing control.

So I laid out some goals for how I would want a hind leg to behave:

  • Effects of the IK should be evenly distributed between both the knee and ankle.
  • Pulling the IK control away should result in a perfectly straight leg before breaking, stretching or pulling away from the foot.
  • Pole Vector twists the whole leg, not just the knee, which is another byproduct of a standard inverse foot setup.
  • The ratio between the knee and the ankle, which I’m calling “pitch,” should be controllable as an attribute.
  • Possibly other attributes for twisting non-uniformly, or breaking the plane of the leg to bow it in and out.

One of the key component in getting all of this to work is the ikSpringSolver, which for some reason is a super secret IK solver in Maya. It doesn’t have a front-end, so you have to create it from the command line. But basically it’s a nice solver for chains longer than 2 bones, which need to collapse evenly and alternately, kind of like a spring, but more like a long strip of folded paper or something.

Anyway, best just to jump right into it. Here’s a basic joint chain for a hind leg, the hip, knee, ankle, foot:

Assigning just a regular IK handle to the whole chain might be the first instinct, and it’s worth trying out. At first glance you standard IK will appear to work fine, but when you compress this chain, you may begin to see its limitations as the joints rotate past eachother:

Furthermore, there’s nothing we can to do in the ik system to fix this pose.

This is where the ikSpringSolver comes in. To use the ikSpringSolver, you first have to initialize it by typing:

ikSpringSolver;

into the MEL command line. Then you create an ik handle by using the ikHandle command with “ikSpringSolver” as the -solver argument. Select the first and last joint, and then run this:

ikHandle -solver ikSpringSolver;

Now for some reason that I haven’t really narrowed down yet (maybe someone else has some insight on this), sometimes the chain will flip when you create this solver. I think it’s just a case of the pole vector being in the wrong spot, so assigning a pole vector constraint seems like it might be the only thing you need to do to fix it. I’m not sure if that will turn into a bigger issue or not.

So the ikSpringSolver is half of it. If you go into the ikSpringSolver attributes, you’ll find it has its own section where you can adjust the weighting of the joints in the system using a ramp, but while this is a cool feature, it doesn’t give you quite enough control. If you play around with it, you’ll find that it only has a subtle affect, and only when it’s not in the default pose:

It’s cool, but not quite the solution we’re looking for. But what you can do is nest another ik system underneath this one. Nesting IK systems is a very simple and useful technique, all it means is building another chain and IK handle that is a child of this system.

So we’re going to make a new rig to control the pitch of the leg. Duplicate the whole chain, and then create a regular ikRPSolver from the knee to the foot creating a basic two-joint ik chain. The result would look something like this when you move the new handle by itself:

Parent the duplicated chain under the hip of the primary chain, so that the top joint inherits the hip motion from the ikSpringSolver. Finally parent that new ikHandle under the ikSpringSolver handle. Now when you move the parent handle, the secondary chain follows the primary one exactly.

The benefit is now is that there’s one joint which isn’t being directly controlled by an IKhandle: the secondary hip. Rotate it and you’ll be changing the pitch of the leg:

This is the most basic example. Depending on the functionality you want, you can also do the same thing but with an inverse IK setup for the secondary chain. In either case, the rotation can be hooked up to an attribute to control pitch from the foot control. For additional clean-up, create a pole vector control for the spring chain, and then make the secondary chain follow along by setting its pole vector to the be the corresponding joint in the primary chain.

So here’s a short clip of the hind leg as I have it currently set up. In this example there’s another fancy thing going on. I’ve created a distance node, set up like you would for a stretchy system, but instead it’s hooked up to a remap value node to feather off the influence of the pitch effect as the leg gets stretched or compressed. That way you can’t pitch the leg when it’s completely straight, and a pitched leg will still stretch and compress evenly.

So, I hope that was interesting! I’ve been working on a foreleg as well, hopefully post that one soon.

UPDATE:

As the resourceful commenters discovered, the ikSpringSolver behaves a bit differently from the ik solvers that we’re used to. Whereas a regular ik handle will respect a pole vector constraint regardless of where they each are in the hierarchy, the spring solver inherits twist from its chain’s local space, which can lead to double transforms. A solution is to keep the ikSpringSolver chain (not the handle) outside of the local hierarchy, in worldspace, and point constrain it so that it doesn’t inherit rotation.

ANOTHER UPDATE:

Here’s an example file:

Hind Leg Rig Example
Hind Leg Rig Example
hindLegExample.v1.ma
Version: 1
138.7 KiB
1881 Downloads
Details
Share Button
This entry was posted in Devo, Rigging, Tutorials. Bookmark the permalink.

45 Responses to The Hind Leg

  1. Toke Jepsen says:

    cool setup. will definitely try that out on the next quadruped.

  2. slick solution Morgan. I’m going to have to give this one a try.

  3. Sweet, glad it made sense. Let me know how you go!

  4. Jared Johnson says:

    NICE! oh man that’s so much nicer then the crap set up i have right now, think I’m going back and redoing my Dino rig 🙂
    thanks for the tutorial man.

  5. Nigel Haslam says:

    Hey Morgan,
    Very cool setup! However when I rotate my rig in Y. my leg joints double rotate and I can’t stop em. Have tried pole vectors and the No Flip method, from Art of Rigging..
    Pole Vector X 0.1
    Pole Vector Y 0
    Pole Vector Z 0
    Then offset the Twist attribute of the solver by 90, but still no joy.
    I’m a bit of a noob at rigging and would appreciate an update if you figure it out.
    Also love to see how you hook up that feathering.
    Thanks for sharing..

  6. Hey Nigel, are you talking about rotating the whole rig, or just getting the pole vector to work? Is it a double-transformation problem that might be solved by rearranging the hierarchy? I’ll take a look at my current setup and see if I find anything weird. Like I said I haven’t really put this through the paces yet. And when I find a moment I could certainly try to do a little tutorial on creating falloff with a remap value node.

  7. Jared says:

    Hey i got the same double-transformation. i dont know why it happens but…
    i did a quick fix by plugging in the y rotate of my main rig mover control (or whatever you use to move your leg setup) into the Twist attribute of the Spring Ik. i did this with the Connection editor. this is only a patch fix! if you rotate 360 degrees on all 3 axes enough you will get the problem again. im sure there is a better solution 😛

  8. Nigel Haslam says:

    Heya guys,
    It’s when I rotate the whole rig hierarchy.
    I understand that the node hierarchy is crucial to avoid double translations but in this case all my other IKs are working fine and the spring hind leg elements are arranged in the same way.
    I’ve implemented Jared’s fix and it seems to do the trick but, from his description, there needs to be a more reliable fix for it.
    Cheers

  9. Ah, yes, that is interesting. I didn’t catch it, but it looks like the spring solver behaves differently from the other solvers in that somehow it’s getting its twist from its local space as well as the pole vector. What I’d try is to put the spring solver joint chain in a world space group, and point constrain it into your hierarchy so that it doesn’t inherit rotations. I did a quick test and that seemed to work, but I’ll definitely have to look into it more to make sure its stable. I wouldn’t recommend trying to counter it with the twist, for the reasons you stated. For something like this, if it seems like a transformation problem, I like to try to come up with a transformation solution first.
    Thanks for troubleshooting that, guys!

  10. Pingback: Rigging Wiki | Animation I

  11. Thanks Morgan! Simple, clever, and clean solution! This would have been gold when I was rigging for my thesis!

    A huge goal of my leg rig was to assure no-flip behavior with the double-knee. I prefer your double-knee solution, so I decided to make it no-flip. I also fixed the local-space transform issue as you said, by simply not rotating it. Here’s a link to a quick vimeo demo of it in action. I hope this helps and I’d love your input on it. Thanks again!

    Quadruped Leg Rigs with No Flip

  12. Looks great Katlan!

  13. Do you mind if I post my solution on my blog? I’ll be sure to give you credit and link to your posts!

  14. Nielsns says:

    Thanks to Morgan..

    Pls allow Katlan to share solution…we are waiting!!!

  15. Yes, of course! Sorry Katlan didn’t see this comment.

  16. No worries Morgan, thanks! I’ll get to writing that post soon Nielsns!

    Also, I had a question on implementing rigs like this. They tend to be fine when they are planar, ie all joints with zero X values. But I get problems when I try to use them on joints that match the model’s often imperfect pose. For example, when making this rig on a hind-leg who’s ankle and knee joints are twisted, the ikSpringSolver ik bends differently than the ikRPsolver ik, ever so slightly, making the ankle joints not line up. (Does that make sense? I can post images to explain if not.)

    Any trick to fixing these imperfections? Or is there a different way to translate these techniques to a posed model?

  17. Since ikSpring isn’t the most stable or supported of solvers, I’d keep that one planar, even if joint positions don’t line up, and then build the correct joint placement into the child joints which are diven by more stable IK. But whenever you go off axis it will make this sort of multi-joint control chain more complicated and less “clean.” If it’s at all possible, the best way to deal with this is to adjust the model to be more planar. 🙂

  18. Ah I’ll have to try that. Yeah its much more stable working with planar joints. Maybe there’s some rest-pose or offset on the IKs causing it. But I’ll jus blame the modeler 😉

    Thanks for the prompt reply!

  19. Hey I’ve finally added an example file, sorry for the wait!

  20. Kaine Zadro says:

    Legend! Thanks so much for this! That ikSpringSolver saved my life. I’ve done some extensive searching trying to get my double jointed leg to work properly and have never heard of it ANYWHERE. Awesome to know!!

  21. Cole Clark says:

    Hi Morgan! I adapted some of your sensibilities to a quadruped rigging of my own. I think it’s really clever how you have the position of one IKH driving the start of another down the joint chain, and then layering the start position of the downchain IKH with a control that manipulates the rotation of the joint above it. I tried other homebrew solutions to this problem before that were way less clean and successful.

    So thanks 🙂 I’ll keep following this~~

  22. Cheers guys. Layering IK like this is often something to consider for setups that need more sophisticated control than a basic IK setup.

  23. R Boyle says:

    Neat set up. It can be perfectly serviceable without the ikSpringSolver.

  24. The same principle can certainly work with a standard ik solver, the spring solver just has the nice added bonus of giving you a more exact collapse and extension poses. It may be possible to emulate that on an RPsolver by driving the preferred angle of the joints, alrhough I haven’t tried that yet.

  25. R Boyle says:

    Driving the preferred angles could work. It’d be interesting to look into any performance speed differences…. Anyway, thanks.

  26. If you try it let me know what you find, at the very least it might be worth doing just because springIK is a bit dodgy and requires special treatment just to get it to behave.

  27. Alex Watkins says:

    Hey Morgan, I have had some trouble when attempting to blend between your IK hind leg and an FK leg, I have used four ‘blendColour’ nodes to blend the rotations of each joint to a result chain but once I move the IK Hind leg and blend between the two the result chain doesn’t match up, it gets about half way. I think the problem is because the spring solver stops some of the joints from having rotation values. Any idea how to get around this?

  28. Alex Watkins says:

    Oh, just fixed it, I had to use the rotational values from the primary chain rather than the nested, thanks again, awesome tutorial!

  29. Alex Watkins says:

    Another amendment, you actually have to add the two rotations together so that the pitch shift for the heel still works, okay thats my last comment 😀

  30. Hehe, glad you figured it out. You could always blend constraints as well.

  31. Alex Watkins says:

    Hey Morgan, I have an issue with a rig I’m working on and would like to blend constraints like you previously mentioned, how would you go about that?

    Cheers

  32. By blending constraints I just mean constraining a node between two other nodes, and setting or controlling the weight values on the constraints to drive which has more influence.

  33. Alyssa D says:

    Hi Morgan,
    Thank you for the tutorial! I’m relatively new to rigging and was using this setup on legs of two quadrupeds I’m working on. One is a stylized cartoon deer, and I added a reverse toe setup so that when I use the Leg Pitch the hoof pivots from the tip of the hoof, giving me a “toe roll” when lifting off the ground.

    I read all the comments, and kept my ikSpring system out of the hierarchy, constraining the top ikSpring hip joint with a Point Constraint to a duplicate hip joint that’s connected to the pelvis. Despite this, I’m still having an issue with the ikSpring hip joint rotating locally when I rotate my Root Control. The whole system does not appear to rotate very much, but the mesh that’s bound to the child IK joints will twist up as if it’s spinning around the ikSpring hip joint. Do you know what might be going wrong in my setup?

    Thank you!

  34. Hey Alyssa, did you have a look at the example file to compare? Sorry I haven’t had time to look into this yet.

  35. Pingback: Rigging for Education: Jaguar « sergiosykes(dot)com

  36. Michael says:

    Thanks for the great tutorial, one quick question that might be obvious…

    How does the polevector work in this set up. Looked in the example file and I can’t figure it out… The spring solver joint chain works just fine with the pole vector, but the joint chain used to bind that has the rp solver is oriented in the opposite direction. So using the pole vector flips it.

    How did the get it to follow the pole vector in the front of it correctly?

    (a little request, I wish the example file didn’t have every channel locked and/or hidden, it makes learning from it a bit more of a hassle)

  37. Hey Michael, I can relate to that annoying little issue. There’s some instances where the pole vector constraint has the opposite effect of what you were hoping for, and it can be hard to predict or avoid. I solve this by sticking 180 into the twist attribute on the ik handle, that will correct for it.

    Thanks for the feedback on the example file, unlocked channels are a pet peeve of mine but I totally understand it makes sense for a tutorial.

  38. Pingback: It’s May already! | Turret Town

  39. Shobhit says:

    Hi,

    I was trying to decipher the hind leg example you have posted. First of all, it is a great hind-leg rig. As I was trying to recreate it, I couldn’t understand a lot of things. Would it be possible for you to write a detailed post explaining the creation of this rig?

    Thanks.

  40. Lior says:

    Hello Morgan! Thanks for this awesome tip!! i know it been a long time since this post.
    I’m trying to figure out how to implement an FK/IK snap script for the quadruped hind/forleg.
    For the moment i can’t seem to find any solution… any leads?

  41. Hey, it’s on my list of things to do, matching fk to ik is easy, just read the rotations of the ik joints and dump them on the fk, but the other way around is a bit of a challenge. I have fk/ik support built into the cgSpectrum tiger rig, but it’s only precise going in one direction. When I get a chance to implement it properly I can do a post about it, but I’m not sure when that will be.

  42. Hey Shobhit, I haven’t had a lot of time for posting these days, but I’ve been meaning to update this tutorial since my current implementation has changed a bit since I wrote it anyway. If you want to see a working example there’s the example rig, but I know those can be kind of hard to deconstruct sometimes.

  43. Lior says:

    Thanks for the replay Morgan! just seeing it 🙂
    I’ll keep my eyes open 🙂

  44. Shobhit says:

    Thanks for the reply Morgan! I guess my email notification got lost a while ago.

    Yes, now with better understanding I think I can decipher the quadruped leg IKs.

  45. Aritz Basauri says:

    Hi Morgan,
    thanks for the rig solution. Anyhow I can´t figure out how to get the pitch right. I mean when I rotate the secondary hip joint rotates it´s own chain but can´t figure out how to make the spring chain to follow. Could you help on this plis?

    Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *