Map Compiling Theory

This article or section should be converted to third person to conform to wiki standards.

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. This article will explain how the process of creating a playable map from an editor file takes place, and 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 this article is 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, 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).

Note:By far the best option is to use Slammin' Source Map Tools's updated VBSP, VVIS, VRAD.

Important:Slammin' Source Map Tools updated VBSP, VVIS and VRAD may not work or not designed for later games (such as Left 4 Dead engine branch or above, or certain Source 2013 games, such as Team Fortress 2 which has it's own branch, incompatible with Slammin's VBSP, but Slammin's VVIS and VRAD will continue to work on Team Fortress 2 branch). Also for Mapbase, it is recommended to use Mapbase's VBSP instead of Slammin Tools VBSP for Parallax Corrected Cubemaps.

Warning:Adam McKern's set of Source compiling tools (CSTBSP, CSTVIS, CSTRAD--known collectively as CST) have become obsolete as it lacks modern features like HDR.

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).