I decided to write this tutorial for the Empires mapping forum because this seems to be something the newer Empires mappers don't pay a lot of attention to. I hope it proves useful to someone. What the compiler actually does The compile button in Hammer is probably something you've gotten used to using to test your maps, and sure, maybe you understand what happens when you set Rad to "fast" or set BSP to "entities only". But do you really understand what you're doing when you compile a map? When you start that compile, Hammer starts an automated process which runs your VMF through three different programs. These programs are VBSP.exe, VVIS.exe, and VRAD.exe. The first program that your VMF is run through is VBSP.exe, short for Valve BSP. This takes your plain Valve Map File and generates a basic BSP file (Binary space partitioning) from it. The brushes and displacements are properly converted into geometry the game can understand, entities and such are converted so the game will understand them. This process never takes more than a couple of seconds. When it is done, the bare-bones BSP is output to the folder that the VMF was loaded from. When you do an "Entity only" compile, the process is slightly different. With "Entity only", VBSP.exe doesn't generate a new BSP file from the VMF, it just loads the existing one in the directory where the VMF is, and edits the entity information in it. Changing geometry, brushes, textures, or lighting in a map and then only doing an Entity compile will either be ineffective or cause problems. The next build program starts and loads the BSP that VBSP.exe just output. This program is VVIS.exe, short for Valve Visibility. The first few things this program does is prepare the fancier shaders such as water or cameras so in order for water to work properly you need to at least run fast VVIS. The much larger part of VVIS involves using the automatic Visleaf generator to make up the Visleafs of the map. If you don't know what a visleaf is, they are described in detail here, and you should make every effort to learn about them. This part of VVIS is very important if you're doing a compile that you plan on releasing. This part of VVIS will increase the FPS that players get in your map by a HUGE amount. If you do a "fast" VVIS compile, you forsake all FPS gains that the Visleaf generator would give you and the players end up rendering ALL of the map, ALL the time. VVIS is a very important and often skipped part of the compile, mostly because the Visleaf generator will take a frustratingly long time if your map is not at least semi-optimized. Why you should optimize and a rough guide of what to do is something I will cover in the section after this. After VVIS completes it's work, which usually takes 2 to 30 minutes depending on map and cpu speed, it outputs the still partially complete BSP to the directory that it was loaded from. The last program in the process is VRAD.exe, short for Valve Radiosity Simulator. This program determines ALL the lighting in your map. If you don't run your BSP through VRAD at all, your map will have no lighting data at all and the engine will be forced to run it with mat_fullbright, which looks horribly, horribly ugly. This program takes the values you set all your lights to and runs them through it's Radiosity Simulator, which calculates the shading on all the different areas of the map, the way the light bounces off of surfaces to light nearby areas, and the way the shaded areas of the map look. This is probably the most important part in making your map look good. When you do a "full" VRAD compile with HDR, the compiler will put the BSP through VRAD twice, once for LDR (LDR is what you have if you don't have HDR) and once for HDR. A "fast" VRAD compile will usually only take a minute or two, but produces very rough lighting. A "full" VRAD compile will take usually 10 to 30 minutes. A "final" VRAD compile will usually take 30 minutes to an hour. Again, if you're doing a compile that you plan on releasing, you should at least do a full VRAD compile, if not a final HDR compile, but I go over that later in the tutorial. After VRAD.exe has finished, the compiler then takes your completed BSP and copies it to the /maps/ directory you specified. The compiler will then attempt to launch the game and run your map, if you selected the option. It's also nice to realize that the compiler leaves a copy of the compile log as a text file in whatever directory you loaded the VMF from, along with a copy of the finished BSP. Additionally, you may remember from when you first configured Hammer, under the Tools>Options>Build Programs menu, Hammer has 5 fields where it asks you the location of the executable files for the game, bsp, vis, rad, and the folder that the completed maps should be output to. It asks you this because different iterations of the source engine use slightly different build programs. Since Empires is on Source 2007, the build programs will all be found in "$SteamUserDir\sourcesdk\bin\source2007\bin". Why you should optimize your map Many novice mappers sit through 2 or 3 day long compiles where VVIS does incredible amounts of completely unnecessary calculations, and then whine about how much Source sucks. The reason behind these absurdly long compile times is the automatic Visleaf generator, and shitty mapper's refusal to understand it. Basically, this generator takes every world brush (any brush not tied to an entity) and calculates what areas of the map it would obscure at every viewing angle in the map. This can be an ENORMOUS task if the mapper hasn't spent the 30 seconds required to address this. To address this facet of VVIS, you take every brush that isnt big enough to properly obscure any part of the map from the player, and make it into a func_detail. Func_details, along with every other brush entity, will be ignored by the generator. The generator will also totally ignore the area inside of a func_viscluster, so you should use these in large, open parts of the map, such as the center of emp_isle. There are far better articles about how to optimize in hammer, and optimization is something every mapper should become familiar with. This is just a bit of info to make sure you're on the right track. Using "Expert" compile mode The "Expert" compile mode in hammer may seem a little bit intimidating at first but it's such a useful tool that it is definitely worth learning about. To access the "Expert" mode, you press the compile button in hammer and then click "Expert..." at the bottom left. It presents you with a slightly different compile option dialogue. In the top left there is a drop down menu of different compile configurations. These are basically what the "Normal" compile mode uses, only you have more control over what the compiler actually does. You can change what they do by adding Parameters in the "Parameters:" field. A useful parameter to add is "-low" if you want the compiler to only use idle cycles instead of all of your cpu, or use "-both" on $light_exe to compile the map for both LDR and HDR. There are many useful parameters you can add, some of which I will cover later, and you can find documentation for all of them on the Valve Developer Wiki. Final Compile settings Once you've tested your map a few times, ironed out all the bugs, and are ready to compile for a playable release, you don't want to just stick with a "Full" compile. With a "full" compile, models still don't get properly lit, props only cast shadows according to their collision models, and the lighting still isn't perfect. To do a proper release-ready compile, you want to go in the expert compile mode, select the "HDR Full Compile -Final (slow!)", and then add two extra parameters to $light_exe. Those two parameters are "-staticproppolys" and "-staticproplighting". This is important for a final release because "-staticproplighting" enables vertex lighting on static props, "-staticproppolys" tells VRAD to calculate shadows from props via their polys instead of collision models, "-final" allows VRAD to use more rays in its radiosity simulator which gives nicer lighting. It is important to do an HDR compile, too, even if you haven't added anything special for HDR. HDR makes the lighting look prettier in places where there is lots of contrast and shadows. Building your Cubemaps If you don't know what cubemaps are at all and haven't placed any in your map, this won't help you, but it's good to know anyway. Once you've done a final compile, you still have to load the game in the engine to build the Cubemaps. You have to open your console while your map is loaded and type in "buildcubemaps", and the client will start flashing a slideshow of small screenshots taken at each env_cubemap entity. If you compiled for both LDR and HDR, you will have to build Cubemaps twice, once when you have HDR disabled, and once when you have HDR enabled. The cubemap data gets automatically compressed into your BSP and the next time you reload the map, specularity and reflections will look correct. It is important to note that if you rename your BSP after you've built the cubemaps, it will cause problems.