Hi,

I try to build a non flipping knee Ik leg based on a maya tutorial.
Its seem to be somehow different to find the right way to convert the joint workflow to bones. Are there any tips or hints out there?

Thanks

not sure if you are asking about general tips, but if you are asking about how to stop knee flipping with IK, you can add twist affector to InverseKin CHOP, which is essentially up-vector defining the plane of ik solve
then just use twist affector to orient the knee, additionally you can use IK Twist parm to affect knee direction as an rotational offset from direction defined by twist affector

Thanks Tomas,

I looked for a little advanced setup. No flipping knee in more then one direction.

something like this… dont no by now if this is as robust as the maya leg!

advanced setup is more of the rigging approach question
since even your setup flips easily when you deviate more in x axis, sometimes it's better to have full control over knee direction than trying to automate everything, animators hate too clever rigs, because they most often need more control

but if you point to the link of your reference maya tutorial, then we can talk about some conversion possibility

http://www.scribd.com/doc/35580059/Art-of-Rigging-Vol-I-Book-CG-Toolkit [scribd.com]

The setup starts on page 17 of the book. Thanks for the support!

I haven't looked at you tutorial link but here is my solution I made in Houdini couple months ago
http://www.mediafire.com/?5z0zgsyln3tb9mb [mediafire.com]

mantragora…i'll give it a try. thanks

mickyblue
http://www.scribd.com/doc/35580059/Art-of-Rigging-Vol-I-Book-CG-Toolkit [scribd.com]

The setup starts on page 17 of the book. Thanks for the support!

Ugh. 18 step tutorial without a single sentence on how the overall setup is supposed to work! From what I can tell, it is some variation on parenting the twist controller so that it is always offset from the average position of the chain goal and chain root.

edward
From what I can tell, it is some variation on parenting the twist controller so that it is always offset from the average position of the chain goal and chain root.

That's exactly what you think and what I put in my example above. You can move chain goal anywhere, rotate it 360(or even full sphere) and twist will follow not allowing for knee flip.

To create a reverse foot set-up leg in Houdini is pretty straight forward. The options in constraining the bone chain's orientation is wide open. I agree with Ed in that the steps in the Art of Rigging require that you use Maya and visually inspect various stages of the set-up. It's pretty easy to see where they're heading though.

—-

One test for a flipping leg is to take the foot control and lift it upward past the root of the hip and see what the leg does. This tests the leg rig itself. The foot and look at IK constraint mainly along with the rest angles.

Another test is to parent the character hierarchy and tumble it in space and watch what the limbs do. The limbs should properly orient themselves as the character tumbles about. No flipping.

Houdini rigs when set up well will pass the above two tests easily with decent bone (locator/joint) orientations.

Houdini's ik solver and ik handle don't have a pole vector option that works on joint anchors and joints as Maya does.

Each bone has it's own local orientation. Not joints with aim constraints to locators. Locators/joints (Maya) vs. Bones (Houdini). Doesn't really matter as both can be used to great effect in constructing simple and complex constraints in your rig to give the Animator what he/she wants, as that is all that matters.
If you really want free oriented “joints” in your bone chains in Houdini, you can parent Null objects between bones in an IK chain and rotate them to any orientation if you need to.

To bind a bone to an IK solver, it has a path reference to a specific Inverse Kin CHOP that drives each bones transform (local rotates). Constructing Bones with the Bones Tool in the viewport set to IK or FK will do this all for you. Great way to study how the Inverse Kin CHOPs are set up to drive bone chains.

The parameter interface of the Inverse Kin CHOP which is used to solve the kinematics for a given chain of bones is where you need to look. Everything ultimately has to be fed in to these Inverse Kin CHOPs.
First, you need to supply the root bone and the last bone in the chain.

As far as the twist is concerned, you supply an actual object where it's world space calculated (cracked) position is used to aim or constrain the bone chain. Not a pole vector using Euler rotations.
There is an additional Twist parameter that can be animated on top of the aim constraint Look At object for tweaking in the Z pole direction of the constraint.

Given that Houdini's Inverse Kin CHOP doesn't have a pole vector Euler rotates, the setup is going to be different.

How you construct the location of this Look At IK constraint object is up to you as long as you avoid an infinite feedback loop commonly referred to as recursion.

Mickyblue's file is a clever one where the root of the ik chain has it's look-at constraint set to the foot end chain constraint on top of which the look-at object is parented to and referenced by the Inverse Kin CHOP. The look at twist object is parented to the root of the chain and simply moved down and out. It's rotates are not considered so you can safely zero them out in Mickyblue's file. Recursion is avoided because no bone in the chain or any parented children are the target of the root look-at constraint as the world space chain goal foot control has no parent (in Mickeyblue's file).

This leg rig behaves quite well when you pass the foot upward and above the root but it will only pass the tumble test if the foot control is rotated along with the chain root. With the foot control unparented to anything, it is in “world space”. It is common to put a top level root null object and parent all these loose world space position-type controllers to this null so you can package up the character in an asset and survive the tumble test.

There are quite a few other Look-At constraint set-ups I have seen over the years, each driven by what the animator wants. If you want to have a similar set-up to the one in the Art Of Rigging book where you locate your aim constraint such that it is the average of the foot and hip, you could do this with a Blend Object (there are many other ways if you don't like Blend Objects). I took Mickyblue's example (after adding two additional nulls as roots), copy/pasted his hierarchy and then added the Blend Object to do a similar method to using a Hypershade network to calculate the average position along with a foot look-at to get a local pole vector then parent a lookat object to satisfy the demands of the Inverse Kin CHOP.

Both these leg rigs will allow you to put the leg end effector wherever you want and get predictable no-flip legs. Well within reason. If you pass the foot right through the leg root, you will get flipping no matter what but move it away just slightly and Houdini's IK solver is about as good as it gets in delivering a good final solution.

There are quite a few advanced set-ups that you can construct but I am of the simple=better crowd. But if your animators kick and scream for a specific rig because they are used to seeing animation curves in a very specific way along with translate vs rotate controllers for various parts of the rig, then you have to build in more complexity to make their lives easier, but more than possible in Houdini.

Thanks Jeff!

Is exactly what I was looking for! I know there are a lot of ways to solve this one. And yes the Animators should not be left out. But I heard a lot of good things about this Book, so I try to mimic the production oriented approach and naming conventions, as close as possible.

Yes I have the book as well and agreed that there is a lot of good info in there.

Everything in there can be worked up in Houdini sometimes with different workflows. Ask away if you run in to other areas.

Nice explanation. But this part made me a little…

jeff
Mickyblue's file is a clever one where the root of the ik chain has it's look-at constraint set to the foot end chain constraint on top of which the look-at object is parented to and referenced by the Inverse Kin CHOP. The look at twist object is parented to the root of the chain and simply moved down and out. It's rotates are not considered so you can safely zero them out in Mickyblue's file. Recursion is avoided because no bone in the chain or any parented children are the target of the root look-at constraint as the world space chain goal foot control has no parent (in Mickeyblue's file).

hmm… confused. Are you sure you are talking about the same file that Mickey posted here ? I'm digging it and can't see it there . True to be told, it's a little late so my eyes may be a little burned right now.