Map Compiling Theory
Posted with permission. Source
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 (or any other engine based on Quake procedures) starts with a 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 are 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 convienent way to prepare the polygon, lighting, and entity data for latter processing. Once you have an built a level in your editor and saved it to disk for safe keeping 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 from 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:
- Exporting your map into .map format
- Executing the CSG program against the .map file
- Executing the BSP program against the CSG modified .map to create a .bsp (final map format)
- Executing the VIS program against the new .bsp file
- Executing the RAD program against the .bsp file to add lighting
- Moving your now finished .bsp to your Mods /map directory
- Removing the numerous extra files created by the four previous applications
- Executing HL.exe with parameters to start your map
You may be thinking "Damn, thats a lot of stuff to do. Whats it all for?". Well thats 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> .rmf > Hammer > .map > 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 being as the tasks the tools perform involve some complex math and algorythms 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 |
BSP | The BSP tool is the one that actually converts the .map file data into a useable .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. |
VIS | This tool creates the visibility matrix for the map based on the levels geometry. This martix 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. |
RAD | 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. |
Compile Managers
(insert content)
Which Compile Tools?
Hammer ships with Valve's own compile tools. These are denoted by the presense of a 'v' preceding the tool name in the tools file name ( i.e. vbsp.exe, vvis.exe, etc. ). These tools are fine for your average map, especially for those new to Source mapping. However Sean "Zoner" Cavanaugh, who is now employed by Gearbox software, has created a new set of Source compiling tools that have many refinements and more options than the default tools, known collectively as CST.
Conclusion
So there you have it. Hopefully you now have a good understanding of what it takes to get a level out of your editor and into Source.