|
|
In November of 1986, early in the history of the Amiga computer, Commodore released a new demo animation featuring a robot juggling three mirror balls. Juggler was a continuously looping sequence of 24 full-color frames, with matching "clink" sound effect, playing at 30 frames per second. |
 |
|
|
||
"Behold the robot juggling silver spheres."
Thus begins the article in the May/June 1987 AmigaWorld in which Eric Graham explains how the Juggler was created. The program ("with full Intuition interface") promised at the end of the article was Sculpt 3D for the Amiga, released in the fall of 1987. Byte by Byte sold Amiga and then Macintosh and Windows variants of Sculpt for more than a decade. Eric rendered the frames in a raytracer he wrote called ssg, a Sculpt precursor. The rendered images were encoded in the Amiga's HAM display mode and then assembled into a single data file using a lossless delta compression scheme similar to the method that would later be adopted as the standard in the Amiga's ANIM file format. Eric and his wife Cathryn actively promoted raytracing on the Amiga. Cathryn wrote the Amiga Sculpt 3D user manual and compiled an electronic newsletter distributed on a series of disks. Raytracing 1.0, the earliest of these, contains both ssg and the static geometry of the juggler object, along with the Juggler image data and the player program. Juggler was an astounding demo in its time. I personally remember staring at it for several minutes through the front window of a local Amiga dealer, wondering how it "worked." Many people were inspired by Juggler, and by the Amiga animations that followed, to pursue a career in 3D graphics. Nothing like it could have run on any other stock personal computer in 1986. In fact, Eric recalled recently, the Commodore legal department initially "thought it was a hoax, and that I'd done the animation on a mainframe." He sent them his renderer so that they could generate and compile the frames themselves. Tracing rays to create realistic 3D images, the method used to render the Juggler frames, was an idea that had been in the air since the 1960's. Credit for the first publication is generally given to Arthur Appel (1968), but like many important papers, this is a point on a continuum. A number of people were experimenting with raytracing prior to 1968. Very similar techniques may already have been in use for years in nuclear weapon effects simulations (although probably not specifically to make pictures). The underlying math of raytracing is the same geometric optics used by Descartes to explain rainbows.
After this page had been up for almost two years, I was finally able to contact Eric Graham and ask him about the making of The Juggler. He has kindly given me permission to print his reply. I've omitted irrelevant bits of our correspondence and added a few links.
I discovered that Eric and I share an interest in amateur astronomy, but I know his skies in the desert Southwest are infinitely better than mine in the light polluted Northeast. He's built several of his own telescopes as well as a personal observatory, and during the 1980's he worked on the data analysis software used at the Very Large Array, the New Mexico radio telescope complex featured in the movie Contact. He recently began a 3D graphics company called Direct Algorithms. The image data of the original Juggler is stored in a unique file format that, as far as I know, was never used for any other animation. After Juggler, Eric wrote a suite of programs (dilbm, pilbm and movie) for assembling and playing Amiga animations that used a somewhat different format. (Free source code for unmovie, a program that extracts the frames from movie format files, is available from Aminet.) ANIM emerged as the standard Amiga animation format only later. In order to preserve The Juggler and make it available to a larger audience, I've extracted the image data from the original file and recompiled it into a Windows AVI. You can download it from
I wrote the program that extracted the frames from the animation file. The program builds 6-bit HAM images from the deltas and then decodes the HAM to 24-bit RGB. The 24-bit sequence was reassembled using the Microsoft Video 1 codec (the simplest and most widely supported on non-Windows platforms) at 16 bits per pixel and 100% quality. The conversion was designed to conserve the original pixel data. I chose not to correct the pixel aspect for square-pixel displays, so the images will look a bit stretched horizontally when displayed on most computer monitors. The dimensions of the frames are the original 320 x 200, and the pixels are roughly NTSC D2, with an aspect (ratio of width to height) of about 0.86. Lossy AVI compression inevitably introduces deviations from the original color data. The RMS error for the Juggler AVI is about 0.04, small enough not to be visually apparent. A link to example source code for extracting the pixel data at full accuracy from the original file is provided below. As far as I can tell, the envelope for Juggler's 8-bit sound is generated at runtime by the player. Rather than try to reverse-engineer the code, I sampled the sound (at 22 KHz) directly from an Amiga's audio out as the animation played.
Juggler
(c 1986 by Eric Graham, All Rights Reserved.
This is Version 1.0 of Juggler, a demonstration program running
on the Amiga written by Eric Graham.
All of the images in this program were generated on a 512K Amiga.
Version 1.0 has several known bugs, but we were so impressed with
the demo that we wanted to get it out as soon as possible. (A new
version is coming, even as you read). The main bug in the program is
that the program doesn't release all of its memory if it exits due to
an error condition. This should not stop you from enjoying this
program, just be careful after you use the program.
Before you use the program, you must assign movie: to the disk
that the Juggler program is on. For example, if you have the
juggler disk in drive df1:, type
assign movie: df1: before you run the program.
(A side note. The Juggler can be started either from the CLI, by
typing juggler, or from Workbench, by double-clicking on its icon.
None of us (except the icon designer, who will remain nameless) is
happy with the icon. So if you do a better one, send it in,
and maybe we can use it for Juggler V1.1.
Controls:
Juggling speed is set by typing 0-9 on the numeric keypad. Speed is
only changed once per complete juggling pass, so it may seem to take
a bit of time before the Juggler responds to your speed change
command. ESC exits the program.
This program is being made available by Commodore for use on the
Amiga Computer. We encourage you to copy it for your friends who
own Amigas. Have fun.
Commodore/Amiga
When the program runs, it displays a banner screen to give users something to look at while the animation file loads from a floppy. Here's what it says. The individual frames of the movie are being fetched from disk. When the movie starts you may press any of the digit keys '0' to '9' to change the speed of the movie. Press the escape key 'ESC' to exit the program. The images were generated with a standard Amiga with 512K memory. A ray tracing method was used, which simulates rays of light reflecting within a mathematically defined scene. Each image requires the calculation of 64,000 light rays and takes approximately 1 hour to generate. An image is compressed to about 10K bytes for storage. Images are expanded in less than 30 milliseconds. The Amiga hold and modify mode is employed so that up to 4096 colors can be displayed at one time. Copyright © 1986 Eric Graham NOW PRESS ANY KEY TO START THE MOVIE Version 1.2
To document the file format, I've made available the source code for my conversion program.
It saves either TGA or Amiga HAM IFF image sequences and compiles without modification in both Microsoft Visual C++ 4.0 and Amiga SAS/C 6.51. Fred Fish #97 contains version 1.2 of the Juggler distribution, which includes the image data and Amiga player program. (The disk archive is LZH compressed, so you'll need an archive utility that understands LZH or LHA files to extract it.)
Unless you're familiar with animation file formats and the Amiga's native display hardware, the organization of Juggler's image data may seem a bit strange. Briefly,
A conventional 8-bit display stores the value of a pixel in a single byte (below, left). For a pixel at (x, y), the memory offset from the start of an image w pixels wide is just wy + x, and the value stored there is an index into a table of 256 RGB color records. plane 0: 10000011b
plane 1: 00110010b
plane 2: 10001001b
pixel: 01001101b plane 3: 11010100b
plane 4: 01010111b
plane 5: 10011010b
The original Amiga HAM (hold and modify) display mode uses 6 bits per pixel. Each bit resides on a different bitplane--the bits of a given pixel aren't contiguous in memory. To retrieve a pixel value (naïvely), you must read bytes at six different addresses, mask off all but one bit from each of them, and string the bits together (above, right). For the pixel at (x, y), the byte offset into each bitplane is (wy + x) / 8, and the bit is 7 - (x mod 8). Bitplane n contains the n-th bit of the pixel value. The high 2 bits of the pixel value form a code that controls the interpretation of the other 4 bits:
A HAM code of 0 causes a conventional color table lookup. For the others, the level of one of the three RGB channels is stored in the four data bits, and the other two channels are copied from the pixel to the left (the leftmost pixel gets the missing channel values from entry 0 in the color table).
Animation files store frames as a collection of deltas, named after the Greek letter used in math to denote the amount of change in a quantity. An animation delta is just a set of pixels that differ between two frames. The deltas for each Juggler frame consisted of horizontal runs of pixels and were sorted by length into five sections. The first section contained runs of 80 pixels (10 bytes per bitplane), and the others contained runs of 64, 48, 32, and 16 pixels (8, 6, 4 and 2 bytes per bitplane). The standard format for Amiga animations that emerged later would use vertical runs, or columns, of pixels rather than rows, and would allow each run to be an arbitrary length.
Double-buffered displays are an integral part of the Amiga's display architecture. Two frame buffers are set up in memory, a foreground buffer containing the currently visible frame, and a background buffer where the next frame is built. While the current frame is visible, the delta pixels are written into the frame in the background, and when the time comes to display the next frame, the foreground and background trade places. At the start of the animation, the foreground and background both contain frame 1. The delta pixels for frame 2 are written into the copy of frame 1 in the background, and the buffers are swapped. Next, the delta pixels for frame 3 are applied to frame 1 and the buffers are swapped again, leaving frame 2 in the background. In general, except for the first frame, the deltas are applied "two frames back," so that the delta for frame n modifies the pixels of frame (n - 2).
|
Copyright © Ernie Wright
Last modified 31 Jul 2004.
Turner Whitted's paper (1980) is widely regarded as the
first modern description of raytracing methods in computer graphics. This paper's famous
image of balls floating above a checkerboard floor took 74 minutes to render on a DEC 
The readme
file that accompanied Juggler (the player) and movie.dat (the frames) is reproduced here
unedited, except for a few changes in line breaks. (I'm certain Eric didn't write this
himself, although he may have created the icon.)
