How to Optimize a Map in Hammer Editor

Seal off rooms. This is a must. If there are ANY leaks in the map, the compiler won't be able to determine the boundaries of the map, and will attempt to render everything within the map all at once. Worse yet, any area portals, hint brushes and occluders in the map will not work, making them useless. Also, water won't render correctly if there are any leaks in the map.

• In Fig. 1a, the room is obviously not sealed. If you compile this map with that leak, vvis (the portion of the compile that determines visibility data) won't be able to determine the boundaries of the map, since the visleaves  will just "leak" out into the black void outside our map.
• In Fig. 1b, the room is sealed and will be compiled correctly.
• To check for leaks, first make sure there is at least one entity in the map (such as an "info_player_start"), otherwise this will not work. Save and compile the BSP by pressing F9 or going to File -> Run Map. Select "Normal" for Run BSP, and select "No" for both Run VIS and Run RAD (also be sure to check the "Don't run the game after compiling" box). Once it's done compiling, close the compile log and go to Map -> Load Point File. If there are any leaks, it'll ask you to confirm the operation (ex. "Load default pointfile? [C:\Program Files\------>]) Select "Yes", and you'll see a red line protruding from the nearest entity* out through the area of the leak. (*This is why you need an entity, either brush or point, in your map. It doesn't work with world or detail brushes.) Seal the leak, recompile the BSP, and load the pointfile. If all is sealed, it should just go to an empty folder in the Steam\steamapps\GAMERTAG\GAME\mapsrc folder. Always check for leaks before the map is released to the public.

Create brushes with "tools/toolsnodraw". Make sure you always create brushes with the tools/toolsnodraw texture first and then texture only what the player can see from the player's point-of-view. If you are only going to see one side of a wall, then texture that visible side only.

Reduce the number of brushes and faces. Whenever possible, stick to creating geometry with a few large brushes rather than a thousand small ones. More brushes equals more faces, and more faces equals slower performance and compile time. Bottom line: if you can create complex geometry with one or two brushes, why use any more than that?

• In Fig. 3a, there are two brushes: the one on the left was created using the Arch Tool which created an 8-sided brush with 40 faces, and the one on the right was made from a single clipped brush with only 11 faces. The latter was achieved by utilizing the Clipping Tool (Shift + X). To achieve the latter, it is recommended to first create the desired geometric shape out of the Arch Tool first for reference. Then, create a brush with the same length, width, and height as the reference arch and place it slightly above the reference. Select the brush and clip the angles. (you may need to change the grid size ("-" to decrease, "+" to increase) and/or manually move the vertices (Shift + V) of the reference arch to snap to the nearest grid point.) Now you have a geometrically identical brush, but only with fewer faces!

Make good use of detail brushes. World brushes block visibility, seal the map, and split the BSP into "leaves", which are basically the compiler's way of determining what can and can't be seen at any given time and place. Detail brushes were designed to essentially be "invisible" to the compiler. The only brushes that should be world brushes are the walls, floor and ceiling of a room. Pretty much everything else in the room that isn't a working entity and doesn't significantly block the player's vision should be tied to a func_detail brush (tie using Ctrl + T). Since detail brushes don't block visibility, they won't be compiled in vvis calculations and won't split the map into more visleaves (which is good in most cases). Be warned though that it won't seal the map either. Just make sure that all the world brushes seal the map and there shouldn't be any problems.

Use area-portals and hint brushes appropriately. Area-portals and hint brushes are great ways to limit visibility and increase performance if done correctly. However, you should not place these in every corridor and window, as the amount to calculate what's supposed to be rendered and when could very well surpass that of just rendering the entire room all at once. Instead, you should only separate rooms with lots of details. This will spare your computer having to render many unnecessary objects, and help increase performance without putting a major strain on visibility calculations.

Use occluders (sparingly). Occluders are similar to a closed area portal, as it doesn't render what is behind it. However, it is different than a closed area-portal in that it doesn't need to seal a room (it can be free-standing and not touch world brushes) and it only blocks 3D models (aka props). This tool is very costly in terms of memory usage, so you should only use occluders when there is an expensive 3D model behind a free-standing wall that cannot be sealed by areaportals.

Add 3D Sky-boxes. Not totally necessary, but it'll help make the map look much larger without drastically slowing down FPS (frames per second). 3D skyboxes are usually made for "large" outdoor maps, but it is possible to make it for an indoor map if you can see an exterior through a window or something. 3D skyboxes are very cheap to render and can make a small map appear up to 16x larger since 3D skyboxes are set to a 1/16 scale in Hammer and then scaled up during compile.

Add fog. On large outdoor maps, fog can limit the amount of detail being rendered, and it can make your map look more realistic in the process. Simply add an env_fog_controller entity in your map. On the "Enable Fog" option in the Object Properties tab, select "Yes". Next, edit the Far Z Clip Plane to your liking, which will remove all brushes after that distance, eliminating the engine rendering unnecessary objects (The Far Z Clip Plane value should be greater than the Fog End value).

Don't go crazy on the Lightmap Scale. The lightmap scale essentially determines how sharp or blurry shadows are rendered on geometry. Larger numbers degrade the shadow quality, but can increase performance. Contrariwise, a lower lightmap scale increases the visuals of the shadows, but can severely lower performance. Either too large or too small of a lightmap scale could produce an unrealistic lighting effect that is either too dull or too sharp, respectively. The default lightmap scale for all brushes is 16, which is a balanced area between visuals and performance.