Map Compiling Theory

Original posted with permission (Source).
Introduction
This article will explain how the processes of converting an editor map file into a playable BSP map. Keep in mind this is not a tutorial on how to compile a map. It is to help understand what has to happen and why other things (like preventing leaks) are important.
The process of creating a playable Source map starts with an editor .vmf file. This file contains all the polygon data (aka brushes), entity data, and texture data that will define how a finished map looks and acts. All the editors essentially serve the same purpose, to define how a level will appear. A VMF file stores entity and brush info to be used during compilation.
Compiling converts a VMF map file used in editors, such as Hammer, to a playable BSP Map uses the process below:
- Reading the .vmf file
- Executing the BSP program against the .vmf file
- Executing the VIS program against the new .bsp file
- Executing the RAD program against the .bsp file to add lighting information
- Moving the now finished .bsp to its respective maps directory
- Executing the game with parameters to run the map
(Most editors/compilers come with a batch shell script (.bat) to go through the processes)
Overview of the compile process
The following chart shows the overall process required to create a playable map file (.bsp).
<placeholder> .vmf > VBSP > intermediate .bsp > VVIS > VRAD > final .bsp </placeholder>
The compile tools
The table that follows should give you a good idea of what each tool does. The descriptions have been kept simple, since the tasks the tools perform involve some complex math and algorithms that you as a mapper have little need to know. As long as you understand what the tools are used for, that should suffice.
Tool | Purpose |
VBSP | The BSP tool is the one that actually converts the .vmf file data into a usable .bsp file that the game engine can load. Once the BSP tool is run the map is essentially playable with the exception that it will have no visibility matrix and will have no lighting at all. Those crucial features are applied by the next two tools VIS and RAD. |
VVIS | This tool creates the visibility matrix for the map based on the level's geometry. This matrix is what determines which polygons the player can see, might see, and can't see from any given point within the level in game. It is critical that this tool be run on every .bsp you create. If it is not run then the entire level, along with models and props will be visible all the time which would, in all but the simplest of box maps, reduces the game framerate (which causes lag) and making the map unplayable. In-depth information about VIS can be found at visibility determination. |
VRAD | The RAD tool, or Radiosity tool, is responsible for generating and applying all lighting effects in a level. Everything from entity lights and the "sky" down to the lowly texture light has to be handled by this tool. A .bsp that has not had RAD run on it will appear pitch black in game or full-bright depending on video-mode and console-settings. This tool is normally the one responsible for slowing down compiles most of the time as it has to process huge amounts of data in the completion of its task. In-depth information about RAD can be found at RAD (technical). |
Compile managers
- Batch Compiler - Supports Quake, Valve, Zoners, and CSTTools
- VBCT - For the Source engine.
Compile Pal - GUI compiler alternative for the Source engine
Which compile tools?
Hammer ships with Valve's own compile tools. These are denoted by the presence of a 'v' preceding the tool name in the tools file name (i.e. vbsp.exe, vvis.exe, vrad.exe).




See also
- Source BSP File Format - a look at the compile tools from a technical standpoint (from the author of VMEX and other Source tools).