Very nice modelling, gentlemen, as always!  Looking forward to seeing the awesome PHUR plugin in action.

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!

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.

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!

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*

Near-side gear running reasonably well, short test animation below:

http://youtu.be/1zStMPcDlVc

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.

3D printing is one of the key research areas the organisation I work for (CSIRO http://www.csiro.au/) is involved in, specifically additive manufacturing using titanium (http://www.csiro.au/en/Organisation-Structure/Flagships/Future-Manufacturing-Flagship/Ti-Technologies/TT-Manufacturing.aspx).  3D printing of temporary organ replacements is also in its infancy, this is seriously exciting stuff.  My favourite 3D printing link is below... melting sand with the sun!
http://www.markuskayser.com/work/solarsinter/

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!

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!

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...

I love anim8or because…

While limited in range, what it can do it does very well.  For example, while missing Boolean modelling operations its vertex editor is a joy to work with.  While not having a massive range of tools, its workspace is clear and uncluttered.

And the big one: Simply the best workflow setup there is.  Being able to create multiple scenes from a single set of figures and objects within a single project is frankly unbeatable.

Anim8or hands nothing to you on a plate… instead it invites you to step up to the plate!  Its shallow learning curve and lack of instant one-click solutions makes it the ideal training tool.

Of course, it does have limitations, and personally I rarely render in Anim8or any more due to deadlines having to be met.  While I, along with many others, would love to see further development on Anim8or in the future, it will always be a crucial tool in my CGI toolkit and it is where every one of my projects starts.

Honestly laughed out loud when Springy dropped onto and gripped the pencil!  Nicely fluid animation, very deftly done!

Nice work!  The visible interior really emphasises the size of the ship.  Very impressive!

Update: Engine mounted on boiler/firebox.

Been a while since I've had XP (miss it a bit actually....*sniff*) but this sounds kinda like a problem with the registry.  The fault could potentially be a virus attacking the registry, if you haven't already done so I'd run a deep virus scan.  Unfortunately my knowledge of the registry and how to edit it is slim, on my old machine I used to keep all my files on an external drive and reformat/re-load XP on the internal drive if anything like this happened.  A bit drastic but it did keep the machine running nicely (it was a Sempron... needed all the help it could get!).