The second and fourth cylinders seem to be working okay but there is a small problem with the first and third cylinders.
Whats the difference what method would fix it?
btw blender version is slightly outdated (2.69) so i’m not sure if that would make a difference (just playing around with blender at work,not really allowed to download stuff)
Off the top of my head … after looking at your file I would say relign the pivot points… but I have also had this ‘animation slop’ happen to me before using the Tracking Constraint… I almost think there is something wrong with the math in that constraint… that only shows up every now and again… but… Seems like Nathan Vegdahl mentioned some issues with the tracking constraints but I don’t remember exactly what he was saying about them…
I think one of the reasons using a constraint of any kind will lend it’s self to ‘slop’ in a Rigg is because of the extended use of matrix math in figuring locations… were as if you use some kind of IK constraint … blender always figures the IK constraint last… and this is what keeps it from having any compound errors…
Allll so… if you look here there is a way to ‘slide’ bones along other bones…
I’m not sure if it will work with a Crank Rigg or not… but here’s some ideas…
Anywayz… take a look at this Rigg and see if you can’t come up with some interesting stuff…
this is a somewhat complex video to follow … the Gist of it is… that in Armatures there is the “location Constraint” in that constraint there is a “Head… Tail” slider…
this slider can be keyframed and animated…
thus you have a way to ‘slide’ one bone along the ‘Y’ axis of the other…
and yep… looks like you can even add a Driver onto this…
Anyway hope this gets you a little closer to what you were looking for…
The propagation of numerical errors is unlikely to be a major problem, unless you have a very long chain of constraints. The ‘slop’ is mainly due to cyclic constraints: at least one bone in each cycle ends up following or tracking to the previous position of its target (i.e. one frame ago) instead of the current position. IK recalculates until it reaches a self-consistent solution.
hummm I"m not sure I 100% follow what your saying… when you say “at least one bone in each cycle…”
plus… wouldn’t the ‘effect’ of one object following another’s ‘previous position’ be caused by a numerical overload in the translation matrix… bumping it into the next frame?
perhaps I have misunderstood the whole cause of the issue…