Introduction

A game’s 3D artwork might survive as an editable scene, an exported mesh, a runtime model or nothing more than a rendered movie. Those files tell different parts of the production story. This hub follows the modelling and animation tools used from the 1990s into the early 2010s, with original documentation and surviving toolchains that help make sense of their output.

---

From Modelling Software to Game Assets

An editable scene is not necessarily a game-ready model. Exporters, conversion scripts and build instructions show which parts of a scene reached the engine. In Quake II, for example, a compiler reads triangle data and writes an MD2 model rather than shipping the author’s scene file ¹.

The following sources show what survives at different stages of a 3D pipeline:

Tool or pipeline	Evidence to inspect	What it tells you
Quake II qdata	Base mesh, animation frame files and models.c	How triangle input becomes an MD2 model 1
Doom 3 model export	.ase or .lwo props; Maya .mb scenes, .def export blocks and MD5 character files	Why static and animated models leave different evidence 2
SOFTIMAGE 3D Design Toolkit for Saturn	Exported files and target preview tools	How artists checked textures and geometry for the console 3
LightWave 6 object files	FORM and LWO2 header, surface and image chunks	Object structure and dependencies that may be missing from an archive 4

Quake II’s Model Compiler

The released Quake II tool source gives a concrete example of the conversion step. In models.c, the base mesh and animation frames can be read through either LoadTriangleList or Load3DSTriangleList. Frame lookup supports names such as run.1 and run1.tri; the default model output is tris.md2 ¹.

The compiler rejects an animation frame when its triangle count differs from the base mesh. So a set of frames can look intact in isolation yet fail as a model sequence ¹. The FindFrameFile function and triangle-count error in the source show where those checks happen.

---

Why Does a Doom 3 Archive Have Several Model Formats?

The original Doom 3 model-export guide separates static props from animated characters. The engine can load .lwo LightWave objects and .ase 3ds Max exports as static models. For characters, the documented route starts with Maya binary .mb scenes and uses exportModels to produce .md5mesh and .md5anim files ².

The export declarations live in .def files: mesh and anim entries name their Maya inputs, while options can set a frame range or destination ². That makes a .def file a useful bridge between source scenes and the MD5 files found in game data. Static models have a different dependency to watch: the guide derives material names from texture paths embedded in the export, so a moved .ase file may have intact geometry but broken material references ². The released Doom 3 source README also identifies the included Maya export plug-in code; it does not include the game’s art assets ⁵.

---

How Were 3D Game Cut Scenes Developed?

Prerendered cutscenes play back finished images; real-time cutscenes ask the game engine to draw each frame. Offline rendering can spend longer on a frame, but the finished video cannot reveal an editable mesh, rig or lighting setup on its own. An archive of original scenes tells a different story from one containing only rendered frames or the encoded movie.

Modelling and animation packages such as 3D Studio Max, Maya and Softimage are separate from compositing tools, which combine rendered layers and effects. The existing community discussion of 1990s cutscene software is useful for research leads, rather than proof of a particular game’s production setup ⁶.

Compositing and Animation Tools

Compositing packages worth looking for in production records include Combustion, Quantel Henry, After Effects, Nuke and Fusion. The version and contemporary vendor matter when identifying an installation; a product’s later branding does not date an old project. NaturalMotion’s morpheme belongs to the animation-middleware side of the investigation, rather than a list of offline renderers. A game’s credits, project files or developer account make a stronger case for any particular tool than a general software list.

---

3D Art Software

These modelling packages each left distinctive documentation and development files.

3D Studio (Max)

The distinction between a native scene and an exchange file matters when examining 3D Studio material. Quake II’s Load3DSTriangleList path is evidence of an importer in the toolchain, not proof that every compatible input was originally authored in 3D Studio ¹. The dedicated page covers the DOS-era tools and the later Max line:

Maya

Maya and its predecessor tools belong to a longer history of workstation-based modelling and animation. For the history of Alias PowerAnimator and Maya in game development, see:

Softimage and the Saturn Design Toolkit

Sega’s September 1995 Developer News describes a SOFTIMAGE 3D Design Toolkit tailored to the Saturn. It offered Saturn-format export and a viewer based on SGI IRIX and Saturn CartDev, alongside interactive colour reduction, texture painting and UV-coordinate editing. The newsletter specifies SGI workstations running IRIX 5.2 or 5.3 ³.

Artists could adjust textures and inspect the exported result on target hardware before it entered a game. The newsletter also pins this toolkit to specific software and workstations; a generic Softimage installation would not tell the same story.

LightWave

The LightWave SDK object-format specification, dated 9 November 2001, documents LWO2, introduced with LightWave 6.0. A file starts with FORM, a four-byte big-endian size equal to the file length minus eight, and then LWO2. That header distinguishes this version from other .lwo files ⁴.

Objects contain points, polygons and surfaces, but surfaces can also reference external images, plug-ins and animation envelopes. If a recovered model opens without its textures, the references may be broken even when the artwork survives elsewhere. The SDK’s annotated object-file examples provide small files to compare against a hex dump ⁴.

LightWave Used by Team17 for Worms on the Amiga

Retro Recipes explores an original Worms development Amiga 4000 with developer Chris Blythe. The recovery shows LightWave animation files, full-motion video assets and unreleased artwork on the machine’s ageing drives.

---

Other 3D Art Software

Some packages changed names between releases, complicating the search for their old project files and documentation.

3D-Brush (Later 3DCoat)

3D-Brush was created by Andrew Shpagin, who had previously worked at GSC. In a 2018 interview with the Pilgway team, the developers describe its origin as a character-texturing tool and date the first $70 sale to 2007 ⁷.

Shpagin’s 3D-Coat 2.07 announcement, posted on 10 March 2008, explains the rename: the 3D-Brush name was too close to ZBrush for trademark registration. Existing users could carry over their serial numbers, and he described installing over the earlier version to retain brushes, materials and settings ⁸. These details help connect installations bearing the two names; they do not establish which commercial games used the early tool.

This screenshot from the old 3d-brush.com website shows the 1.82 Beta interface:

Visual Reality

Visual Reality 2.0 by Visual Software remains a research lead. The archived Visual Software website from November 1999 is retained here as a starting point; a dated manual, catalogue or developer account would be needed to establish a specific game-production workflow.

---

References