Map Compiling Theory

Original posted with permission (Source).

Introduction

Many people simply do not know or understand how and why a Source map needs to be compiled. A few do not even realize that their maps are being compiled. In this article I am going to attempt to explain how the process of creating a playable map from an editor file takes place. Though I will go into some detail on certain aspects of the compile process keep in mind this is not a tutorial on how to compile a map. It is to help you to 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 file. This file contains all the polygon data (aka brushes), entity data and texture data that will define how your finished map looks and acts. All the editors essentially serve the same purpose--to define how a level will appear. This is a key concept to understand: this is ALL the editors do. They do not create finished maps. All they do is give you a convenient way to prepare the polygon, lighting, and entity data for later processing. Once you have built a level in your editor and saved it to disk for safekeeping you will want to playtest it in Source to see how it turned out. To make sure that all your entities are working properly, that your lighting is correct, and that you have no bad "brushwork". In Hammer many people just "Run" the map and then, after some time "thinking", their computer opens Half-Life 2 and plops them gracelessly into their map. This simplistic event hides a more complex set of operations taking place out of sight of the user. Now, to the heart of the matter, what happens during that sometimes excruciatingly long "thinking time"? With even a decent sized map most people will notice their hard disk pounding away reading and writing data during this time. So what is your computer doing? It is compiling your map! Your editor has invoked a batch shell script (.bat) and is doing all of the following:

1. Reading the .vmf file
2. Executing the BSP program against the .vmf file
3. Executing the VIS program against the new .bsp file
4. Executing the RAD program against the .bsp file to add lighting information
5. Moving your now finished .bsp to your Mods /maps directory
6. Executing the game with parameters to run your map

You may be thinking "Damn, that's a lot of stuff to do. What's it all for?". Well that's what I'm here to explain.

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 will be visible all the time which would, in all but the simplest of box maps, make the map unplayable due to video-lag. 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

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). In addition, Adam McKern is working on a new set of Source compiling tools (CSTBSP, CSTVIS, CSTRAD--known collectively as CST) that have refinements over and more options than the default tools. As of now CST does not have any big improvements over the Valve tools and it is not as thoroughly tested.

See also

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