Approaches for setting up ik/fk blending

[Fongool]

After watching the latest installment of Lucas Martell's Pigeon Impossible podcast, I'm curious about the approach of building multiple rigs on top of each other, one for FK and one for IK and then setting up blending between them.

I've also seen this approach in some rigging tutorials, so clearly Lucas isn't the only one doing this. But, if you select a bone chain, ctrl+r reveals that XSI natively has a slider in the chain properties for ik/fk blending.

So what I'm wondering, is the multi-rig approach a workaround for ver. 5 limitations? Or are there drawbacks to using the native slider that the layered rig approach avoids or is there some other reason why building multiple rigs right on top of each other is advantageous over using a single rig with the built-in blend slider?

Or am I just dumb and completely missing some basic understanding of ik/fk blending? (very possible!) :)

I'm fairly noobish and trying to absorb as much rigging theory as possible, so it's as important and facinating to me to understand *why* people approach things the way they do as it is to understand how they set it up. :)

Thanks,
Steve

[xzof]

You raise an interesting question. I wanted to make a topic on this, in the Pigeon Impossible xsibase.com forum's topic, but finally I didn't. When I was using Maya, I tried to make one arm rig with both ik and fk to get a more simple stuff to build. The IK solver and effector aren't powerful enough so I didn't find a way and I had to use a 3 parts blending arm rig. I was also searching a way to get rid of the blending option, but finally, i think it is necessary because you have to key times you get ik or fk. When I jumped into xsi, I saw this ikfk option inbedeed in the bones, and finally I found it !!!! So now, I use one part for the arm rig. I just have to connect this option with the controllers visilibty and script a little matching position code to make it works perfectly. For the legs, it's a bit more difficult. The foot roll system make the legs much more connected with constrain and parenting connections than the arm. It's more difficult to modify all these connection without making errors, than make a 3 part for the leg rig. So I use this older heavy and tiring system.


But, in conclusion, in rigging, XSI > Maya haha

Sorry for my bad english, i'm still training myself

[3DMastermind]

IK/FK blending is innate in XSI and works really well and is very reliable and "light".
You can use ctrl+r on any chain element to reveal the slider.
Many prefer 2 separate systems for IK/FK perhaps for added flexibility like separate "bone length" or to be able to edit both IK and FK chains.
This comes with extra eval cost though = slower playback all the time.
Out of the box, you can enable fk/ik ghosting (below the blending slider) and enable skeleton ik/fk ghosting (on the viewport) to see the separate ik/fk ghosts.
Prsonally, a separate system is only essential when you need to switch between ik/fk which is rare in the first place.
To me "playback speed" is more important which is why i would stick to the default blending.

[Fongool]

Thanks for the replies guys!

xzof: can you fill in some detail about what problems you've encountered with the legs that cause you to do them with multiskeleton approach as opposed to the arms?

Manny: You make it sound so simple! :) Is it really just a matter of choice, or does rig complexity get involved in this at some point? Are there limitations to some rigging approaches with the built-in method?

You mention maybe someone wants the bone lengths to be different, but I (in my admitted vast ignorance) would think something like that would be extremely special case and in the vast majority of cases the two skeletons would be identical.

Or is it more like xzof is suggesting that at some point it's just somewhat easier to build it with multiskeleton approach (for example the scripting starts to become convoluted and more difficult otherwise or something). And it becomes an issue of balancing rigging labor vs. feedback speed?

Hopefully my questions aren't too dumb! Thanks again for educating me on this stuff! :)

[3DMastermind]

No limitations.
Under the hood, it's the same thing.
perhaps workflow is different.

On a typical xsi chain
set slider to FK (there is no need for this step since the slider is usually there if you do FK)
key bones (FK)
set slider to IK
key chain effector and up-vector (IK)
key blend slider

On a separate chain system:
key IK chain effector and up-vector (exposed)
key FK bones (exposed)
key slider to blend.

There may be an extra step in the first method.
But it does not justify for the overhead necessary.
Also, all those chains get in the way which is why I find the first method cleaner and that's cause the logic is already there in the 2D chains in XSI.

If someone can come up with a logical example as to why they work with a separate ik/FK chain system.
I'd like to know.

[Fongool]

Thanks Manny, this is exactly what I was thinking as well, but lack the experience to know for sure on my own. :)

[Serguei]

The built in ik/fk slider is not flexible enough for a more complicated rig. With 3 bone approach I get to control how, when and why my blend happens. This allows me to deal with things like stretchy limbs, breakable joints, locking elbows and etc much easier than with the default blend.
In my latest system I didn't even use bone chains for my FK chains as that’s just adding unnecessary overhead.

[Fongool]

Thanks Serguei! Now things are getting interesting! I'm especially interested in breakable joints. I was considering using secondary deformations with curves or possibly blend shapes or something to imitate this effect because I wasn't exactly sure how you'd go about setting this up with traditional rigging techniques without risking IK weirdness. Or do you generally just do that entirely with the FK side?

Did I just answer my own question? :sweatdrop:

If so, I have more! :D If it's not too much trouble, could you detail a little more what sort of problems you would encounter if you used the built-in blend? Or is it as simple as not being able to have unique properties for each "mode", such as breakable joints simply not being possible with a bone chain set up to work with IK? (like your example of not even using bones for the FK at all?)

Did I just answer my own question again? :pinch:

[Serguei]

Well a simple example would be that when you are doing stretchy bones you have to use a controler other than the effector for the IK goal. So right there you're already stepping away from how the built in blend is designed to work and opening up room for the solver to screw up. And the more constraints/scops you start adding the more there is room for things to go wrong. In which case the 3 bone approach makes it much easier to debug as you control all the elements.

The reason I don't use bones for FK is because bone chains come with extra stuff like root/effector/solver none of which are required to get FK. Also if you're doing stretching on FK doing it on a bone chain is incredible pain! So why over complicated what is rather simple hierarchy :)

[franky]

i can only agree with Serguei, i am working on a autorigger that spits out a stretchy rig since quite some time now (its being used for a game pipeline) and in my early evaluations i also tried the internal ik/fk blend.
its working fairly well (different workflow as manny wrote) but ok.
things get out of hand if it needs to be more complicated like stretch, volumes and pinned limbs. then you need layers on top of a basic ik chain to keep control over things.
the rigging demos you see and which shine with benb bows (curved limbs) or pinned elbows, fingers etc... all need additional chains or elements to pull that off.

i found the way to build rigs in layers most transparent and still fast. if there is no or little scops involved its pretty fast all together. in the end the envelope is still the performance killer. so i f you can just animate with a broken up version of the mesh (just parent parts to the skin bones) or with a stand in it helps a lot.

[ViCoX]

Sergueli, I`m interested of your approach. Could you explain how this 3 bone ik/fk system works in more detail? How do you handle the blending? Sorry, Im not very good with this stuff yet! : )

[Serguei]

It's pretty straight forward really. You blend using constraints between the two targets, the FK and IK. If you want to blend in one frame and with no snap you need to match the two targets to each other before the switch which you would put into an event that happens when you click switch button of some sort in your UI.

While doing this dynamically would be desirable this proved to be very touchy and unstable so I went with an event based approach.
This however was probably linked to a bug with transforms in XSI that plagued the version I was writing this for at the time. So it would be good to try again.

XSI naturally hates cycles. Even if you use a switch board approach to make sure there are no cyclic dependencies happening at any one time the connections that create the cycle seem to rattle XSI enough to break your setup.