Rigging in Maya: Recursive Constraints and FBIK
polycounter lvl 18
I've been trying to push myself into learning some of Maya's more advanced features recently, and I'm kinda stuck on the subject of rigging. More specifically, the adding of additional controls to the rig, and getting those controls to all play nicely with each other.
It seems inevitable that, no matter what I try to set up, I eventually come to the point where I want two controls for the same object and therefore, when the object is modified by one control, the other should follow. This obviously does not work in a purely mathematical sense, as object A changes object B's position, which changes object A again, etc. The generic solution is to animate the constraints, which seems to me basically throws the whole 'ease of use' concept out of the window: you'd be better off not even bothering (which seems to be the course most 'sample rigs' I've downloaded and inspected take)
On the other hand, the Full-Body IK (FBIK) setup manages it somehow, though I can't figure out for the life of me exactly how that whole thing works. I'm sure I've seen similarly interactive rigs before as well. I could just use FBIK, but I'm loathe to use anything I don't fully understand, especially since most rigs need at least a few custom bones or controls (or could use some paring down).
I understand that most animators keep things pretty simple, but ignorance never helped anyone. Any solutions? I'm not afraid to dive into MEL for this, but would like some direction before I go digging through the documentation.
It seems inevitable that, no matter what I try to set up, I eventually come to the point where I want two controls for the same object and therefore, when the object is modified by one control, the other should follow. This obviously does not work in a purely mathematical sense, as object A changes object B's position, which changes object A again, etc. The generic solution is to animate the constraints, which seems to me basically throws the whole 'ease of use' concept out of the window: you'd be better off not even bothering (which seems to be the course most 'sample rigs' I've downloaded and inspected take)
On the other hand, the Full-Body IK (FBIK) setup manages it somehow, though I can't figure out for the life of me exactly how that whole thing works. I'm sure I've seen similarly interactive rigs before as well. I could just use FBIK, but I'm loathe to use anything I don't fully understand, especially since most rigs need at least a few custom bones or controls (or could use some paring down).
I understand that most animators keep things pretty simple, but ignorance never helped anyone. Any solutions? I'm not afraid to dive into MEL for this, but would like some direction before I go digging through the documentation.
Replies
What exactly do you need the different controls to do? This will be helpful in doing a more complete write-up, as I have a ton of notes from my maya rigging class.
[/ QUOTE ]
Does it really matter? I thought I was pretty clear, but basically this goes for side-by-side IK/FK controls without having to change/animate a blend value, or for a more specific example, reverse-FK on the foot, where I'd like to be able to:
- Rotate the whole foot from the toes, heel or ankle points
- Rotate the heel and ankle up from the ball
- Have a separate floating control for misc toe movement
'Recursive constraints' pretty much covers everything though, as it's the root of the problem: Two controllers which need to move each other. In the foot situation take the toe and heel controllers: You rotate the foot with A, B must be included through some connection-- direct or indirect, literal parent or parenting constraint, and thus moving one moves the other ad infinitum, the whole thing explodes.
It's a pretty basic limitation, so if no one knows offhand, I expect a solution may not be common or efficiently usable-- or I'm missing something obvious and I've overcomplicated the issue and blown it way out of proportion until noone recognizes it, I do that.
Of note: The FBIK system will re-place controllers attached to overextended IK handles the next time you touch anything on the rig (similar to respecting the IK handle's Stickyness setting), so it seems like it must be doing some sort of manual repositioning. I'm fairly certain the only thing truely 'custom' about the FBIK system is the IK solver, which I don't think should affect this, so it should be reproducable if anyone actually understands the forest of nodes that makes up the rig, even if one needs write scripts to set it up.
As for the FBIK, I've never really heard any animator talk about it as a viable character animation solution.
from the 3 bullet points you have, i have a fairly easy way of doing all of those, but most standard industry rigs(both movie and games) have 1 foot controller with attributes that cover the things you wish to do.
for example, the way i'd hook up those things is by creating groups. the ankle IK would be grouped to itself and the group name would be something like Peel_Heel.
the ball and toe IK would be grouped and named Toe_tap or something.
the toe tap and peel heel groups would be grouped and named Toe_Pivot.
then the toe pivot would be grouped(with itself) and named Heel Pivot.
so your heirarchy would be:
Foot Control
-Heel_Pivot
---Toe_Pivot
----Peel_Heel
IKHandle#
Toe_Tap
IKHandle#
IKHandle#
then hook all that shit up with driven keys and you're good. if that seems like what you want, I can do a fully detailed write up. that should get you all the foot control you could need though for your standard stuff. if you want hyper real stuff, you can go further. <u></u>
i cant help you at all.
animatr: As far as I can tell, groups have the same problem as any other type of parenting constraint: in your example for instance, you use the peel_heel group, then toe_pivot is invalidated because it no longer exists where the heel currently is. If you meant that driven keys should solve that then I'd like to hear it-- as far as I can tell you can't create conflicting driven keys any more than any other constraint method. Though rather than exploding as parenting does, it seems to simply use the last one whose curve attributes you changed.
aesir: Yeah, FBIK seems to be Maya's version of Biped, which is kind of annoying. If they can program it, they should give the tools to us to make our own rigs.
Anyway, sounds like a dead end for the easy way (recursive constraints). I'd still be interested in hearing about how these things are usually dealt with with the tools we have though. I suppose you just don't use two controls at the same time
[ QUOTE ]
[...]for a more specific example, reverse-FK on the foot, where I'd like to be able to:
- Rotate the whole foot from the toes, heel or ankle points
- Rotate the heel and ankle up from the ball
- Have a separate floating control for misc toe movement
[/ QUOTE ]
How is this all not easily possible with a simple reverse FK foot setup to control the IK handles? Everything you want here can be controlled using a single controller and a couple of attributes, although I'm not 100% no what you're looking for with the last of those three, but I expect that's the easiest of the three.
[ QUOTE ]
Does it really matter? I thought I was pretty clear, but basically this goes for side-by-side IK/FK controls without having to change/animate a blend value, [...]
[/ QUOTE ]
That however is entirely different from the above. IK and FK are two entirely seperate kinds of control that thankfully can be blended very well in maya. I personally can't see how a system that uses both FK and IK without the need to animate any kind of blend would even work as an animation system. You always have to tell the rig whether or not it should interpollate up or down the hierarchy.
There's an ancient post on CGtalk, maya character rigging forum, that deals with this. It cites Mirai's system as an alternative which does what you want to some extend, but has the interpolation trouble which basically makes it a very primitive way to animate with. here you go: http://forums.cgsociety.org/showthread.php?f=88&t=58455
As you said in your first post, just keep things simple. I guess everybody tends to overcomplicate their rigs to make them mathematically most competent for what you're trying to animate, but this can usually be solved easily with some seemingly tedious hand-keyed animation which probably ends up better looking in the end anyway.
I'll re-read this tomorrow, and see if I can set something up for you, as I feel like my visual cortex is about to go on strike and it really isn't parsing information well at all right now.
From what I understand after just reading it, the IK is triggered by moving the IK controller (which is linked to the FK setup) away from its 0,0,0 position. The only downside is that in order for the FK to work again - for as far as I understood - the IK controller has to be back in it's default null position, so you can't just switch from FK to IK, then easily continue in FK from that IK pose... but I won't research that until I have to build another rig. It sounded like a pretty sweet solution.
Oh and as for:
[ QUOTE ]
- Rotate the whole foot from the toes, heel or ankle points
[/ QUOTE ]
That indeed is slightly trickier. I misunderstood what you were looking for the first time reading. While the heel and toe control are pretty much the standard function of the inverse foot FK setup to control the IK, the ankle indeed actually is a lot trickier if you want to control the rotation of the whole foot with it.
Still, I still think trying to get such a setup to work is too much of a hassle compared to the relatively simple solution to just animate it by hand using the 'default' inverse foot setup.
Vailias: Anything you could come up with would be great, though these things seem to have a way of being more complex than they seem
1) Stretchy Spine w/ controls
2) fk/ik arm w/ controls
3) clavicle rigging w/ controls
4) leg rigging w/ controls
The controls on the fk/ik arm behave similar to how I assume Asthane wants the controls to behave, where one control can rotate the arm at the elbow while the control for the wrist moves with the wrist and is still able to control it without creating a feed-back loop.
thanks