id Tech 3 Optimization


This is going to be a rather large guide on map optimization for id Tech 3 engines, so I've broken it down into separate articles. Each article will cover a specific subsection in understanding the optimization process.

It is necessary to explain in a fair amount of detail the theory of how the engine works. A lot of it is quite advanced and I expect a number of readers will feel a bit overwhelmed, but take heart in that you don't have to fully understand all the theory, but it will help you understand the principles that a typical level designer needs to build a solid map and diagnose problems.

It is assumed that the reader has a basic understanding of how to build a basic map with GtkRadiant, compile it, and load it in the game. Basic best practices such as using caulk on unseen faces is assumed.

Quick Glossary of Terms

This is the compiler for id Tech 3 maps. It runs 3 primary operations in stages: BSP, VIS, and LIGHT.
BSP (Binary Space Partition)
An recursive (it repeats itself until the task is done) function of Q3Map2 that takes the entire volume of a map and continuously breaks it up into smaller volumes until every single area is a convex volume.
BSP Tree
A binary tree data structure that is a representation of objects within the space as generated by the BSP process.
In general, this is any point on the BSP tree. Parent nodes are the higher order of two children nodes. A branch represents a subsection of everything that belongs to the child of parent node. Each node represents a portal created which partitions (splits) a volume of space.
Leaf Node or Leaf Volume
The end point of each branch of the BSP tree. Each leaf volume represents the a space that has not been subdivided because it is a single convex volume.
VIS (Visibility)
This is the second stage of Q3Map2's compiling process, following the BSP stage. The relevant part of this process is the creation of the PVS table for the portals in the map. As the player's viewpoint moves around a fully "vis'ed" BSP, different areas become visible or hidden depending on which area the viewpoint is in.
A portal is created for every face of a leaf node (a single convex volume) that is bound by another leaf node. Each Portal is like a window from one node looking outwards into another. The Portal information is not needed in the BSP, but it is essential to VIS, so it is stored in the portal file "mapname.prt".
PRT (Portal) File
The PRT file ("mapname.prt") is a temporary file that is generated by Q3Map2's BSP process and saved for use by the VIS process. The PRT file stores portal information that is not needed by BSP, but it is essential to VIS. The PRT file can also be imported into GtkRadiant for a visual representation of the generated portals.
PVS (Potentally Visible Set)
PVS Table
Backface Cull
HoM ("Hall of Mirrors") Effect
"HoM" is the term given to the rendering artifact as seen when the GPU is trying to render a surface with nothing in the pixel buffer (as in a surface without a texture). With nothing to render, the GPU fills it with whatever pixels were last in the buffer, producing a "blurring" effect.
Strictly speaking, when the GPU has to render a surface above another one. Generally, this refers to having a brush that is overlapping another one, causing the GPU to render both brushes.
Structural Brush
This is the default state for brushes when Q3Map2 performs the -VIS stage. All brushes in this default state generate portals along their planes.
Detail Brush
Brushes flagged as "detail" are ignored by Q3Map2's -VIS stage. Detail brushes do not generate portals.