The IK/FK Switch in Maya

Hey All,

I just made a little blog post about the different ways to do an IK/FK switch in Maya here.

Here’s what I concluded and I was hoping for people to chime in and say more ways to achieve the IK/FK switch in Maya:

I’ve been doing some research on IK/FK switching solutions for Maya because I think it is one of the more interesting and practical problems to encouter while Rigging. I have found 4 different methods to achieve a seamless IK/FK switch in Maya.

  1. Use HIK in Maya or use another middleware/plugin. HIK is a probably more powerful than anything you would make on your own, but, you have to do it their way and use HIK for your entire rig to take advantage of it. It also only works for bipeds.
    [ul]
    [li]Documentation: http://download.autodesk.com/global/docs/maya2013/en_us/index.html?url=files/GUID-945BCFFE-A772-4D52-87B8-FCFC50C974FB.htm,topicNumber=d30e282498
    [/li][li] Video: http://www.youtube.com/watch?v=394qaUPDZ4U , http://www.youtube.com/watch?v=blLBRmNA3zI
    [/li][/ul]
  2. Create 3 different bones, make one IK, leave one alone (FK) and then orient constrain the third to the IK and FK bones respectively. You then use Set Driven Keys to lerp between the two. This solution isn’t really ideal for real time due to the addition of 6 bones for each ik/fk switch you want to include on your character. It is an easy solution that has the potential to produce some decent results.
    [ul]
    [li]Brian J. Immel does a nice job describing it here:http://www.jawa9000.com/Technical/fk-ik-arm/fk-ik-arm.htm
    [/li][li] Tyler Thornock describes it here as well: http://www.charactersetup.com/tutorial_ikfkarm.html
    [/li][/ul]
  3. Create a button that switches between IK and FK. The button takes the transforms from either FK or IK and then enables or disables IK and passes the transforms back into your joints and pole vector position.
    [ul]
    [li]Lionel Gallat describes the process here: http://seithcg.com/wordpress/?page_id=30
    [/li][/ul]
  4. Use scriptJob to have everything done automatically for you. This is the most complicated but in my opinion the sexiest way to do an IK/FK switch. It would take me a while to describe so I’m not going to bother. *There may be performance issues with this method as well because of how many times scriptJob is called so take note.
    [ul]
    [li]Here is an extensive video series where Chad Robert Morgan talks about the script he creates to make everything automatic: http://www.youtube.com/watch?v=KNfSG1DEj58&lr=1
    [/li][/ul]

Also, checkout this thread on Automatic IK/FK switch which is in a similar vein but I think more specific, hence this thread: http://tech-artists.org/forum/showthread.php?1451-Automatic-FK-IK-switching-in-a-Maya-rig.

If you have another way to do it or preferences about the methods I found, comment below!

what I like to do is use the built in ik blend with one chain and create an attr for visibility and using a float value instead of enum so it minimizes popping for a smooth transition. I havent had any problems yet. :slight_smile:

Have you had any feedback from animators? I tried animating some stuff and it was a little unintuitive, in terms of what I was expecting to happen. I didn’t implement your custom visibility attr though because I didn’t really understand what I was hiding. Could you explain what the animation workflow of this would be?

Hey thanks for the links, by the way…

I added a visibility attr to the arm control to hide the FK when ik blend is at 1, and when IK blend is at 0, it hides the IK. Also, hiding the pole vector for the arm when it was in FK through the connection Editor as well.
Connecting the IK blend at 1,(IK) to the visibility of the FK controls to 0 or off. and ikblend to 0(FK) and the IK control vis to off, etc. This method also helps keeping the joint numbers down in a game engine. The animator I worked for thought it was useful, and approved the rig with that system, unless he was just lying ;).

Here is more of a visual interpretation, I hope this helps!

What part of your method keeps joint numbers down for the game engine? Whatever the rigging solution is the export skeleton is usually constrained to the control rig so using a different rigging technique shouldn’t effect the number of export bones.

Personally I prefer a direct switch between IK and FK and not a blend, as the key range during which the blend is occurring becomes more difficult to have precise control over the position of the bones as they are partially weighted to both IK and FK controls. With IK FK blending I often find animators setting keys next to each other to stop this from happening, which could be reduced to a single keyframe using other solutions.

[QUOTE=snoutling;16928]What part of your method keeps joint numbers down for the game engine? Whatever the rigging solution is the export skeleton is usually constrained to the control rig so using a different rigging technique shouldn’t effect the number of export bones.

Personally I prefer a direct switch between IK and FK and not a blend, as the key range during which the blend is occurring becomes more difficult to have precise control over the position of the bones as they are partially weighted to both IK and FK controls. With IK FK blending I often find animators setting keys next to each other to stop this from happening, which could be reduced to a single keyframe using other solutions.[/QUOTE]

My bad, that does make sense, I heard of this method from some masterclass from Autodesk, and the dude said something about joint count and not liking the 3 chain system because of that reason.

Hi guys,

you can also use a blend node inside maya to have a nice blend between two identical joint chains(FK/IK).
FK-chain <-> blend node <-> skeleton chain <-> blend node <-> IK-chain.

I also don’t get it why you’re considering the bone count. Only the target skeleton gets the animation in the end.

Animating with any of these solutions will quickly reveal both pros and cons about them. I you’re thinking of putting these in a production environment, I would suggest trying that out, or at least gather a few opinions from animators with experience. Usually, stability and usability comes first, performance second.

Sorry for the delay, got busy there.

[QUOTE=markorenic;16926]Hey thanks for the links, by the way…

I added a visibility attr to the arm control to hide the FK when ik blend is at 1, and when IK blend is at 0, it hides the IK. Also, hiding the pole vector for the arm when it was in FK through the connection Editor as well.
Connecting the IK blend at 1,(IK) to the visibility of the FK controls to 0 or off. and ikblend to 0(FK) and the IK control vis to off, etc. This method also helps keeping the joint numbers down in a game engine. The animator I worked for thought it was useful, and approved the rig with that system, unless he was just lying ;).

Here is more of a visual interpretation, I hope this helps!
http://vimeo.com/28286452[/QUOTE]

Thanks, understand it better now. You’re welcome for the links.

[QUOTE=castortroy;17079]Hi guys,

you can also use a blend node inside maya to have a nice blend between two identical joint chains(FK/IK).
FK-chain <-> blend node <-> skeleton chain <-> blend node <-> IK-chain.

I also don’t get it why you’re considering the bone count. Only the target skeleton gets the animation in the end.[/QUOTE]

Thanks for sharing! So you’re saying that regardless of solution in Maya, whatever is imported into the engine will be just applied to a single skeleton?

Oh jeah, only the target skeleton has the mesh bind to it and this only will give you the direct feedback. :wink:
The animators do work on the control rigs(skeletons,controls whatever you create for them) and for the engine export you plot/bake/sample the data down to the target skeleton and export this one into the engine(cryEngine, UDK, whatever).

Example:
character export skeleton -> 50 bones
control rig -> it does not matter how many bones or controls you have here, as long the control rig gives you more power and access and usability over animating straight in FK on the export skeleton :wink:

I suppose that makes sense if you think about it, thanks!