Anim8or Community
Artwork => Finished Works and Works in Progress => Topic started by: ENSONIQ5 on April 04, 2013, 04:25:21 am
-
With a lull in other projects I thought I'd re-visit a favourite subject of mine (steam engines) and a favourite 3D software (Anim8or). The engine I'm building is a twin cylinder single expansion unit of the type often used in the paddle steamers that still navigate the Murray River in Australia. These boats were once the main thoroughfare for produce and passengers from the coast of South Australia into the fertile interior of the Murray-Darling basin. Although many are still running, these days they mainly serve the tourist trade.
This engine is not modelled precisely on any particular engine, rather it uses ideas and systems drawn from a number of engines of the type. There's still much work to do on the modelling, once complete the intent is to animate it in motion, preferably in Anim8or. Maybe one day I'll model a boat for it to go in, but that's getting a bit too far ahead of myself!
-
Thats awesome.
You said it's not modelled precisely on any particular engine, but uses ideas and systems drawn from other engines of that type. So, if its a runner, then you've actually made an 'ENSONIQ5 steam engine, and should be applying for patents as we speak. ;)
Beautifull piece of machinary ENSONIQ5. Awesome job so far. I'm sure it'll look like a million dollars when its done. (hope you put an 'ENSONIQ5 badge on it somewhere ;) )
It'll be a gr8 thing to see it running.!
(something RudySchneider would be proud of too. ;) )
-
...(something RudySchneider would be proud of too. ;) )
Darn right! Looks great ENSONIQ5! Makes me itchy to see it animated!
-
Thanks guys. Remodelled the cylinders/valves case and couldn't resist johnar's suggestion re the badge! Couple of test renders to check the materials, the ART attributes look good but I'll probably have to wind them back for the animation for speed reasons. Still to go are the boiler, firebox, flywheel, oilers and about a hundred feet of pipeline!
(PS: never mind the background, just a placeholder)
-
Excellent attention to detail as usual, ENSONIQ5, it surely reflects your passion for steam engines! Unfortunately (or perhaps fortunately), my area of expertise lies well outside of such engineering, so I'll be enjoying your progress for other reasons ;)
--also, the badge is a nice touch
Good luck with the final detailing and rendering!
-
Lookn good ENSONIQ5. Will be keeping an eye out for updates, and yeah, i'm "itching too see it animated" as well.
Lookn wicked so far. ;)
-
hehe Great badge as well as Raxx says
nice work ensoniq5
-
looks fantastic!! :D
-
Update: Engine mounted on boiler/firebox.
-
One word: Holy crap!! Wait thats 2. Nice Job Ensoniq5!!
-
great to see it coming together. (awesome badge. ;) )
Are you really going to be able to start it up and get it running. (i'm sure you can). That will be so awesome. Would be, maybe, even awesomer if you can get a decent fire going inside the firebox as well. :)
hoping you still hav time to work on this machine....inspiring....
A little off topic but... inspires me to look into robotics, hydraulics, pistons etc..
Nice stuff ENSONIQ5 :)
-
The modelling isn't really finished but couldn't help jumping ahead and animating this SOB. Totally....doing....my....head....IN! Just setting up a short running cycle, 4 or 5 revolutions of the crankshaft, and it's really taking forever. Some elements just have to be keyframed at every frame otherwise they want to rotate the wrong way (I know why it does this, but it's still a pain!). And it would be great if you could hide elements in wireframe mode as well as the other modes (or is there a way and I've just forgotten....!), it's really difficult lining everything up with all the objects showing.
I was tempted to script all the motion as I've done before but there are two things that bother me with this. It is very difficult to script the motion of a conrod accurately, it isn't just a sine-wave reciprocal with a lateral motion in a single axis, the wave is slightly skewed ('egg shaped' is the best analogy). This basically means that the big ends don't track the crankshaft correctly (though this could possibly be countered in the script...something to think about...)
The main reason I am avoiding scripts is that there is no way to pass variables from one frame to the next, making it EXTREMELY difficult to animate acceleration and deceleration. If I can figure out a way to do this I may create a second scene with scripted motion instead (see, THAT's why I love Anim8or!). Hopefully will have something to show soon...
-
where's the like button? ;)
-
Hey ENSONIQ5, not sure why you're having issues hiding elements in wireframe mode, if you select an element in the scene and press 'h' or go to Edit->Hide, it works as expected.
As for your second dilemma, I can't really tell what's supposed to be going on at the other end of the conrod, so not sure. But there's always the trick of parenting the rod to one end that's moving or rotating, and then set it to face the other end piece, and so long as the two ends' motions are accurate then it'll look like it's working correctly.
For acceleration/deceleration, you'd have to use if statements based on what frame it is supposed to start accelerating/decelerating, to set the acceleration/deceleration multiplier based on either the frame or time squared or to-whatever-power, minus the number of frames or time that has already elapsed at the start of the acceleration/deceleration.
-
The reason I was having trouble hiding the elements was that it been so long since I've animated in Anim8or that I forgot you could. I was using visibility. *slaps forehead* Thanks Raxx!
I am using a lot of parent/child relationships but they can only go so far. Taking the near-side valve gear as an example, the upper valve drive rod is a child of the crankshaft, so it pivots smoothly around the eccentric on the shaft. I could then have the gear 'slider' as a child of the upper valve rod, and the lower valve rod as a child of the gear 'slider', but then the lower valve rod has to pivot smoothly around the other eccentric on the crank shaft. It's a "closed system" rather than a hierarchy, so at some stage manual tweaking to line things up is inevitable. I realise the above probably doesn't make any sense...
The gear mechanism's motion is so darned complex, the mechanical design causes some elements to move in very unusual patterns.
Regarding scripting acceleration, the problem occurs when using Frame or Time as an 'input' into a motion script, the output being the angular position of the element. Even using IF statements to govern the speed of rotation, as the motion is not cumulative there is no way for the system to calculate the angular position the element would be at if it had changed speeds over previous frames. For example, lets say an element decelerates from 100 RPM to 20 RPM from frame 500 to frame 600 by using IF statements in the script. At frame 600, the script will set the 'speed' to 20 RPM, and hence calculate the angular position of the element accordingly, but as it is not cumulative the actual position of the element will be set as if it had rotated at 20 RPM for all previous 599 frames. In a nutshell, the script defines the angular position of the shaft, not the speed, and there's the problem.
Previously I have used invisible objects as a kind of variable, in one instance I had all the scripts get the scale of an invisible sphere as a multiplication factor, which was great at keeping all the elements in time and I could change the speed by enlarging or shrinking the sphere, but the same acceleration/deceleration issue occurred if I tried to animate the sphere's scale. When decelerating, the rotating elements actually ran backwards, which makes sense when considering the above paragraph but was dang irritating. I even attempted to use invisible objects as running variables, having the script change an attribute of the object at the end of the calculation (ie. 'speed'), then picking it up at the start of the script for the next frame, but Anim8or wasn't having any of that and delivered a 'circular script' warning.
As I type this I'm thinking there might be a kind of 'best of both worlds' solution here. If a single element's motion was keyframed to include accel/decel events, for example the crankshaft, then every other moving element could use a script to pick up the crankshaft's angular position and use it to define its own angle or position. There'll be a lot of trial and error to get the factors right but it would be preferable to keyframing the whole thing by a long shot. My scripting is rusty as hell but I'm sure a bit of WD40 will get the gears moving again!
-
Hi :)
Its hard to see the exact mechanics of this beautifull machine, but got me thinking of pistons and rods.
I made a short test of a 'very simple' setup, which seems to work ok in its basics.
Possibly the idea of using morph targets for any 'in/out' movement, might free up the rig a bit..?
I realise your rig is far more complex, but, just thought... maybe... :-\
I feel for you man, and wish i could help more... ;)
-
Nicely done johnar, very smooth. I may well use morph targets as a way of adjusting for the not-strictly-sine-wave motion of the pistons and valves. I have made pretty good progress using the scripting method, I'll post early results soon
Also, the concept of quaternions was clearly invented by a sadist. I've been trying to wrap my head around these mathematical nightmares used in element rotations and now my brain hurts a lot. I've managed to distil a workable solution for calculating sinusoidal linear motion from a rotating object... more through trial and error than an actual understanding of the mathematics but it'll do!
-
Near-side gear running reasonably well, short test animation below:
There's a bit of wobbliness where the valve rods link to the gear slider mechanism, should be able to fine tune that out. All motion is driven from the rotation of the crankshaft with the exception of the valve itself which is currently keyframed, it will be possible to script this from the crankshaft orientation once I've tuned the motion of the gear slider properly which currently isn't strictly sinusoidal (ie. rocking back and forth smoothly, evenly and rhythmically, like a metronome). I will transfer all scripts and motion control targets to the far side gear, phase-shifted 90 degrees, once the near side is sorted. Then I can get back to completing the modelling.
-
Congratz ENSONIQ5, you just blew my mind yet again!!! Nice work! I guess you'll soon be doing a Union Pacific Big Boy next? ;)
P.S. Do you play keyboards?
-
Cheers Blick Fang. I kinda plan to plonk this engine in the bowels of a paddle steamer at some stage in the future, I love those old boats and would enjoy attempting to construct one in Anim8or. I have little doubt that this will end up another unfinished project among many that litter my hard drive but I am enjoying the process so far and will see how far it goes.
Yes, I do play keyboards... hence the Ensoniq tag (the 5 is totally random, some forum a long time ago needed a number in the username so I just mashed at the num pad and hit 5!). I have a somewhat vintage Ensoniq SQ-80 that I bought back in the early 90's (still used and loved daily), plus recently acquired Korg digital piano and King Korg synth. Also have an oldish Technics keyboard that's used mostly as a drum kit and extra MIDI controller. My first synth was a Roland Juno 6 bought for $600 when only a couple of years old, unfortunately I sold it in the 90's "when analogue was dead" for very little $. These days they sell for well over $1000 on eBay! *slaps forehead*
-
;D Yes!!! ;D
Nice one ENSONIQ5 Gr8 to see the movements happening. I'm totally Amazed how you can do that through 'scripting'. (what type of magic is this. lol. Not a real question. But mind blowing it certainly is)
Awesome.
re keyboards: Am a bit of a fan myself. Loved to hav an old piano handy when living in a house, but living in a bus doesn't suit 'old iron-framed piano' ;) At the mo i hav a full size casio keyboard, and a neat little MIDI controller, but these both put away for now, till i get a sound card in my PC. (actually, a new PC is the plan).
I hav 'fruity loops' as main music software. Works great with MIDI.
anyway, must dash, cool stuff, bye for now... :)
-
It seems we've got a few music making goers on this forum. I my self have a Yamaha Kx 49 keyed midi controller. I also use fruity loops and various software like wavasaure (for creating my own sampled instruments).
Great work on the engine ENSONIQ5, I just think it needs more of a fluent velocity feel. It starts up and stops very suddenly which is unnatural.
-
This is very much a test animation only, to get everything moving together properly. Once done I plan to animate a more carefully timed run/stop/switch to reverse process. Having said that, with no flywheel (a smallish gear at each end of the crankshaft drives a large gear on the transverse shaft to which the paddle wheels are attached) these engines actually do stop and start pretty sharply once the gear is centred, I guess the compression in the cylinders is a pretty effective brake. I might actually fit a small flywheel on this engine though...just because they look cool!
-
I guess the compression in the cylinders is a pretty effective brake.
It certainly is. My 7 litre diesel engine needs no glow plugs to start. And it stops amazingly suddenly.
Compression = EXPLOSION. When forced compression stops, so does everything else, but when you get an explosion inside going, step back.
The compression in your beast, ENSONIQ5 would be, , more-so comparible.
cooldude234 They start quick, they stop quick., If they're running, get the heck out of the way . :D lol
(Reminds me of the broken arms /wrists we got by hand-cranking 'BIG EFFING BEASTS') ::)
Awesome
-
7 litre diesel! O.O
I used to love doing compression lockups in my first car ('69 Hillman Hunter). Get some speed up, drop gears from 4th to 2nd, and dump the clutch. The engine's compression would act like a brake and the rear end would loosen up very nicely! Went through a few clutches of course but buttloads of fun!
There are some pretty good home videos of steam engines much like this one running in the bowels of a paddle boat and going through reverse cycles etc., so I should be able to get the speed and timing pretty accurate.
-
('69 Hillman Hunter). Get some speed up, drop gears from 4th to 2nd, and dump the clutch. The engine's compression would act like a brake and the rear end would loosen up very nicely!
Lol. Classic
Interesting thing about using gears to decelerate, it actually cools the engine really quicjkly. If you ever get to the top of a large hill, (or mountain ;) ), and vehicle is overheating, dont stop at top of hill to allow engine to cool. (they actually get hotter doing that). Best thing to do is go down the other side, using engine/gears as brakes. Used to do a small mountain here, (takaka hill), would be overheating at top, then go down in second gear and engine was back to 'below running temp' in only 5 or so minutes. Could 'literally' watch the temp gauge drop'. (funny that)
The '7 litre' is in my bus. Its a Ford Commander, 11.5 metre 'home'
Slightly off topic here, hope you don't mind, but was revisiting Terranim8or yesterday.
(Leslie done awesome stuff there. Needs more recognition. Should be linked at Anim8or Home page.)
Was thinking, when it comes to 'Fire' for your 'steam engine', maybe worth a revisit.
http://biederman.net/leslie/terranim8or/terranim8or.htm
(but then, you probly got some other 'magic' way of making fire... ;)
-
(but then, you probly got some other 'magic' way of making fire...
Yep, Carrara I would expect for Steam, smoke and (heaven Forbid Fire!!) If I Know Tony ;)
-
Carrara is very tempting... but if possible I'm really trying to keep this all within Anim8or so I don't have to re-jig the motion (also just because it's been ages since I've done an Anim8or-only project.... though I am remembering why that is!). I've done smoke before in Anim8or, it was a bit rough but the concept might be transferable. In fact, since these engines burn redgum blocks (Redgums are massive Eucalypts that grow along the banks of the Murray River) rather than coal they don't actually smoke much when nice and hot. I haven't really thought about the fire yet, mostly it'll just be an orange/yellow glow with a few flicking tongues of flame licking out when the door is opened which shouldn't be too hard to simulate. Some experimentation is in order for this I think... which is the enjoyable bit about projects like this!
-
Tony:
Don`t know if you have this controller script , but may be useful to dissect. Originally posted by Kubajzz on CG-Nation which has now evaporated.
/*--Pendulum script - created by Kubajzz--*/
float $Period, $AxisAngle, $Amplitude, $Brake, $Decrease, $time, $finalamplitude, $stopmoment;
/*--Replacable parameters below--*/
$Period = 1; /* Enter value in seconds */
$Amplitude = 0.2; /* Set the range of the movement */
$AxisAngle = 0; /* Set the horizontal angle of the axis */
$Decrease = 0.3; /* If you want the pendulum to lose it's energy, set enter any value higher than 0 (values 0 - 0.5 recommended); set 0 for constant motion */
$Brake = 0.05; /* Maybe you want the pendulum to stop swinging when ti loses it's energy; set value 0 - 1 (values lower than 0.1 recommended) */
$finalamplitude = $Amplitude*(1-tanh(time*$Decrease));
$stopmoment = ($finalamplitude/$Amplitude)*1/$Brake;
if ($stopmoment<1) $time = 0;
else $time = 0.7854*$finalamplitude*cos(time*3.1416/$Period);
$orientation = (sin($AxisAngle*0.0174533)*sin($time), 0, cos($AxisAngle*0.0174533)*sin($time), cos($time));
-
Thanks Kev, it all makes sense in terms of operation. Just having trouble understanding quaternions...slips straight through my head without leaving any impression at all! That's not quite true, I understand the basic concept, but wrangling quaternion/roll+pitch+yaw conversions requires a higher level of mathematics than my hardened old synapses can handle. I'm pretty much abandoning scripts for some things and instead making use of invisible rotating objects and the point-at function, which is far easier to manage and adjust. I'll still be using scripts for some things (rotations, reciprocal sliders).
-
ENSONIQ5, I know your pain. In case you may have missed it, there's a RPYtoQuaternion function in ASL that'll handle that all that nasty conversion and convert your roll/pitch/yaw for you.
point4 RPYtoQuaternion(float roll, float pitch, float yaw)
// Compute the primary unit quaternion defined by
// applying a roll , then a pitch, and finally a yaw
// specified in degrees.
-
Yeah, I know about that one, however the QuaterniontoRPY function is conspicuous by its absence. Since I'm deriving motion from a rotating object (ie. getting the orientation value), I need to convert to RPY to run oscillations, either rotational (like a pendulum) or linear (like a sliding piston). I'm planning to jump out to a simple project and analyse a few RPYtoQuaternion operations to see if I can work out what's actually going on before working out the reverse process, I'd love to get a handle on this since it is often used in 3D geometry to avoid 'gimbal lock' issues and I kinda feel like it's something I should know about. One Wiki article I started to read on the subject of quaternions started to get into 'unreal numbers' (those impossibilities that equal a negative number when squared, ie x^2=-1) and I recall that it was these little $#@&s that back in high school marked the limit of my mathematical ability and interest and helped me to cross 'mathematician' off my careers options list!
-
Ugh, sorry about the obvious reference. I've been staring at ASL for the last 12 hours ;)
I've made my fair share of attempts to convert from Quaternions to Vectors/YPRs and back again. Only once did I get really close. It's unfortunate but it seems that for the most part it's impossible to get a 100% conversion. Or at least, that's how it's been for me.
For example, I did a quick run with this (it's a mess, sorry), and it doesn't work:
/*
From: http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/
http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm
*/
#command("object");
file $output;
float $test, $roll, $pitch, $yaw;
quaternion $q, $qC;
$output.open("$console", "w");
/* Our beginning Roll, Pitch, and Yaw */
$yaw = 20;
$pitch = 45;
$roll = 50;
$output.print("\nStarting RPY: %.3f, %.3f, %.3f \n", $yaw, $pitch, $roll);
/* Now convert it to a quaternion using Anim8or's built-in function */
$q = RPYtoQuaternion($roll, $pitch, $yaw);
$output.print("RPYtoQuaternion: %.3f, %.3f, %.3f, %.3f \n", $q);
/* Now convert it to quaternion the hard way */
$q.w = sqrt(1.0 + cos($yaw/2)*cos($pitch/2) + cos($yaw/2)*cos($roll/2) - sin($yaw/2)*sin($pitch/2)*sin($roll/2) + cos($pitch/2)*cos($roll/2))/2;
$q.x = (cos($pitch/2)*sin($roll/2) + cos($yaw/2)*sin($roll/2) + sin($yaw/2)*sin($pitch/2)*cos($roll/2))/(4.0*$q.w);
$q.y = (sin($yaw/2)*cos($pitch/2) + sin($yaw/2)*cos($roll/2) + cos($yaw/2)*sin($pitch/2)*sin($roll/2))/(4.0*$q.w);
$q.z = (-sin($yaw/2)*sin($roll/2) + cos($yaw/2)*sin($pitch/2)*cos($roll/2) + sin($pitch/2))/(4.0*$q.w);
$output.print("Manual Quaternion: %.3f, %.3f, %.3f, %.3f \n", $q);
/* Now let's try and convert it back...*/
$test = $q.x*$q.y + $q.z*$q.w;
if ($test > 0.499) {
$yaw = 2 * atan2($q.x,$q.w);
$pitch = PI/2;
$roll = 0;
}
if ($test < -0.499) {
$yaw = -2 * atan2($q.x,$q.w);
$pitch = -PI/2;
$roll = 0;
}
$qC.x = $q.x*$q.x;
$qC.y = $q.y*$q.y;
$qC.z = $q.z*$q.z;
$yaw = atan2(2*$q.y*$q.w-2*$q.x*$q.z , 1 - 2*$qC.y - 2*$qC.z);
$pitch = asin(2*$test);
$roll = atan2(2*$q.x*$q.w-2*$q.y*$q.z , 1 - 2*$qC.x - 2*$qC.z);
$output.print("Converted RPY: %.3f, %.3f, %.3f \n\n", $roll*(180/PI), $pitch*(180/PI), $yaw*(180/PI));
/*
$RPYConverted.x = atan2(1 - 2*pow($q.y, 2) - 2*pow($q.z, 2), 2*$q.y*$q.w - 2*$q.x*$q.z);
$RPYConverted.y = asin(2*$q.x*$q.y + 2*$q.z*$q.w);
$RPYConverted.z = atan2(2*$q.x*$q.w - 2*$q.y*$q.z, 1 - 2*pow($q.x, 2) - 2*pow($q.z, 2));
$output.print("Converted RPY: %.3f, %.3f, %.3f \n\n", $RPYConverted.x*(180/PI), $RPYConverted.y*(180/PI), $RPYConverted.z*(180/PI));
*/
$output.close();
-
Hmmm, thanks for that Raxx, gives me a good starting point for picking this thing apart. Much appreciated.
-
You guys blow my mind. 8) Your knowledge gives me the confidence I need, to push ahead with Anim8or. But I am stuck on what to do next. I need to make a mobile figure.
-
Wow, so this took longer than I thought! I've been busy with other projects but finally had a bit of time to return to this steam engine thing. To work out the scripts involved, I constructed a simple engine model based loosely on the Walschaerts valve gear system (the file is attached). All the motion of all the moving parts with the exception of the reverser lever (which would be operated by the engineer via a linkage) is controlled by scripts, with the input being derived from a moving target.
The target gets around the problem of defining acceleration in an Anim8or controller script without the ability to pass variables from one frame to the next, since the target's motion is keyframed the required motion is easily defined. The target could be considered to be a point on the ground, with the engine driving past it, assuming the wheel diameter was correctly accounted for and it rotated the right way (which in this case it wasn't, and doesn't). A script defines the orientation of the wheel based on the position of the target, with scripts defining the position of the linkages based on the wheel's orientation or the position of other elements, such as the reverser lever. In some cases, linkage orientation is defined using the 'facing' function. So to change the speed or overall motion of the engine it is only necessary to change the animation of the target and the reverser lever, with all elements maintaining their mechanical interaction with each other.
The scripts involved are too complex to list here, they can be dug out of the an8 file if you're interested in seeing how they work or modifying them for other projects. I have kept my (reams of) notes and geometric calculations and should be able to explain what each script is doing. I hit a major hurdle related to the ambiguous triangle problem with sine rule geometry (used to calculate the position of the valve linkage in the reverser gear), I very nearly walked away from the project but luckily had a bit of a brainwave (while on the dunny...haven't we all!) and it all came together tonight. Feel free to fiddle with it, just remember that there is no actual collision detection between elements so it is possible to set the reverser to a position that would be impossible in real life, with potentially weird results.
The plan is to refine the scripts for use with the Stephenson valve gear used on the paddle steamer engine, so I can finally get the beast to run. Fingers crossed other projects stay quiet for a bit, otherwise it could be another year until the next update!
-
Hey ENSONIQ5, that is friggin' awesome. I wish I thought of that, haha. Keep it up, can't wait to see more!
-
The scripts are (more or less) done, at least on the near side of the engine. The screen cap below shows the nearside gear running and the lack of keyframes, only the target object that drives the action and the gear selector shaft ('GSS') are keyframed. All other motion is the result of scripts based on the location of the target object and the orientation of the GSS. Unfortunately the engine's running isn't really correct in the sense that the rotation etc. happens regardless of the gear selector's position, I would have kinda liked all the action to be the result of the GSS and the orientation of a steam valve lever but without the possibility of running variables I don't think it's do-able.
The scripts are not quite perfect regarding the position of the valve rod and the location/orientation of the main gear selector object, I fear the maths involved in getting it absolutely perfect is beyond me. The problem is that the orientation of the object affects its location, which affects its orientation, which affects its location, etc. ad infinitum. This has a nasty 'calculus' stench to it! Perhaps I'll re-visit the scripts with this type of approach at a later date, for the moment the scripts are based on basic geometry and while not perfect they are, I think, good enough to be going on with (perhaps some of the bearings are just a little bit worn!).
The modelling is not complete, I need to add the steam pipes, valves, gauges and of course the gear selector lever before attempting fire and smoke and rendering it out. I am glad that the thing runs though, the Stephenson gear is WAY more challenging to script than the test Walschaerts system.
-
Moving parts replicated to far side of the engine and some more modelling done (gravity and pressurised oilers). More modelling to come and some tweaks required to the scripts.
-
Man, that is is absolutely awesome.
And as, Blick Fang said, mindblowing
.
Speechless really. Extremely Well done
(http://s24.postimg.org/o4uvmxwjl/Thumbs_Up_G1.gif)
-
Cheers Johnar. I came close to walking away from this many times, it's satisfying to see it running. Hopefully I can "finish" it (if any project is ever truly finished)!
-
IK would make this setup a piece of cake.
-
Hmm, maybe, at least in some places. Most IK setups I've seen are strictly hierarchical in the sense that 'tree-like' structures can be created, but not closed loops. Child objects can influence parent objects through the IK chain, but you can't have looping chains or multi-anchored chains which this rig would require, as far as I know. What would make it simpler would be a physics engine that incorporated collision detection, then simply rotating the crank would generate the required motion in the linkages etc. I've done this sort of thing before in packages that included physics (Cararra) but I kinda wanted the challenge of doing this entirely in Anim8or and rigging it so the animation could be easily changed without re-keyframing everything, which means scripts.