Map Compiling Theory: Difference between revisions
TomEdwards (talk | contribs) No edit summary |
Minefnafer22 (talk | contribs) m (→The compile tools: Removed the few instances of "you". Slightly rewrote the VVIS section to be a little less lengthy and janky sounding. This whole page could do with a rewrite honestly) |
||
(63 intermediate revisions by 44 users not shown) | |||
Line 1: | Line 1: | ||
{{lang|Map Compiling Theory}} | |||
{{pov}} | |||
'''Original posted with permission ([http://www.game-edit.org/tutorials/general/compile_theory/compile_theory.shtml 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 [[brush]]es), [[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). | The following chart shows the overall process required to create a playable map file (.bsp). | ||
''<placeholder>'' | ''<placeholder>'' | ||
. | .vmf > VBSP > intermediate .bsp > VVIS > VRAD > final .bsp | ||
''</placeholder>'' | ''</placeholder>'' | ||
[[File:Source_Mapping_Pipeline.png]] | |||
The table that follows should give | == The compile tools == | ||
The table that follows should give 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 a mapper has little need to know. | |||
<table> | <table> | ||
<tr> | |||
<td>'''Tool'''</td> | <td>'''Tool'''</td> | ||
<td>'''Purpose'''</td> | <td>'''Purpose'''</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td class="type2"> | <td class="type2">'''[[VBSP]]'''</td> | ||
<td class="type2">The BSP tool | <td class="type2">The BSP tool 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.</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td class="type1"> | <td class="type1">'''[[VVIS]]'''</td> | ||
<td class="type1">This tool creates the visibility matrix for the map based on the | <td class="type1">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. This is used for optimization and performance. Therefore it is crucial that this tool be run on any final version of a .bsp. If it is not run then the entire level, along with [[models]] and [[props]] will be visible all the time which reduces the game framerate and potentially make the map unplayable. In-depth information about VIS can be found at [[visibility determination]].</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td class="type2"> | <td class="type2">'''[[VRAD]]'''</td> | ||
<td class="type2">The RAD tool, or Radiosity tool, is responsible for generating and applying all lighting effects in a level. Everything from entity lights and the | <td class="type2">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)]].</td> | ||
"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.</td> | |||
</tr> | </tr> | ||
</table> | </table> | ||
==Compile | == Compile managers == | ||
* [[Batch Compiler]] - Supports Quake, Valve, Zoners, and CSTTools | |||
* [[Batch Compile Tool|VBCT]] - For the Source engine. | |||
* {{compilepal|4}} - GUI compiler alternative for the Source engine | |||
==Which | == Which compile tools? == | ||
Hammer ships with Valve's own compile tools. These are denoted by the | 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|vbsp.exe]], [[Vvis|vvis.exe]], [[Vrad|vrad.exe]]). | ||
{{note|By far the best option is to use {{slamminsrc|4.1}}'s updated VBSP, VVIS, VRAD. | |||
{{Important|{{slamminsrc|1}} updated VBSP, VVIS and VRAD may not work or not designed for later games (such as {{l4dbranch|1}} or above, or certain {{src13|1}} games, such as {{tf2|1}} which has it's own branch, incompatible with Slammin's VBSP, but Slammin's VVIS and VRAD will continue to work on {{tf2branch|1}}). Also for {{mapbase|1}}, 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 [http://www.ammahls.com/zhlt 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). | |||
[[Category:Level Design]] | [[Category:Level Design]] | ||
[[Category:Theory]] |
Latest revision as of 23:34, 4 August 2025

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 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 a mapper has little need to know.
Tool | Purpose |
VBSP | The BSP tool 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. This is used for optimization and performance. Therefore it is crucial that this tool be run on any final version of a .bsp. If it is not run then the entire level, along with models and props will be visible all the time which reduces the game framerate and potentially make 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).