My application · Real-time ray tracing
In November 1986, Eric Graham had an Amiga ray-trace a juggler: 24 frames, each taking about an hour to calculate. This tribute recreates the scene live on your graphics card, with a free camera, a chunky-pixel 1986 mode and the original ‘ding’.
A personal making project.
The demo loads when it comes into view and starts with a click, in 1986 mode: 320 × 200 pixels in a 4:3 frame, 24 steps per loop and one ‘ding’ per catch. 2026 gives you smooth motion at full resolution. Choose Take control to orbit the juggler with a mouse or finger, zoom with the wheel or a pinch, and adjust the speed from 0.01× to 2× using the control at the bottom. The sound changes pitch with the speed, like a tape. Use the comma and full stop keys to step through the 24 poses; the space bar pauses. The demo toolbar hides after three seconds of inactivity and returns when you move. The demo pauses automatically when it is off screen.
The 1986 original
Eric Graham bought an Amiga 1000 in mid-1986 and wrote a ray tracer in a single day that November. He used it to calculate 24 images of a figure juggling three mirrored balls: 320 by 200 pixels, 64,000 rays per image, and about an hour of processing per frame. The images were encoded in the Amiga’s HAM mode, displaying 4,096 colours at once, compressed losslessly to around 10 kB per frame, and played as a 0.8-second loop at 30 frames per second, with one ‘ding’ per catch.
Commodore was initially sceptical. The company released the animation in November 1986 to demonstrate the Amiga’s capabilities, but initially thought the images had come from a mainframe. Graham sent them his renderer so they could calculate the frames themselves. That ray tracer later became Sculpt 3D, released in autumn 1987.
What survives. The original camera and movement data have been lost. What remains is the set of 24 frames, the recovered Raytracer 1.0 source code from 1987 with its robot.dat scene file, and a recording from a real Amiga’s audio output. This version was reconstructed from those sources.
Two display modes
1986. The ray tracer calculates at exactly 320 × 200, quantises each colour to 4 bits per channel (⌊16·colour + 0.5⌋, as in rt2.c), and displays the result using nearest-neighbour scaling in a 4:3 frame, with the 5:6 pixel aspect ratio of a monitor of the time. Motion steps through the original 24 discrete poses at 30 per second. One characteristic is deliberately omitted: the HAM encoder’s per-scanline colour fringing is not emulated.
2026. The same shader renders at your screen’s native resolution, including its device pixel ratio, with FXAA as a lightweight second pass. The 24 poses are interpolated along a closed curve for smooth movement. The vertical field of view matches the original, at approximately 50°; wider screens reveal more at the sides.
Reconstructed from 24 frames
Without the original scene and movement data, the pixels themselves are the reliable reference. Every parameter in this version is derived from them or taken from the 1987 source code.
Fitted to the frame data: the eye is at (−6, 3.32, −6), looking at 45° across the chequerboard diagonal, almost level, with the horizon at row 97 of 200 and a focal length of 215 pixels when using square image pixels. The figure stands at the world origin.
Ball centres, head, hands, feet and joint bend directions were measured in all 24 frames. The ball path is a Fourier fit with three harmonics per coordinate, with a reprojection error of about 2 pixels, placed on a slightly tilted 3D juggling plane. The hands move on a plane just behind it, so they meet the balls even from a freely positioned camera. Each ball completes its circuit in three loops, with the three balls one-third of a cycle apart.
Seventy spheres use the materials and colours from robot.dat and the lighting model from rt1.c: wrap ambient (n·ẑ + 1.5) · 0.4 × 0.25, one distant light with cos/r², binary white highlights above cos² > 0.95, recursive mirror reflections × 0.9, hard shadows and no gamma correction. The floor is an exact port of gingham(): tiles three units wide, mirrored across both axes, including the double band at the origin visible in the original.
The body follows Ben Hanke’s slimmer, camera-independent 3D pose, with fixed arm and leg lengths. Two-bone inverse kinematics keeps the hands and feet at their measured targets, so the balls do not pass through the head or torso when viewed from other angles.
One ding per loop, at the catch: an almost pure 1 kHz sine wave with a stepped envelope in 50 ms intervals, lasting about 0.5 seconds. It was measured from Ernie Wright’s recording of a real Amiga’s audio output. Web Audio plays the sample like tape: at speed r, its pitch rises by r and its duration shortens to 1/r, including when the speed changes during playback.
A verification mode renders each of the 24 poses at 320 × 200 for pixel-by-pixel comparison with the original frames. This makes the reconstruction verifiable, including after later changes.
How the GPU renders it
Each frame sends the 70 spheres — position, radius and material — and five bounding spheres to the GPU as uniforms. No meshes or textures are used.
A GLSL ES 3.0 fragment shader casts a ray from the fitted camera position through each pixel. The whole screen is covered by one triangle.
Ray–sphere intersections are calculated analytically. The limbs are arranged in five groups, each with a bounding sphere, so most rays only need to test a few spheres. The floor is an infinite plane.
At each hit point, a shadow ray is cast towards the light, with hard shadows, wrap ambient and highlights following rt1.c.
The three balls reflect up to twice, with a reflection factor of 0.9, then fall back to the sky. If frame times remain high, the frame budget reduces the workload in stages: one reflection, followed by a lower rendering scale in 2026 mode. When performance improves, it tries a higher level again.
1986: 320 × 200 scaled to a 4:3 frame with nearest-neighbour sampling and 4 bits per channel. 2026: full resolution, with FXAA as a lightweight second pass.
JavaScript modules, three GLSL shaders and Web Audio are all it needs. The demo follows the same strict Content Security Policy as the rest of mahieu.nl, with no external scripts or inline code.
A dedicated animation clock tracks elapsed scene time. Pausing and resuming does not cause a jump, and the 0.01× to 2× speed range applies to both visuals and sound, including during playback.
If the browser loses its graphics context, for example when switching tabs on a phone, the demo rebuilds the renderer and either resumes or returns cleanly to the start screen. This also works while paused.
Eighty-two unit tests cover the scene, camera, clock, audio, frame budget, controls and renderer behaviour. A further 20 Playwright tests in Chromium check controls, focus, pausing, audio, full-screen display, context loss and reference images for the 24 poses. Keyboard operation, focus order and screen reader status messages are included.
Sources and credits
This tribute is possible thanks to the people who preserved, recovered and studied the original. These are the sources behind the reconstruction.
The recovered source code (rt1.c–rt3.c) and robot.dat scene file, extracted from the original floppy disk by AlphaPixel and published on GitHub. In February 2026, Eric Graham gave permission for anyone to use the code provided he was credited. It supplies the materials, floor and shading model.
The 24 original frames as PNG files, the juggler.wav recording from a real Amiga, and the history of the demo, including Graham’s own recollections. These provide the calibration and verification material for this reconstruction.
A step-by-step reconstruction deriving the camera, ball trajectories and shower juggling pattern: a high arc from left to right and a low return arc. Used as a reference for the high and low paths.
A previous real-time version of the Juggler, used as a reference for a camera-independent 3D pose.
Graham’s own article on making the Juggler. The program announced in the article became Sculpt 3D. The demo itself appeared as version 1.2 on Fish Disk 97.
Why it matters
What this demonstrates. A ray tracer no longer needs a render farm: what took an hour per image in 1986 can now be calculated dozens of times a second by a graphics card, in a browser, without a plug-in. It also shows how 24 images and some C code can become a working, tested and accessible application through careful measurement.
How it relates to my services. It is the same approach I bring to client work: start with what is available, build the smallest working version, measure, test and then expand. That is what taking an idea to a proof of concept means in practice.
Verifiable evidence
Frequently asked questions
An animation created by Eric Graham in 1986: a figure juggling three mirrored balls, ray-traced on an Amiga 1000 and released by Commodore as a demonstration. It uses 24 frames in HAM mode at 320 by 200 pixels, in a 0.8-second loop with one ‘ding’.
No original frames are played back. Every frame is calculated live in your browser by your graphics card. The scene, camera and movement were reconstructed from measurements of the 24 frames and the 1987 source code.
That was the original resolution: 320 by 200 pixels, stretched to 4:3 as on a monitor of the time, with 4 bits per colour channel and 24 steps per loop. Choose 2026 for smooth motion at full resolution.
Yes, in a modern browser with WebGL2. Drag to rotate the camera, pinch to zoom and use two fingers to pan. If frame times remain high, the demo reduces the workload: first to one reflection, then to a lower rendering resolution.
This is a tribute that uses no original images. In 2026, Eric Graham said anyone could use his code provided he was credited. Both the demo and this page credit him and the other sources.
It follows the same approach I use for client projects: start with what is available, measure, build the smallest working version and test it. That is how an idea becomes a working proof of concept.
Contact
You’re welcome to get in touch.
Prefer to contact me directly? Call +31 6 1400 2312 or email mwd@mahieu.nl.