Arm rig FK / IK switching

My goal is to make an arm rig which can easily switch between FK and IK without using scripts (I’d be willing to use pre-made and tested scripts if there is a consensus that it’s the best way to go.)

My first attempt at this has produced cyclic dependencies. Here’s how I’m trying to do it. I have two identical bone chains, one for FK and one for IK, a FK / IK switch slider, and an IK target (let’s call it _target). The FK chain bones copy rotation from the IK bones only if my IK slider is in IK mode. This seems pretty conventional.

Now the part I’m having problems with. I want _target to stay with the end of the FK chain in FK mode. This way when I want to switch back to IK mode I can just key _target where it is, and move the slider. To do this, I add a copy location constraint to _target so that it copies the location of my FK chain. This is all well and good, because it only has influence in FK mode (because in IK mode this would be a cyclic dependency.)

The problem is that blender complains about a cyclic dependency even though the copy location constraint has 0 influence. Is this expected behavior? Is there a way for an IPO driver or such to completely enable/disable a constraint to prevent cyclic dependecies?

So there’s the problem, and I realize this might not be the best way to approach the solution at all, so other suggestions are very welcome.

I can theorize that you drive the FK and inverse IK with a single object, such that when Empty (for example) has RotX=0, FK=1 and IK=0, and when RotX=90, FK=0 and IK=1. That way they will be mutually exclusive.

Don’t know about the cyclic dependency - I’ve always had to resolve that manually.

Yes, you’re correct, they are mutually exclusive, but that’s the problem: Blender doesn’t know they are mutually exclusive (how could it?) Because of this, it complains about cyclic dependencies…

Use too different sceletons to drive your FK and your IK and then copy location from one to the other.

I was dealing with this problem whole summer. And I guess there is not possible solution for this and you cannot over come this without having cyclic dependencies. So script is the only solution for this. I have also studied dozens of tutorials for other 3d apps and they always use scripting for this.

musk, I tried that but it doesn’t fix anything. Putting the bones in another armature object doesn’t solve the problem, it just obscures it and no, it doesn’t fool Blender either :wink:

JiriH, thanks, that seems to be the conclusion I am (reluctantly) coming to also. I’m surprised that there is not a feature to do this without scripting, or even a very popular script that everyone uses to do this. I guess it’s not an easy problem to solve. Oh, well, I suppose I’ll learn Blender python scripting if I get tired of doing it by hand.

Thanks, all!

There you can download my rig, BlenRig. I don´t use scripts, I just use IPO driven constraints to switch between IK and FK. The only drawback is that the pose you´ve set with IK doesn´t remain fixed when you switch to FK, you have to manually snap the IK and FK controllers to match the pose.

Basically, Blenrig uses separate controllers for driving the arm in IK and FK. The forearm has an IK Constraint targeted to and IK controller bone. That constraint is driven by an IPO curve that goes down to 0 when I move one of the bones from the IK/FK panels I made. When that happens, the IK constraint is turned off, and the arm is driven by a targetless constraint applied to the child bone of the forearm, so the arm becomes FK with an optional targetless IK constraint.

Well, I set up the system for you with the test.blend you provided in the other post.

If you move the green Bone to the right you will switch to FK.

The IK controller is the blue bone, and the controller for FK is the orange bone.


test IKFK.blend (180 KB)

jpbouza, thanks for your responses, and the set up you made. I think, however that you’ve misunderstood what I wanted, so probably I wasn’t clear enough. The other post I made with the test.blend example was a separate issue, and not related to this. I already, had made the setup you described in your post (though it will probably be useful to people reading this thread.)

What I wanted was actually a way for the IK target to stay with the FK chain in FK mode. This way when you switch back to IK mode, the IK chain is already positioned (more of less) where the FK chain was, and no jumping occurs. Currently I have to manually position the IK target to the end of the FK chain and it’s inconvenient.

I got close (kind of) to a solution to this by putting a copy location constraint on the IK target to copy the location of the last FK bone in the chain. This constraint was only active (influence = 1) in FK mode. However, this gave me cyclic dependencies even when the constraint had influence = 0. As far as I can tell there is no way to have a “driver” object turn a constraint completely on or off (to avoid cyclic dependencies). The only way as far as I know is to set the influence (but this does not avoid cyclic dependencies.)