# Offset Joint IK Setup?

#1

I’m struggling with a solution for a problem I’m sure everyone has faced or will face at some point. I have a typical 3-joint setup to be used for an IK leg. The catch is this: the two lower joints in the hierarchy share the same rotation plane, but the topmost parent is offset from that plane, mimicking a bowed leg structure, where the hip is recessed inward into the pelvis.

hierarchy1.jpg shows the actual pivots of the leg. The middle joint’s rotation plane is vertical, whereas the top joint’s is angled. When using FK, this works fine. However, if IK is applied, the leg will bend inappropriately outward at an angle. The rotation plane of the leg forces it to bend unnaturally.

hierarchy2.jpg shows the setup for an approach I have not found to function. With the IK using the relationship of the three joints in question as the rotation plane, those three joints must be kept in line with the plane of the middle joint (vertical). In this case, another pivot needs to be established (left joint), which will act as the pivot at the hip. This joint needs to maintain a perpendicular relationship to the next top joint in the hierarchy (keeping the distance between the left hip joint and the knee joint constant through all movement).

I have not been able to manage this. Does anyone have any suggestions?

#2

Im confused by your post. So which image is the leg set up you wish to end up with?

If it is the first one I think I may have an idea. If you lay out the IK from the bowed joint(hip) to the ankle which way does the knee flip?

This reminds of a no flip knee set up that can be found in the “Art of Rigging Volume 1” book. The video shows using nodes in Maya to control the “offset” of the IK. Do you happen to have access to this book? I dont have it on me.

#3

I guess I didn’t explain the problem clearly enough. This is not a knee-flipping problem, this is a knee-bending problem. In your average character, the knee will bend towards the hip. If the upper and lower leg are the same length, this will eventually put the ankle in exactly the same location as the hip (this is the way ik tries to solve any 3-joint chain).

My character’s leg is bowed (hierachy1.jpg), so that the knee does not bend toward the hip. Instead, it bends toward the area beside the hip. If using FK, a bend on the knee would never align the ankle with the hip - the ankle would end up next to the hip, but they would never share the same location.

However, when I try to apply IK to this 3-joint hierarchy with an offset hip, the IK tries to force a new rotation plane onto the knee. This would emulate a normal chain (ankle moves to hip), but results in unnatural twisting and bending of the knee joint. (see 3joint.jpg)

The solution (not yet found) would most likely include two hips. The first hip (Hip_A) would be positioned at the true pivot for the hip of the leg, while the second hip (Hip_B) would be offset from that pivot to align itself with the rotation plane of the knee. (see 4jointA.jpg, left side) When IK is applied to the section between Hip_B and the ankle, the bending of the knee joint behaves naturally (see 4jointA.jpg, right side).

Again… however, while the knee is bending properly when the ikHandle moves vertically, the relationship between Hip_A and Hip_B is breaking, regardless of where the ikHandle moves (see 4jointB.jpg, left side). In order to maintain natural behavior on the whole of the leg, two things must happen. First, Hip_A and Hip_B must have identical rotation planes. This allows the true hip pivot to carry the rotations for that section of the leg, which helps the natural motion of the skin on that joint. Second, the distance between Hip_A and the knee must always remain constant. If that distance changes, the result mimicks that of the upper leg stretching. Keeping the rotation planes of the hips identical will keep the distance between Hip_A and the knee constant. — see joint4B.jpg, right side.

Despite my best efforts, I have not been able to solve this dilemma. Given the time, I’m sure the solution will eventually come to me. But, I really don’t have that kind of time. I’ve got other things that demand my attention right now, so I’m passing the puzzle on to the forums. If anyone has a bulletproof solution, I’d like to see it.

Edit:

I didn’t realize the picture attachments on this post don’t carry their filenames onto the web. Just assume that they are posted in the order in which they are referenced.

#4

Im working on a possible solution to this (as i was thinking about it today) - remember:
[ol]
[li]There is always a plane in an ik system with two joints[/li][li]The solution of this plane is not always the reflective of the transform space the joints work in.[/li][/ol]

#5

There’s an easy solution to this. Make the chain prebent in the right direction. This will guide the IK solver. Even a very small amount of bending should help, though in the 5-minute test I just did there seems to be flipping problems if you don’t have enough bending (this is with blender’s solver though). You could also try making a pole vec object for the ik chain; this doesn’t really work with blender’s IK solver unless the chain is prebent, but whatever app you’re using might have a smarter solver.

Joe

#6

I’m having the same problem (but for some reason I had no response). Here the thread I posted just a few days ago http://forums.cgsociety.org/showthread.php?f=54&t=613732

You can lock the rotationaxis on the knee joint, that way you wont break the knee. but that raises another issue, the polevector. Since the plane doesn’t pont in the direction the joints are pointing, the leg will twist un-naturally when moving the ik-handle.

Good to see you on this one eek. Please respond with any progress or thoughts you have around this so we can help eachother out.

Cheers

#7

There two issues:

1. is the plane direction - i.e how the leg bends is crucial to the whole system.
2. How the joint rotates relative to this system.

Now if you have an off-plane ik system - your not really having off-plane ik, more over you have off-transform joint rotation about the rotation of the plane, relative to its direction.

I.e if you want a joint to rotate along its ik plane, then it wont rotate along 1 axis it’ll rotate on 2. This is because the transform space of the child to parent is different it relation to the plane direction.

The plane is essentially in world space, the joints i.e the child (2nd joint) is in parent space, to get it to rotate along this plane would be to rotate in world space.

