Brock Institute for Advanced Studies all rights reserved
P. O. Box 302, Roxbury CT 06783

Home Page for Virtual Mechanisms
Animated by Java

Welcome to Brock Engineering's mechanism home page. Later, if you're still interested, I'll describe in more detail what's going on here, but if you want to cut to the chase, the columns in the table below list some classical categories of mechanisms. Under the headings are some specific examples of those mechanisms. If you have a Java-enabled browser, the clickable ones take you to Java animations of typical configurations. (The ones that aren't clickable are still in the shop).

Straight Line


Four Bar




Simple Crank

Drag link


Swing Arm Quick

Scott Russell

Scotch Yoke


Clock Escapement

Whitworth Quick


Intermittent linear motion

Double Rocker


Hookless #2



Function Generator


Involute Rack and Pinion

Epicyclic Gear Train (see Note)










Interesting Links:

The Cabaret Mechanical Theatre, a Museum of Automata (mechanical sculpture), Southend-on-Sea, Essex.

Note: Roy Rice and Richard Egge host The Little Engine Pages, a site that documents their work in model Stirling Engines and other essential endeavors. They've posted an animated GIF of an interesting straight-line generator using an epicyclic gear train here.

Release Notes 8 August 2000:

Well, not really 'release notes' because there's no new release, but rather a note reporting the discovery that some of these applets malfunction in my Microsoft Internet Explorer 5.0 after it's been equipped with Sun's Java2 Plug-in JRE 1.3.0-C. The applets are programmed to stop the animation when they're mouse-left-clicked and restart on the next click. That was functional until Java2, but now the action seizes the browser up to Ctrl-Alt-Del. I'm researching what to do about it, but in the meantime, please don't left-mouse-click on any of the animations if your MSIE is Java2-equipped. That or use Netscape Communicator.

Release Notes 22 January 1998:

There was a lot of housekeeping to do before I moved the mechanism board to its new home. First, there was the mess with Java's Graphics.drawPolygon() method. It turns out that none of the major browser implemented it correctly. If a Polygon was left open, then the browser (Netscape 2, 3, and 4, MSIE3) would render it open, contrary to what the API said. When Sun moved to JDK 1.1, they made sure that the drawPolygon() closed an open Polygon before rendering it, and they added drawPolyline() to do what drawPolygon() did before. So, now, MSIE4 is the only browser that gets drawPolygon() right. Fine. But MSIE4 now breaks old code, such as my RackNPinion class. For this release, I had to rewrite the classes that used open polygons so that they work in all of the browsers that I can test.

Release Notes 20 May 1997:

If the original page of mechanisms was a winter project, the first revision became a spring project. I had wanted to add the zipper, but that animation is so busy mechanically that I thought that I would have to build the machinery to make opaque members. Once the polygon filling routines existed, I had to use them to update the earlier mechanisms. There seemed to be no place to stop until I got to this point.

For a long time, I've wanted to see a proper animation of an involute gear set in the internet. I decided that it was up to me, so I added one.

I fixed the math error that caused the Netscape version of the Tchebicheff straight line mechanism to blow up.

Release Notes 21 March 1997:

1. Once you have an animation running, you can stop and restart it by clicking anywhere on the blueprint. (but if you're using a Java2-equipped MS Internet Explorer, see 'Release Notes 8 August 2000)

2. For best results, if you're using Microsoft Internet Explorer (MSIE), enable the Just In Time (JIT) Java compiler and Java logging. Make sure that their boxes are checked from the MSIE main menu via View -> Options -> Advanced. The JIT compiler seems to make a big difference in the smoothness of the motions.

3. In Netscape 2.0, the animations are jerky, and Tchebicheff blows up halfway through its first cycle. There must be some math singularity that MSIE just blitzes by. I guess I'll have to trap that somehow.. I haven't tested the page with Netscape 3.0. Any comments?

1.0 Background

When I was young, my Dad took me to the Carnegie Tech (now Carnegie Mellon) campus in Pittsburgh for homecoming. My father, who had graduated from Tech in 1931, took me deep into the basement of what was then Machinery Hall (and let me tell you, it is some basement) to show me this magical structure - a vertical gray board, maybe a couple of 4 x 8s, on floor stands - on which were mounted working models of classical mechanisms. Straight line generators, intermittent motions, all kinds of stuff to inspire a 12 year old. All of the mechanisms were animated by a electric motors behind the board. I suppose that the board was patterned after the classical mechanism synopses of the nineteenth century (Robert Willis in 1841?), but that will take some more research to dig out.

By the time that I got to Carnegie, Sputnik had gone up, and mechanical engineering education had been driven back (forward?) to the fundamentals. My classes were all calculus and partial differential equations, and the mechanism board in the basement of Machinery Hall was dusty, inoperative, and forgotten. Not by me.

2.0 The Virtual Mechanism Project

Fast forward to the fall of 1996. For my winter project this year, I decided to try to learn Java. I had never learned any of my dozen or so programming languages from classes or books - I needed a project, something that would focus my interest, and most importantly, lead to the development of techniques and maybe libraries that I could use later to display output state and performance of real and simulated processes.

What better way to start than to virtualize that dusty board - keep the flame alive. Even when the board was made (as part of a depression era WPA project, I heard), many of the mechanisms were obsolete. (Straight line mechanisms, crucial to the development of steam engines before cross slides could be accurately machined, only occasionally appeared in automotive suspension systems.) By now, you could probably get fired for trying to use one of these things, instead of stepper motors or robots.

In the preface to one of his books on mechanisms [Ref 2], Gardner Hiscox said: "The deeper we delve in the research for novelty and variety in the present field of mechanical design, the more we see the possibilities of human ingenuity. The facility and power of construction shown in the complicated mechanisms of the past augur well for the future of inventive genius."

Couldn't have said it better myself.

My ambitions for the winter project meant that I couldn't use the standard text book "..for Dummies" approach to animation, swapping GIF or JPEG image files in and out of the display. I had to develop ways to do all of the calculations and drawing offscreen, then show them when they were done.

I'm not all that bright (I get complaints about it all the time), so I've had to spend truly extravagant amounts of time figuring out things that some other people just breeze through (or claim later to have breezed through). What success I've had has been mostly due to a refusal to admit that I'm too stupid to get this stuff. This Java project was a perfect example. It was pretty easy to pick up the basics, and I had a couple of non-trivial programs running in a few days. But they were what "real" programmers dismiss as "FORTRAN programs in Java." By this they mean that the programs don't use objects properly or at all.

So at about the time I started to teach myself object-oriented programming, I started to teach my rotten dog, Rotten Dog, to meow. He's made much better progress on that project than I have on mine. I have only a few weeks of winter left, so it's time to publish, properly objectified or not.

3.0 Approach

The mechanisms shown here are computed and drawn on the fly, that is, the positions of all of the elements are calculated, then drawn using a purpose-built drawing library built on top of Java's graphics routines. The drawing library is patterned roughly on PostScript, with a stack of graphics contexts that can have their own current points, transformations, and so forth. The goal was to put all of the trick stuff into its own class, so the mechanism calculations and drawing could be as compact as possible, using units and coordinate systems that were structured completely for the drawing purpose, stripped of references to Java's graphics and the wretched coordinate systems that CS types insist on giving engineers.

The animations shown here are done using three images:

1) A static background image. These animations have a static background, the image of a blueprint with a title block. It didn't make sense to redraw this background for every animation frame, so I draw it as part of the applet's initialization code and swap it into the offscreen drawing image at the start of every frame cycle.

