Fk/ik switching problem

[goemon]

i'm building a rig where a control arm is driven by either an fk arm, or an ik arm, depending on the value of an external attribute (0 = fk, 10 = ik). my hope was that i would be able to transition the control arm from the ik arm position to the fk arm position with the attribute slider.

here is the problem: even if both fk and ik arms are straight, if the attribute which drives the weight of the point and orient constraints that influence the control arm is set to a combination of ik and fk (5 for example- a 50% blend of fk and ik), the ikhandle attached to the control arm begins to contract.- again, even if both the fk arm and the ik arm are straight (elbows straight). does anyone know whats going on?

secondly, with the fk ik switching tools in maya, is this kind of a rig even necessary? my thought was that with this kind of rig i could blend from fk to ik as opposed to just being able to turn the ikHandle on and off.

thanks for any advice.
squanto

[gmask]

This has been solved in Maya 5 with the addition of a blend attribute for the IK/FK switch.. they should have added that in the first place as a switch is pretty much useless. Otherwise you have to make a duplicate of that part of the skelton and use contraints to get the same functionality.

[goemon]

yes, i've set up the rig with multiple arms as a work around for the lack of an ik/fk blender node. what i can't figure out is why the ikHandle contracts when my homemade blender is set to 50% (or some other mixed percentage) AND the two driver arms arent in the same position. both driver arms- the ik and fk are straight at the elbow. i don't think its the pole vectors, as they are positioned directly behind the shoulders- unless there's some problem with having more than one pole vector target for an ikHandle.

squanto

[goemon]

i think i figured it out.

because its a blend of point constraints which drive the wrist, its always going to move the wrist in a straight line from fk to ik, thus requiring the ikHandle to 'shorten' part way through the transition- in effect, bending the elbow. now. . . how to deal with that problem. . .

thanks for the heads up on maya 5- i cant wait!

squanto

[joojaa]

MAke sure the bones are not allowed to scale...

but offcourse there are many ways of doing the actual switching. one can use blend shapes wich is bad one can use constraints wich works better but is more painfull to do. one can use expressions etc etc.. The key is to actualy manipulate the bones rotations (and perhaps scale if you need some bone to actualy do that most setups wont however) not their position!

[nonquad]

now. . . how to deal with that problem. . .

I do my arm IKFK blends with math nodes; multiply divide nodes blend the rotations of each joint in the chain, per channel. It's about as failsafe as you can get; at least as long as the chains are identical to begin with. Alternately you could have your final arm driven by dual-weighted orient constraints, but I find that the interpolation on that system tends to wig out, which defeats the purpose.

Math nodes are the sure fire way to do it; I'd wager that it's effectively the same way maya 5's blending works. But as I haven't used 5, I can't say for sure. Anyway, rotation channel blending is kind of slow to set up for each joint, but if you make a script for it, you never have to worry about it again.

[goemon]

thanks for the tip on using math nodes. it worked beautifully.

unfortunately, i couldn't figure out how to use the math nodes, so i just wrote it all out in expressions.

how do you get more than one input into a 'plus minus average' node? when i try to add a second input- which it seems is how it's supposed to work, it bumps the first input out.

thanks again- it was a big help

squanto

[nonquad]

Well, the connection editor is supposed to give you a context menu when you right click on the destination attr; and from that you select "connect next available".

For some reason, the context menu often doesn't work. But you can still make the connection manually

connectAttr -f object.attribute plusMinusAverage.input1D[X];
where X is the next available input. Works the same for all nodes that will take a list of inputs.