But this brings up further issues, do you want a joint even if its off axis (in relation to its parent) to rotate about its ik plane? causing it to rotate on 2 axis’

I need some time to think whether you want a ik system with joints off axis, to always rotate about there plane or not. The later is hard to control because you have no real control of the ik goal.

#8

maybe something like this?

#9

Thanks, C.J. That’s exactly what I was looking for. It maintains the structure of the leg without forcing the user to give up control. I applaud you.

So simple, too… It often amazes me how the most straightforward solutions can be lost in a folder full of “failures”.

But, then again… "The story of Edisons lightbulb says he failed 1000 times before having success. When asked about it, Edison allegedly said, 'I have not failed 1,000 times. I have successfully discovered 1,000 ways to NOT make a light bulb.'

Edit:

One thing I just realized, though. The knee joint is positioned properly, but does not maintain the appropriate twist. This is due to the scIK keeping the orientation of the controller it is parented to. A simple constrain of that handle to the knee of the vertical joint chain should fix that.

#10

Looks like I didn’t take a full look before I gave my thanks. While your solution does indeed work nicely, there is one small bit of behavior I needed that isn’t provided in your example. When the leg bends at the knee, and the ankle IK handle is raised directly toward the outer hip, I need the inner hip to not rotate outwards - moving the position of the outer hip and changing the angle of the leg.

The behavior in that area should resemble the second image, right side from the second post I made in the thread. Notice how the leg is bent, but only rotates forward on the inner hip to allow for the knee pushing forward for the bend. When the IK handle moves laterally, nearer or farther from the hip, perpendicular to the rotation plane of the leg, then the inner hip should rotate inward or outward to compensate.

I think I may have a solution, but it needs a little testing, and it’s much more complicated (without being unreasonably so, I hope). I’d still like to know if you have a fix for that.

#11

Howdy,

I don’t know if I understand correctly what you’re wanting to do, but is it something like this?:
http://www.cactus3d.com/OffsetIK.mov

Cactus Dan

#12

I like what I see, Dan. Is that in C4D? If so, how closely would you suppose that setup could be duplicated in Maya?

#13

Howdy,

Yes, it’s set up with my rigging plugins in Cinema 4D, but I think you should be able to do it in Maya, too. It’s basically creating 2 parallel planes. I set it up with a dummy IK system using Null objects (you may have to use joints in Maya for the dummy, as I don’t know if you can add an IK handle to Null objects in Maya), and then constrain the joints to the dummies.

The set up is based on using aim constraints to create a double targeting control system. The Null root of the control chain has an aim constraint on it with a target and an up vector:

Then the target of that Aim constraint is parented to a director object that keeps the target at a parallel distance from the IK chain, by also using an aim constraint:

This director object is parented to the IK Handle.

Then there is also a Pole Vector Director set up that keeps the Pole Vector moving to minimize the IK flip. This uses an Aim constraint targeting the IK handle:

The parallel plane’s Up Vector for the aim constraint is also parented to the Pole Vector Director object so that it moves parallel to the Pole Vector

Then the joints are constrained to the Null objects in the dummy control sytem.

It sounds more complicated than it actually is, as you can see by the object hierarchy on the right side of the images.

I hope that helps.

Cactus Dan

#14

Howdy,

OK, I just tried the same set up in Maya PLE and it works.
http://www.cactus3d.com/OffsetIKMayaPLE.mov

I don’t know if Maya will open a Maya PLE file, but if it can, you can download the file here:
http://www.cactus3d.com/OffsetIKTest.mp.zip

Cactus Dan

#15

Thanks for the contribution, Dan. I had to download PLE to see what your network was like, but I like what you did in your test, except for a few trouble spots. I had problems with the IK as the ankle approached the hip. The leg slowly rolled upwards and inwards toward the inner hip, and the IK wasn’t very controllable at that point. I tried a couple of things to correct it, but didn’t get very far before I found a more critical problem.

With the way the final leg hierarchy is orientConstrained to the earlier hierarchy, the positions are slipping on the joints, which is forcing the ankle joint off the spot where the ikHandle and foot control reside. This was somewhat resolved by another IK on the final hierarchy, but another problem arose. The distance between the inner hip and the knee wasn’t remaining constant.

If it’s not one thing, it’s another…right?

Anyway, your example put some ideas in my head, and I started weaving them together with a mix of C.J.'s approaches and several restless-night ideas of my own, and the attached file is what I ended up with. It fits all the criteria of my original post, without any unwanted behavior that I’ve found (thus far).

I did this example in non-PLE Maya, but I will reproduce it in PLE a little later on so you can see it in action. For now, though, I need to step away from the keyboard and re-energize.

Edit:

PLE version now included in .zip attachment.

#16

Howdy,

Ooops, I forgot the point constraint on one of the joints in my file.

Cactus Dan

#17

If you downloaded the .zip that only contained the .ma file, then you would need to open it in a text editor and //comment out the line that reads ’ requires maya “2008” ; '. The file should open fine after that. If not, then I wouldn’t know what the issue is.

The .zip that is posted right now has been updated with both the .ma and .mp formats, the former having been edited to allow loading into pre-2008 versions of maya. Give it a shot and let me know.

#18

Howdy,

That is a very nice setup.

But, I’m having a bit of difficulty understanding the exact setup, due to my lack of knowledge about Maya. Basically, I’m not sure where to see what’s connected to what in Maya.

Can you give me a quick rundown of it? I’d like to see if I can duplicate that with my plugins in Cinema 4D.