2) The offscreen drawing image. Here's where all of the drawing happens, invisible to the display. As described above, the frame cycle begins by loading a copy of the static background image (a clean piece of formatted vellum). Once the geometry of the mechanism is computed, its picture drawn onto the offscreen image.

3) The display screen. This is the image that Java puts up on the browser screen. To complete the frame cycle, the offscreen drawing image is swapped into the display screen. Then the applet's thread goes to sleep to wait for the next frame cycle to come up.

Java makes it so straightforward to create and manipulate these images that even I could figure out how they worked. I wouldn't like to have to do it in C++ though. The animations seems to be fairly presentable. Reasonably flicker-free (see browser notes above) and as smooth as any of the animations I see on Windows 95. (Win95 seems to have its own hitches in its giddyup.)

The blueprint motif? Well, it sort of fits into the retro style, but it's not _that_ retro. At about the time that I made those first trips to Machinery Hall, I was working at my father's engineering office Saturday mornings, and I got to help him make blueprints. Real wet-process-in-the-darkroom-take-most-of-the-day blueprints. So they seemed fitting here.

The animations were produced using Microsoft's Visual J++ 1.0. In my opinion, J++ at 1.0 is still very much a beta (or should I say my beta noire). It's reintroduced what I call "elevator shaft programming," when an innocent or stupid mistake seizes the system up, the debugger won't load, and the power switch is the only way out. A lot like assembly language programming without an assembler. Real "elevator shaft programming" is writing programs in machine language to control machines or industrial processes. At least with J++, nobody gets killed.

4.0 Results

The results so far are presented in links in the table. I'd like to hear from people who actually know how to do this stuff.

5.0 References

This first was the best for the nitty-gritty of the basic mechanisms. Strong on algebra, weak on history:
1. Schwamb, Merrill, and James, Elements of Mechanism, Fifth Ed. John Wiley and Sons, 1938.
2. Hiscox, Gardner D., Mechanical Appliances and Novelties of Construction, Norman W. Henley Publishing, 1927
3. Encyclopaedia Britannica, 1973, Machines and Machine Components.
4. Hyland and Kommers, Machine Design, Third Ed., McGraw Hill, 1943.

I have many more. I'll add them as I go along.

Return to the top of the Brock Engineering home page.
Your comments and suggestions are welcomed.
07-09-03 3:55 PM