When I picked up the Sunday NY Times in my driveway on November 7, 2015, I believed the world was about to change. That morning, the Times, in partnership with Google, distributed 1.3 million Cardboard VR headsets. A generation of people would be exposed to VR and the world would never be the same.
Between 2020 and 2022, Meta/Facebook has sold 15 million Quest 2 headsets. We are square in the middle of a new generation of VR usage. (We have 3 Quest 2 headsets in our house.)
This upsurge of interest in virtual reality has me nostalgic for my time in the first VR wave, back in the 1990s (technically, this might have been the second or third wave) but when I started to research on the web, you would see names like Jaron Lanier, Ivan Sutherland, John Carmack and even the Nintendo Virtual Boy, I was upset that the articles din’t mention my corner of the universe (Sense8, Gemini, etc.)
I realized that a good reason these stories didn’t cover Sense8 and Gemini was that there are very few artifacts available on the web. No images. No videos. No stories. So the goal of this blog is to rectify that situation. I found a collection of old DVD with source code, executables, demos and notes. I am going to cull through this info a post what I remember…and what ever I can actually run on computer 25 years in the future.
I don’t know if I am violating someone’s copyright, but I asked my AI (OpenAI Codex) to help recreate the World Toolkit libraries so I could re-compile my old apps, like SpaceRocks. And it worked. And it only took like 15 minutes!
WTK running on a Mac!
Nearly thirty years ago, I developed several real-time 3D applications using Sense8’s WorldToolKit. (I have written about it previously here.) The software ran on the desktop PCs and specialized VR hardware of the era. Like many projects from that period, the source code and original assets survived long after the operating systems, development tools, and commercial libraries needed to run them had disappeared.
Recently, I decided to see whether these applications could be brought back to life.
The project began with a game called Space Rocks. It eventually grew into something more ambitious: a modern compatibility layer for WorldToolKit applications and the restoration of another substantial project—a virtual Mars rover.
Space Rocks
Space Rocks is an asteroid-style game that I originally wrote around 1996–1997. It combines real-time 3D graphics, textured models, animation, sound, collision detection, mouse control, and several scripted sequences.
The source code was still available, along with its original models, textures, sound effects, and configuration files. What was missing was the environment in which it had been built.
The original application depended on Sense8 WorldToolKit, a commercial 3D and virtual-reality development system. It also assumed the graphics conventions, input devices, file formats, and compilers of a 1990s PC. Simply recompiling the old C source on a modern computer was not an option.
I have tried to bring it back to life in the past:
This time, the objective was not to rewrite Space Rocks, but to preserve as much of the original application as possible.
Along with ChatGPT Codex (GPT 5.6 Sol light), we created a modern macOS build around the existing source and gradually worked through the incompatibilities. The application could eventually open a window and draw its world, but getting from “it runs” to “it behaves correctly” involved a long series of smaller discoveries.
Some of the problems were immediately visible:
Textured objects worked from outside but disappeared when viewed from inside.
The opening Space Rocks logo did not render.
Explosion frames were missing.
The ending sequence failed.
Mouse movement did not align correctly with the screen.
Vertical mouse control was reversed.
The game began with an unintended explosion instead of placing the player inside the ship.
The Sense8 logo was mirrored.
Sound initially did not play.
Each problem exposed another assumption made by the original runtime. Polygon winding, back-face culling, texture orientation, coordinate conventions, animation timing, relative file paths, audio initialization, and camera transforms all needed to be reconstructed.
Eventually, the opening sequence, internal ship view, gameplay, sound, explosions, textures, and ending sequence were operating again.
The result is not a visual imitation of Space Rocks. It is the original C application, running through a newly implemented compatibility layer.
Building WTK-NG
Restoring Space Rocks required recreating enough of WorldToolKit for the original program to run. That work became a separate open-source project called WTK-NG.
WTK-NG is a compatibility runtime for legacy applications written against the WorldToolKit API. It does not attempt to reproduce every feature of the original commercial product. Instead, it implements the parts needed by the surviving applications while preserving their original structure and behavior wherever practical.
The runtime currently provides support for areas including:
Scene graphs and object hierarchies
Viewpoints and camera transforms
Geometry and model loading
Legacy NFF and OpenFlight assets
Textures and materials
Lighting
Animation sequences
Collision detection
Mouse and keyboard input
Overlays and simple user-interface elements
WAV audio playback
Compatibility implementations for older WorldToolKit functions
SDL2 provides the modern window, input, and audio foundation, while OpenGL handles rendering. The compatibility API allows the original application code to continue calling familiar WorldToolKit functions.
One of the most interesting aspects of this work has been discovering how much behavior was implicit in the old runtime. A function’s name and arguments are only part of an API. Applications also depend on undocumented conventions: coordinate handedness, transformation order, default lighting, normal orientation, texture wrapping, back-face behavior, and the meaning of “forward.”
Recreating those conventions accurately is often more important than merely reproducing the function signatures.
We also separated the compatibility layer from Space Rocks itself. WTK-NG now has its own public Git repository, allowing it to support other surviving WorldToolKit projects.
Once the game was working locally, the next challenge was making it shareable.
A binary that runs on one development computer is not yet a distribution. The initial executable depended on Homebrew installations of SDL2 and libjpeg at absolute paths. It also expected all its legacy assets to be present in the current working directory.
We created a repeatable macOS packaging process that builds a conventional application bundle containing:
The Space Rocks executable
All required models, textures, sounds, and animation frames
Private copies of SDL2 and libjpeg
A launcher that establishes the expected asset directory
Rewritten dynamic-library paths
An application property list
An ad-hoc code signature
Running:
make dist-macos
now produces a self-contained ZIP archive containing Space Rocks.app, ready to attach to a GitHub release.
The current package is an Intel x86_64 build. It runs on Intel Macs and can run on Apple silicon through Rosetta 2. A future improvement would be a universal build with native Apple silicon support.
Returning to the Mars Rover
With Space Rocks running, we turned to another WorldToolKit application: a virtual Mars rover.
The Rover project is more complex than Space Rocks. I have also written about it previously. It combines a detailed vehicle model with articulated wheels, terrain following, surface textures, camera control, lighting, and vehicle movement. Some versions of the original project also anticipated specialized VR equipment, including a Polhemus tracker.
For the initial restoration, we deliberately focused on the desktop experience. The goal was straightforward: run the application locally using a mouse and keyboard. Legacy tracking hardware could wait.
Once the missing source and assets were gathered, the Rover application compiled against WTK-NG and began rendering. As with Space Rocks, however, the first visible result revealed several deeper compatibility issues.
Initially:
The rover appeared upside down.
The terrain seemed to be rendered from below.
The wheels did not rotate.
Forward motion moved the rover backward.
The left wheels rotated in the opposite direction from the right wheels.
Parts of the rover floated above or passed through the terrain.
The lighting was badly unbalanced.
Wheel facets disappeared under some lighting conditions.
The wheels changed brightness dramatically as they rotated.
The original executable provided an invaluable reference. Screenshots showed not only the intended model orientation, but also the visual relationship between the wheels, body, antenna, terrain, and light source.
Reconstructing Rover Movement
Correcting the Rover was not simply a matter of rotating the entire model.
The original program used a particular combination of coordinate axes, model orientation, and transformation order. WTK-NG initially interpreted some of these differently. We corrected the rover’s base orientation, reversed its movement direction, and accounted for the mirrored geometry of the left and right wheel assemblies.
The wheel problem was especially instructive. Wheels on opposite sides of a vehicle may need opposite local rotation signs even though they are all moving the rover in the same direction. Applying one rotation uniformly made half the wheels appear to run backward.
Terrain following required more than assigning the rover a height at its center. On an uneven surface, each wheel contacts the terrain at a different elevation. A vehicle can be correctly positioned at its center while its front wheels float and its rear wheels disappear underground.
The improved approach samples the terrain at multiple points around the rover. Those samples are then used to calculate both its elevation and its pitch and roll. This allows the vehicle body to follow the local slope instead of remaining rigidly horizontal.
It is still a simulation rather than a full suspension and tire-physics model, but it more closely reflects the behavior of the original program.
Solving the Pulsing Wheels
The most persistent visual problem involved the rover’s wheels.
As the wheels rotated, they repeatedly changed from dark brown to an almost glowing tan. At first this appeared to be a general brightness problem. Reducing the wheel material brightness helped at one angle but made the rover too dark at another.
The real issue was the interaction between rotating geometry, polygon normals, and the lighting model.
The original low-polygon wheels depended on visible facets to communicate their cylindrical form. Smooth or overly strong modern lighting erased those facets. At the same time, rotating the normals caused different faces to move rapidly into and out of direct illumination, producing the distracting pulse.
Several approaches were tested:
Reducing overall brightness
Rebalancing ambient and directional light
Preserving flat shading
Rotating normals with the wheel geometry
Stabilizing the lighting calculation
Separating wheel lighting from the rest of the rover
The final solution treats the wheels more like the original renderer did: their color remains stable as they rotate, while subtle polygon outlines preserve the faceted shape. This avoids the flashing without turning the wheels into featureless dark discs.
That work also led to useful additions in WTK-NG, including finer control over geometry lighting, brightness, normal handling, stable lighting, and outlines.
What Was Preserved
The goal of this work has not been to modernize the applications into entirely new games. The objective has been to preserve their original code, assets, appearance, and behavior while replacing the unavailable runtime beneath them.
That distinction matters.
A complete rewrite could produce smoother graphics and more contemporary controls, but it would no longer be the same software. By recreating the runtime interface, we can study and run the original programs—including their design decisions, limitations, and visual character.
The restored projects now consist of three related pieces:
Space Rocks, the original asteroid game running again on modern macOS
WTK-NG, the open compatibility runtime that makes the restoration possible
Rover, a second and more demanding WorldToolKit application that continues to improve the runtime
Each application helps validate the others. Space Rocks exercises animation, sound, collision detection, scripted sequences, and first-person rendering. Rover exercises articulated models, terrain following, transformation hierarchies, flat-shaded geometry, and more complex lighting.
What Comes Next
There is still more to do.
The current macOS distributions use Intel binaries. Native Apple silicon and Windows builds would make the projects easier to share. Proper Developer ID signing and notarization would remove the additional Gatekeeper step on macOS. There are also opportunities to improve terrain contact, camera behavior, packaging, documentation, and compatibility with additional WorldToolKit applications.
A browser-based interpretation of Space Rocks has also been explored. That approach is useful for accessibility and sharing, but the native compatibility version remains the most historically faithful because it continues to execute the original application logic.
Most importantly, the projects are alive again.
What began as an attempt to run one old C program became an exercise in software preservation: recovering not only source code and assets, but also the undocumented behavior of an extinct development platform.
Thirty years later, Space Rocks is flying again, the rover is crossing Mars, and the foundation now exists to revive other WorldToolKit projects as well.
Credit for the rover app belongs to the late Dave Hinkle and others over the years.
Yet another blast from the past! I recently came across an Medium article (posted to LinkedIn) from VR rockstar Tony Parisi. In the article, Tony mentions another VR player from the 90’s, Mark Pesce. Together, Tony and Mark were the co-founders of the VRML standard which allowed VR content to be delivered over the early interweb.
Tony’s article chronicles his recent experimentation with vibe coding and the potential impact of $0 investments on the idea economy…along with hope that this could finally trigger adoption of the metaverse concepts beyond science fiction novels.
Prof. Bob Stone is at it again, dusting off old data sheets and “application sheets” from old projects.
Still ploughing through the years of previous material I’ve collected. This time, I’ve merged a load of pdf “applications sheets” sheets from the 1990s and early 2000s, when I was part of the UK National Advanced Robotics Research Centre, VR Solutions Ltd (the commercial VR spin-off from that Centre) and Virtual Presence Ltd (we were sold off to them, again in the 90s). Not 100% sure of the accuracy relating to the listed techniques for pulling these together, but they’re close! We had a busy decade, that’s for sure!!
Bob Stone referenced this in a LinkedIn post where he provides an overview of VR in the 90s based in the UK. The writeup he posted can be found here, too.
Can’t believe it’s 30 years to the month that Andrew Connell and I launched the world’s first collaborative VR initiative – VRS (Virtual Reality & Simulation) from our base at the time, Advanced Robotics Research Limited (the operating company behind the UK’s Advanced Robotics Research Centre in Salford). This was the first VR programme in the world that was fully funded by the industrial sector in an attempt to share experiences before committing to adoption. The “try-before-you-buy” Initiative was officially launched by the Lord Wade of Chorlton and was initially supported by Bell Northern Research (Europe), British Nuclear Fuels plc, GEC Alsthom Engineering Systems Limited, Hunting Engineering Limited, ICI Chemicals & Polymers Limited, M W Barber Group Limited (an SME involved in surveying and civil engineering), Multi-Design Consultants Limited (architectural design SME), North West Water Group, Rolls-Royce plc, United Kingdom Nirex Limited, University of Salford, Vickers Shipbuilding and Engineering Limited (today part of the BAE Systems empire) and Westlakes Research Institute. Later collaborators included the NHS and Sainsburys. Some amazing concept projects were delivered in that time, with a good number convincing the sponsors to go on to adopt VR in their businesses. Real pioneering days!
SpaceRocks was my ongoing Sense8 WorldToolKit demo app back in the 90s. While I no longer have access to the WTK libraries, I have been working to bring it back to life. My latest version (Dec 2021), for the Oculus Quest 2 and built with Unity, can be found here:
Here is a link to my original SpaceRocks demo built back in 1997 when I was working for Sense8. The idea was to be a tribute to the classic Asteroids game built in 3D and using photos from the Hubble Space Telescope as textures for the background and asteroids.
Instructions for “sideloading” a APK file to your Quest can be found with a quick internet search, but here is one option:
Professor Bob Stone recently found an 1999 paper on VR for UNESCO. I was excited to see the paper referenced the Stonehenge work he had done for the UK Heritage folks with WTK
