The Juggler

Behold the robot juggling silver spheres.

The cover of the May/June 1987 AmigaWorld.

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

Turner Whitted's 1980 test of raytraced reflection, refraction, and shadow.

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.

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 VAX 11/780 mainframe, a $400,000 computer. The Juggler would appear a mere six years later, created and displayed on a $2000 Amiga.

III's Adam Powers.

Shiny spheres and checked floors aren't the only elements of early computer graphics reflected in Eric's animation. It's also part of a legacy of computer- rendered jugglers begun by the Information International, Inc. (III) demo reel, Adam Powers, the Juggler, which premiered at SIGGRAPH in 1981. Powers was animated using a primitive form of motion capture that involved projecting film of a real juggler (Ken Rosenthal) onto graph paper. The tradition was continued by Lumpy the Clown in Pixar's 1987 short, Red's Dream.

Both Adam Powers and Lumpy were fully animated with realistic variations in their moves throughout their routines. Eric's Juggler comprised a single move that could be looped indefinitely to create a fascinating, hypnotic animation that nevertheless fit comfortably in 512K of RAM. Experienced jugglers will also note that Adam and Lumpy perform the more conventional three-ball cascade, while the Juggler throws a shower pattern, more difficult to master but somewhat easier to animate.

From the Author

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.

From: Eric Graham
To: Ernie Wright
Subject: Re: Juggler
Date: Thu, 13 Jan 2000 11:03:04 -0500

I bought an Amiga 1000 in June or July of 1986 along with a C compiler and spent a month or so porting my text editor to it and writing software to communicate with my IBM PC.

In November 1966, a month after I learned to program, I had written a simple ray tracing program. I was then a grad student at Manchester University in England and had access to a Ferranti Atlas super computer. After getting the program to actually work, I only ran it once. The scene had a horizontal floor, a few spheres, and maybe a cube or cone, and two light sources.

The output was a big reel of punched paper tape which I fed through a Friden Flexowriter. By judicious use of backspaces and over-strikes, you could build up blocky pixels. For example an M and a W produced a dark blob, while a single period was off white. The final image resolution was about 100 x 80.

I remember the computer run took about 20 minutes and my department was billed around $1,000 for it--it was all funny-money, no real cash actually was exchanged. Because I wasn't supposed to be doing this, only a few people actually saw the output, and it was lost in a move at some time. A work of art it wasn't, but it did show shadows and shading.

I used ray tracing because that was the simplest and most obvious way to render an image. I can't claim priority over Turner Whitted on the idea, because it was never published, but I suspect lots of other people also figured it out over the years.

Twenty years later, in the fall of 1986, I was thinking of adding a room onto my house, and rather than start the work I decided to write a modeling and rendering program. But first I re-implemented the ray tracer. It took about a week to get running, and then another week or two to make a few models and put the compression scheme together. That was November and the Juggler was born. The room never was added to the house.

The reaction amongst the Amiga community in Albuquerque encouraged me to send it to Commodore. Their legal department thought it was a hoax, and that I'd done the image generation on a mainframe, so I sent Commodore the small program so they could run it themselves and generate the big Juggler file. Then they sent me $1,000 or maybe $2,000 for the rights to use it for promotional purposes. A year or so later Tom Petty included a second of the Juggler in a music video, I squeezed $100 and a copy of the tape out of his record company.

I started coding Sculpt 3D on December 26, 1986 and had a working prototype by about April. Byte by Byte picked up the rights to sell it, and as best as I can recall it shipped in October 1987, but I may be off by a month or two.

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 Video

