Introduction This tutorial focuses upon the compiling process of your map. It will explain what happens during it, what the results are and finally ways to improve the compiling process. This tutorial assumes you have good knowledge of the editor and the Source game engine. It will also be very heavy on text, there is no simple way I can draw a picture that will illustrate these concepts well enough. Three Acts There are three parts to the compiling process, each one has its own purpose and contributes to the overall map. It is vitally important to run each one when compiling the map for the final time, but we will go into that in further detail later. The compile is essentially the VMF (Valve Map File) being processed using various algorithms to produce a fully functioning BSP. The three algorithms used are called VBSP, VVIS and VRAD. VBSP - Creates The World This is the main section that needs to be compiled, the result is what the other two based themselves off of. This essentially takes the VMF file and converts it into a BSP. Now, some may be wondering, why not work with the BSP, well, some editors do this, however, by doing so, the editor becomes inherantly unstable. This approach was chosen to maximise the stability of the program, however this still doesn;t make it 100% crash-proof. The VBSP has several options when compiling, no, full and entities only. Full is what you will use 9 times out of 10. This takes the entire map and makes a new .BSP file, replacing any prior ones made in an earlier compile. It must be run if its the first time you compile a map. Entities only will, surprisingly compile only entities in the map but will need a previously compiled map, it simply replaces all the entities in the BSP file. This is useful if you only changed a couple of entitied in a large map. However, as the VBSP runs very quickly, usually under a minute, it is best to always keep this option on "full." After it has compiled the BSP from the VMF, it will save the BSP, ready for the next part to do its magic. VVIS - Virtual Visual This is a rather complex part of the compiling process, it is quite complex in how it works, however is essential to any large maps. This algorithim edits the already existing BSP file and needs one to work, as it works by looking at the BSP, loading up the map and then "slicing" it up into visleafs. Visleafs is simply the fancy name for areas of the map the VVIS has decided to split your map up into. It then takes each of these visleafs and works out what can be seen by each one, can it see that prop, can you see that wall. It prevents objects that cannot be seen to be rendered ingame, there is no need to. This is the part of the compile that will make the map run well, if the map is very small, such as a fy map, this is not necessary as there isn't much in the whole map. This is a very complex program though and is very time consuming to run, however, this is where "optimisation" comes in. Optimisation is the various ways to make a map run fatser, however this isn;t the focus of this tutorial. A good site that focuses upon optimisation can be found here, even though it focuses more on HL2, most of the ideas can be copied accross: Optimisation Guide In the options, there will be the following options, No, Full and Fast. Full will do everything described above, whilst "fast" will simply work out the visleafs, useful if you want to see how many there will be during the full compile of the VVIS. It can also aid in optimisation. VRAD - Let There Be Light In a 3D game, the rendering is in several sections, building the geometry, applying textures and then lighting passes. Granted this is a very watered down description of what really happens, it is accurate enough for us. If your graphic card/processor had to calculate all of the lights on the fly, no one would get more than 1FPS. However as most, if not all, lights used in your map will be static, why not calculate it once and use the data made from this. That is the purpose of the VRAD, it calculates all of the lighting in the map and its effects upon the world geometry and props. This can be very time-consuming (around half an hour for a moderate sized map with HDR) however, once it is done once, it is done forever. That is unless you need to change some variables with the lights, in which case the whole lot need to be done again. Like the VVIS, the VRAD needs a BSP file to work on. The options available will be No, Full, Half and a tick box for HDR. No will not run the the VRAD at all, so the map wil have mat_fullbright set to 1, which makes every surface look like it does in the editor, un-natural. Full will do the whole lighting pass as described above, whilst Half will still caculate the lights, but use a faster algorithem. Useful for testing ideas and testing the lighting, before commiting to a full, time-consuming, pass. The HDR option is obviosly used for if you want your map to have HDR effects on it. If you select this option, the VRAD will run twice, once for LDR (Low Dynamic Range)) lighting and once for HDR (High Dynamic Range). Additional Parameters There are multiple additional commands that can be entered into this box, however, I feel there is only one that needs to be mentioned here. The "-final" command. This is used when compiling the map for the final time, just before you release it. This should be done in conjunction with everything set to "full" under each option. The does several small enhancements to the map, however the most noticable is fixing up the VRAD's lighting as it will use different algorithims. Post-Compiling You think your job of compiling the map is done after you have executed the VBSP, VVIS and VRAD on full with the -final command? Nope, in order to have what I deem a fully compiled map, the cubemaps need to be compiled as well as a radar background to be made (tut for this soon). Please, please, please use cubemaps, it makes any reflective surface look right and will make the map look right with HDR and water. I have heard complaints of water not looking right, or the weapons not looking right in HDR lighting. The cubemaps need to be included into the VMF, so if you never put any in, go back and place them everywhere, most importantly around 64 units above every surface the player will walk on. Place them at regular intervals, then after compiling the map again, type "buildcubemaps" into console. if you have HDR lighting, you will need to turn it off by typing in "mat_HDR_enabled 0" into console and building the cubemaps again. If you are slightly epileptic look away when this is working out, as it flashes an image of each cubemap in 6 directions. All of the images will be saved into the BSP map file at the end. The last job to do is to produce a bot_nav file, simple add bots to the server and let it work out. Sometimes the bots will not work, so its best to compile the BSP only, add bots and work out why they dont work, such as stairs have been known to throw them off. Again there are a multitude of links, articles and tutorials all around to help you with this. Conclusion Well, now we know what the compiling does and why it needs to happen, we also touched upon how to make the process easier for the computer. I hope this has been informative, some people don't even know why a map needs to be compiled, but hopefully if this is you, you'll know better now eh? Happy compiling, Rokusho