[SOLVED] Bionicle Piston Limbs: Track To Constraint Issues

[xabotage]

I am modeling and rigging an old-fashioned Bionicle action figure and have so far finished two basic limbs. But I am having problems with the piston-jack-like components of each one (see attached images).

I am using the Track To constraint to make the two bones that control the two “piston” pieces face each other. The top “skinny” piece is lagging in its tracking: it only tracks to the previous “frame” position of the bottom “fat” piece. As a result, jerky movements during grabbing/rotating of relevant bones (such as “IK_lever”) in pose mode as well as animation playback reveal that the “piston_skinnies” bone is not tracking to the current position of the “piston_fats” bone. (see attached .blend file)

The attached images show me first moving the “IK_lever” bone (not visible) so that the arm is contracted (piston_render_contracted.jpg) and then instantly snapping it down to a resting position (piston_render_resting.jpg). The skinny piece of the jack/piston is still pointing to the previous position (not precisely in these images, but that is what it really does). Editing the pose or armature in any way causes that bone to then correct itself instantly and properly track to the fat piece of the jack.

Is this caused because blender evaluates the Track To constraint in “piston_skinnies” bone before evaluating the movement of the bone, “segment_low”, or is there something I can fix? I have included a .blend file of the armature for anyone to experiment with. The bone in question is called “piston_skinnies” and is tracking to “piston_fats”. Although “piston_fats” is respectively tracking to “piston_skinnies”, it does not have any problems. Why?

Attachments

piston_rig_problem.blend (147 KB)

[chipmasque]

Haven’t looked at the .blend yet, but if you have two bones constrained to each other using Track To, you likely have a “cyclic dependency loop” formed, which can mess things up badly and cause a number of problems including glitches like you describe. But such glitches can also be sporadic, and a file can look OK, but if the loop persists, it probably won’t stay OK.

Best way to confirm this is to look in the console window – it should report any cyclic dependencies found in the file, usually when opened, but also when the loop is operated, so to speak. If there is one reported (it will name the bones/objects involved), you’ll have to find another way to do what you want.

[xabotage]

You were right. I don’t know how to check for cyclic dependencies, but your idea gave me a theory that a bone constrained to a bone constrained to the first bone can get into a nasty loop or else make some semantic errors.

(edit: I do know how to check for cyclic dependencies… now. The terminal says it best:
Dependency cycle detected:
piston_fats depends on piston_skinnies through IK Constraint.
piston_skinnies depends on piston_fats through IK Constraint.
Not sure why it says “IK Constraint”, though…)

To solve the problem, I created a new bone at the same root/head postion as “piston_fats”, parented it to “segment_low” just the same, and let the “piston_skinnies” track to that instead. Now it looks the same as if it were tracking to “piston_fats”, but no problems. This way, the bone will not track to a bone whose own position was dependent on the first bone (see how confusing that sounds? The solution makes things so much cleaner).

The solved armature is attached for any who didn’t understand the above paragraph.

Attachments

piston_rig_solved.blend (148 KB)