Blending source joint chain betweeen two destination chains causes un intended rotation

So I have created a tool for blending between 3 joint chains.
one source FK chain, and 2 types of IK chain.
The model will be bound to the source FK chain. and is constrained by controllers.

here is an example of blending between the 2 IK chains.
through a node called Type Blend

however, when I try to blend FROM the FK chain to either of the IK chains I get some really bad rotations happening.


for the straight-out IK it’s all of the rotations.
for the second switch it’s only on the top joint.
Does anybody have some idea why this is happening?

all joint transformations are frozen as well.

here is the script I made to create the joint blend maybe there is something wrong with that.

1 Like

Best guess? You need to set the .interpType value for the orient constraint.

(Yes, this is the 2011 docs, but that’s what google brings up, and I’m pretty sure it’s still the same)

interpType (int)

Interpolation type, used when weighting between more than one target. When there is only one target, no interpolation is used and this attribute is ignored. The meaning of the types of interpolation is as follows:

  • No Flip When constraining between multiple targets, this attribute prevents flipping. Since this attribute is dependent on the previous frame, it requires a runup to provide consistent results, or a cache can be created using the Create Cache button in the orient constraint attribute editor.

  • Average The quaternion average. This setting can cause flipping since the previous result is not taken into consideration. Use the “No Flip” setting in order to prevent flipping.

  • Shortest Use the shortest path between the targets.

  • Longest Use the longest path between the targets.

  • Cache Use the cached result.

1 Like

Instead of using point and orient constraints and blendColors nodes, you could use a pairBlend node with its rotInterpolation attribute set to use quaternions. It’s a simple, local space blend of translate and rotate values but it should be simpler and more reliable than what you have now.

BTW, you don’t have to set and connect your float3 child attribute values individually, you can set them with one line of code.

FKR1 = fkIkBlend+".color1R"; FKG1 = fkIkBlend+".color1G" ;FKB1 = fkIkBlend+".color1B"
mc.setAttr(FKR1, 1); mc.setAttr(FKG1, 0); mc.setAttr(FKB1, 0)

could be:
mc.setAttr(fkIkBlend + ".color1", 1, 0, 0)

1 Like

Best guess? You need to set the .interpType value for the orient constraint.

yep, this is probably going to do this trick. Really excited to give this a go.

Instead of using point and orient constraints and blendColors nodes, you could use a pairBlend node with its rotInterpolation attribute set to use quaternions.

that is going to require research on my part. I think for this character I have to go with tfox_TD’s response, but this is probably what I will implement in my auto rig script for future use.
very nice solution indeed.

the frustrating thing is the mirror of that chain works perfectly fine.
I really wonder why the default rotation constraint is so unpredictable like that.
what makes it decide its a good idea to rotate a full 360 degrees?

just a quick update.
changing the interp type to shortest solved the problem like a charm.
so easily that I decided to spend some time researching pair-blend nodes.
now I am rewriting the script to incorporate all of @chinwagon 's suggestions.

and also to @tfox_TD your solution was fast and easy and made my demonstration to the directors today really smooth.

can’t tell you how much I appreciate both of your replies. thank you so much.

Glad to hear we were able to help out!

Also, the “why” of flipping like this comes down to the fact that there’s no way to do a conversion between matrices, eulers, and quaternions that is perfectly continuous in all cases. So programmers hide the flips in the cases that users are least likely to reach, but then they give you a choice so your particular use case can avoid them. If you want to go deeper just ask. I’ve had to write that code a couple times.

2 Likes