Hello,
I made a sime rig of a spider which is controoled only by 8 affectors at the end of each leg. The rest is animated by KineFX “FullBodyIK” node.
Each affector is animated with python script to make the spider walk along the curve. It works great mostly, but after 270° rotation it makes a strange flip.
It worth to mention that each affector is of type “Position” and they all are animated smoothly.
Below are couple of videos which demonstrate the problem and a couple of screenshots which show the basic KineFX setup and animation curves of one leg.
Any ideas what could cause this problem and how to fix it?







Thanks.

I can't tell from your image but is the (first) input pose that you're feeding into the full-body IK rotated first into same root position/orientation? If you're asking the IK solver to rotate 180 degrees at the same time, it can very easily run into degeneracies.

Thanks for your response.
I prepared a test-file which reproduces the problem (I am not sure about rotations you mentioned).
I also found one possible solution, but it looks more like a ‘hack’ than a solution. It works as expected if I apply additional rotation to the input geometry and skeleton.

To reproduce the problem:
1. Open attached file and press play. The problem occurs on frame 940.
2. To apply the fix (or ‘hack’), the following nodes should be activated: obj/spider_robot/rig_target/transform_root and transform_root_ref1.

It would be nice to learn what am I doing wrong and to have correct solution to the problem.

Thanks.

Hello Radik,

Thanks for posting your scene. The main issue here is that the FBIK solve is prone to flipping etc when we try to apply a very large ‘global’ rotation to the skeleton - when dealing with this it's generally best to apply the global rotation before we attempt the fbik solve.

The fix you had in the scene gets pretty close to this, just that you only need to apply that global rotation just before the FBIK solve, rather than placing it right at the top of the network.

Another gotcha in here is that when you set the 3@transform attribute manually in a wrangle, you probably want to call to ensure that generic SOPs (like the Transform SOP) know to treat that attribute like a transform matrix rather than just a series of float values. You could also use a Rig Attribute Wrangle here instead, which takes care of this for you.

I also knocked up an alternative method where we keep a joint_base driver for the fbik solve and use a Rig Copy transforms before the Solve FBIK node to provide an initial orientation to the skeleton prior to the solve.

Hope that helps!

Hello Henry,

Thank you very much for these great improvements and suggestions. It really helped and I really appreciate it.

Thanks!