An HTML5 version of the Juggler animation.

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 number of reasonably standard file formats. (Not all at once. I've accumulated these as video on the Web has evolved.)

File	Size (kB)	Encoding
juggler.webm	309.4	276 × 200, On2 VP8
juggler.mp4	541.6	276 × 200, H.264
juggler.flv	259.4	320 × 200, On2 VP6/Flash
juggler.avi	328.5	320 × 200, MS Video 1, 16-bit
juggler_pngs.zip	568.6	320 × 200, 24-bit PNG frames
juggler.wav	21.9	uncompressed 22 kHz 8-bit mono

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 original images are 320 × 200, with a frame aspect of 4:3. It isn't obvious whether it's better to faithfully reproduce the correct frame aspect or to preserve every (non-square) pixel, so I've done both at various times. Links to the source code for the extraction program are below, along with a more detailed discussion of HAM, non-square pixels, and other arcane details.

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.

The Text

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


  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

Source Code, Technical Details

To document the file format, I've made available the source code for my conversion program.

jug2tga.c
rotate.c

It saves TGA (Targa) 24-bit image sequences and compiles without modification in both Microsoft Visual C++ 4.0 and Amiga SAS/C 6.51. (Update: It also compiles in MSVC 2008 Express and gcc 4.4.3.)

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

http://www.funet.fi/pub/amiga/fish/001-100/ff097/

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,

pixel bits are separated into bitplanes
pixel values are hold-and-modify encoded
only the pixels that change between frames are stored
the difference is calculated two frames back
the pixels aren't square

A conventional 8-bit image 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:  00111010b           plane 3:  11010100b
                                plane 4:  01010111b
                                plane 5:  10011010b

The original Amiga HAM (hold and modify) display mode (above, right) 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. 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:

Code	The data bits are...
0	an index into the 16-member RGB color table
1	the blue value (in the range 0 - 15)
2	the red value
3	the green value

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

Frame 1, with the delta regions for frame 2 highlighted.

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

Frame 1 is loaded into both the front and back buffer. The delta for frame 2 is applied to the copy of frame 1 in the back buffer.

Once frame 2 is built, the back and front buffers are swapped, displaying frame 2.

The delta for frame 3 is applied to the copy of frame 1 in the back buffer.

The buffers are swapped to display frame 3. After this, the delta for frame 4 will be applied to the copy of frame 2 in the back buffer.

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

Unlike modern displays, the Amiga (and other computers of its era) used non-square pixels, a legacy of analog television. To display an Amiga image on square-pixel hardware so that it doesn't appear squashed or stretched, the image has to be resampled by a scale factor that cancels the non-squareness of the pixels. The measure of non-squareness is the pixel aspect ratio, or PAR, the ratio of width to height of a pixel. To preserve the shape of the image, its horizontal resolution must be multiplied by the PAR or the vertical resolution divided by the PAR.

Unfortunately, there's some confusion about the correct PAR for Amiga images. Eric's raytracing code assumes that a 320 × 200 display has a frame aspect of 4:3, which implies a PAR of 5/6 = 0.8333. The original Amiga documentation suggested a PAR of 10/11 = 0.9091 for NTSC (the TV standard in North America; Amigas in Europe used the PAL standard and a different PAR), and most older IFF ILBM image files have that 10/11 PAR in their headers. A 1993 technical note by Amiga programmer Carolyn Scheppner revised the recommended PAR to 11/13 = 0.8462 for the original low-resolution NTSC display modes.

In my own code, including the HAM and ANIM-5 routines I wrote for LightWave, I used 69/80 = 0.8625, and this is also what I used for the aspect-corrected versions of the Juggler on this page.

Postscript

I posted the first version of this page in the Spring of 1998, making it older now than the Juggler was then. Although I revise it from time to time, I usually do so with a light touch, partly for lack of time to do more. But more importantly, the page itself is something of a relic that wants to remain in its temporal context. References to obsolete compilers are part of its charm. Words like recently and currently should in most cases be understood to refer to a time much closer to the origin of the page.

My goal was to curate the Juggler, to unlock it from its singular and now unplayable file format, and to share it with others who remember it as fondly as I do.

A number of people have dropped me a note to share the stories of their first encounter with the Juggler, and those are always fun to read. With my permission, the page was translated into French, which is pretty cool. The Juggler is now in dozens of places on the Net, from YouTube videos to animated GIFs, and most of those copies ultimately came from this page.

A few people have written seeking permission from me to do various things with the animation, or asking whether I have other data that hasn't been shared on the page. I answer those on a case by case basis, but there are a few things that apply in all cases:

I can't sign any legal forms regarding reproduction rights. Eric Graham is the owner of the intellectual property.
I don't have current contact information for Eric, but you may be able to reach him through the e-mail address in the Contacts link on the Direct Algorithms site.
I don't have any data that isn't already linked here.

In 2011 I wrote, I used to have the static geometry of the Juggler, probably from the Raytracing 1.0 disk mentioned here, but that was lost several computers ago. RT 1.0 has been found! You can read the story of its rediscovery here, as well as see the Juggler rendered dynamically in your browser using the algorithms and data from the disk.

A scene file describing the motion of the Juggler doesn't exist. As Jimmy Maher confirmed while researching his 2012 book about the Amiga, each frame of the Juggler animation had its own scene file, similar to the way RenderMan has always worked. And unfortunately, these per-frame files were never published and probably haven't survived. (The single frame file on RT 1.0 differs slightly in lighting and camera angle from the Juggler frames.)

When I announced on a few newsgroups that I'd created this page, I acknowledged several people by name who helped me track down Juggler information and original files, and it was one of them who eventually got me in touch with Eric. I've also received helpful information and feedback from several people since then. My thanks to Bob Eaton, Eric Fleischer, John Foust, Marvin Landis, Scott Peterson, Jimmy Maher, and Patrick de Zoete for their assistance, which in some cases involved rummaging through boxes of decade-old magazines and floppies to aid failing memories.

And I'm sure most people reading this would join me in thanking Eric Graham for allowing us to share a moment of nostalgia in this way.