I am tackling this mechanical linkage which moves in the x axis (see image). I would like to do it using IK but the problem is that I can't establish a relationship between the blue and green parts because they both move but the blue part is dragging the green part along in a non-linear fashion (at least thats what I believe) Left image is what it looks like extendend.
Many thanks!
Like this?
Yeah, that's a tricky one and it needs either a cheat or the not so new but usually overlooked iTaSC solver.
So, in the settings of your armature, enable iTaSC:
I made the blue part the boss and the green will follow. If I'm not mistaken, this special solver doesn't like unparented targets, so I made a main bone. The hierarchy is as follows (u = upper):
bluebone, mainlever1-u, target-u and height-u are children of main
mainlever2-u is a child of mainlever1-u
follow-u is a child of mainlever2-u, not connected
greenbone is a child of follow-u, but does not inherit rotation.
mainlever2-u has an IK-constraint, chain length 2 to target-u with the following settings:
This is straightforward. Would be exactly the same with an ordinary constraint. Simplest leg rig possible.
But the settings of follow-u are where the magic happens:
It points to height-u and it's axis reference is set to target, lock X. That means, its tip tries to get on the X-axis of height-u. In effect that means its tip stays the same height if it can since height-u's X axis is parallel to the ground.
You could do without the lower armature, if you equip the meshes with Mirror Modifiers with a Mirror Object on the center line of your mechanism.
And for old time's sake, the cheat:
Simply add a very long cheat bone and turn follow-u and cheaty into another IK chain, 2 bones long. Since cheaty is so long, the up/down motion of the joint is minimal. Then you'd move greenbone with a simple copylocation constraint in one axis and it won't bob up or down. There's ways to make the bobbing even smaller, but it will already be invisible if cheaty is long enough.
It's not entirely obsolete since iTaSC sometimes gets hickups if you re-arrange stuff after it's been set up. It likes your workflow to be linear. Then again, it could just be me being clumsy.
This is doable with the regular IK solver.
The first part of the structure, the bottom two IK in my picture, are pretty trivial. They reach from our control to static positions. There's only one thing they can do to get there. So a basic 2-chain IK will take care of them.
The tricky bit is the top chain, which seems like it'd need three bones, and there's no single solution to 3-chain IK. Blender cares a little bit about the rotation of the first bone relative to its parent but not at all about the rotation of the last bone relative to the target, and so it creates an asymmetry in the bend. And we want symmetry.
The trick then is to figure out exactly what we know about the connecting bar, which I've called ik2.T. We know its pose/world rotation, which never changes. We also know that its midline lies on the axis of symmetry. Its midline never changes either. What we don't know is one axis of its exact position: its height in my pic. Now that we know what we know and what we don't know, we can create a custom IK chain to solve that problem for us.
The top IK chain is a 3-chain, with stretch, rotation, and position enabled. The third bone in the chain, which is not intended to have any meshes parented to it, has stretch enabled and is locked in all axes:
It targets a bone well above, in the same axes, in the same line as described by its Y axis. Because the IK seeks to match rotation to the target, this bone will always have that same rotation. Because the third bone is locked in all axes, the second bone will also always have the same rotation. And because the third bone and the IK target lie in the line of symmetry, the connecting bar will always be centered on that midline. The third bone will stretch to meet the target-- that's all it can ever do.
After that, we don't even need an IK for the other half. We can just locked track a marker parented to ik2. I suppose if we'd rather, we could copy inverse rotation from ik1. Come to think of it, that'd be a good demonstration that it's working correctly, so let's try that:
