This video demonstrates what can be achieved using Minko, the next-gen 3D engine for Flash “Molehill” I’m working on. The environment is a Quake 3 map loaded at runtime and displayed using high definition textures. The demo shows some technical features such as:
- Quake 3 BSP file format parser
- Potentially Visible Set (PVS)
- complex physics for spheres, boxes and convex volumes using BSP trees
- light mapping using fragment shaders
- materials substitution at runtime
- dynamic materials using SWF and the Flash workflow
- first person camera system
Quake 3 BSP file format
Quake 3 uses the version 46 of the BSP file format. It’s farily easy to find unofficial specifications for the file format itself. Yet, parsing a file and rendering the loaded geometry are two very different things. With Minko, it is now possible to do both without any knowledge of the specific details about the BSP format and algorithms. Still, those are interesting algorithms so I wanted to explain how it works.
Binary Space Partioning (BSP) is a very effective algorithm to subdivise space in two according to a “partition”. To store the subdivided spaces, we use a data structure called a BSP tree. A BSP tree is just a binary tree plus the partition that separates both children. This picture shows the BSP algorithm in 2 dimensions:
In that case, each node of the BSP tree will store the partition line. When working with 3D the partition will be a plane. We can then walk through the tree by simply comparing the location of a particular point to the partition. A good use case is 3D z-sorting: we simply have to compare the location of the camera to the planes stored in the BSP nodes to know which child should be walked through (or renderered) first. But in Quake 3, the BSP tree is used for:
- physics: the tree makes it possible to optimize collisions detection by performing only the required computations and tests
- rendering optimization: by locating the node where the camera is, we can know what is the Potentially Visible Set (PVS) of polygons that should be renderered and ignore the rest
In each “*.bsp” file are stored the BSP tree itself, the partition planes, the geometry, the PVS data and even bounding boxes/spheres for each node to perform frustum culling. This data is very precious and is compiled directly in the file by tools like GTKRadiant.
HD textures were provided by the ioquake3 project.