BSP Map Optimization

This page is actively undergoing a major edit.
As a courtesy, please do not edit this while this message is displayed.
If this page has not been edited for at least several hours to a few days, please remove this template. This message is intended to help reduce edit conflicts; please remove it between editing sessions to allow others to edit the page.

The person who added this notice will be listed in its edit history should you wish to contact them.

BSP-style game engines require a special set of knowledge, to know how to create levels that will run well in the engine. This article will attempt to explain some of the techniques and methods used to make a level run well in the Source engine. This will cover Visibility optimization, func_details, compile time optimization for VIS, and areaportals.

Requisite Knowledge - How to make a map that is free of leaks, and be able to compile it and run it in the game engine.

---

Theory

The whole goal of map optimization is to not render anything that isn't necessary. This is accomplished in a BSP engine like Source, through a number of techniques. I'll address the techniques in order of importance.

The first optimization technique is using the visibility tree to full advantage. The visibility tree is precalculated in Source during the VIS step of compile. The tree uses the visleafs that were generated during the BSP step of compile to precalculate the PVS of every leaf in the map. The goal in level optimization is to minimize the PVS of each leaf that the player is most likely to be in, to maximize game performance. This is accomplished in practice by using hint brushes to divide leafs, to mimimize the PVS for those leafs.

The next step is to analyze the map, and any brushes that don't significantly block the player's visibility, should be removed from visibility determination by making them detail brushes. Func_detail brushes, or detail brushes, don't divide the BSP tree.

If you properly optimize your map, your compile times should be significantly shorter than an unoptimized map.

Practice

General

In practice, the best method for handling optimization is to plan the map ahead of time. If you lay out the paths in the map, whether single player, or multiplayer, it should be come fairly apparent where you will run into problems with visibility.

Some things to keep in mind:

• BSP engines love indoor areas. They handle them well because corridors and hallways are easy to determine visibility for. Outdoor areas require a rather different design approach.

Detail Brushes

func_details don't divide the BSP tree, and can't block visibility. Use these for angled brushes, small brushes, and anything that doesn't significantly block the player's view.

• You can put as many brushes as you want in a func_detail. It won't make a difference if you have a group of brushes all as one func_detail, or each as individual func_details.
• If it doesn't contribute to blocking the view somehow, make it a func_detail.
• Anything that's angled, make it a func_detail. BSP hates angled faces. If you can't func_detail it, put a hint brush around it, so it doesn't carve up the tree any more than necessary. That's why you'll see hint brushes in my maps over all angled faces.

Areaportal

• Areaportals have to seal an area to function. If they don't, they'll produce leak errors on compile, and generate a pointfile you can use to find where they aren't sealed.
• Areaportals are more accurate at visibility determination in engine, but they are more costly. Use them wisely.

Hint brushes

Hints are used to divide visleafs.

• Don't use any more HINTs than you have to. The more leafs in the map, the slower it will compile. Although this may sound counter-intuitive to the last statement, proper use of hints can speed up your compile times, as visleafs will have smaller PVS.
• Generally visleafs will stretch to the ceiling of the map, which will let them "see" over your buildings, drawing what's on the other side, whether the player can see it or not. Counteract this by using hint brushes parallel to the ground plane, at the roofline of the building.

Exercises

Compile your map with the following options: BSP with the -glview option, and VIS with the -fast option. Turn off Hammer's Auto visgroup for this compile. This should hide all the ents and func_details that don't carve up the BSP tree, since we are only interested in the BSP tree, and that is the only thing that affects visibility.

Load it into glview, and look at how the compile tools carve up the level.

Run the engine and have a look at the leafs in the engine. You are specifically looking for the shapes of the leafs, and how everything triangulates.

Turn these on:

mat_viewleaf 1
mat_wireframe 1

• Note: You can also set mat_wirframe to 2 and 3 for different triangle display modes.

Tricks

This is useful for viewing how your map is turned into triangles by the compile tools. Remember, less triangles means faster rendering.

This will let you cycle through wireframe modes by pressing F1.
bind f1 "incrementvar mat_wireframe 0 3 1"

Related Links

• Optimization - This article covers definitions and explains some of the concepts of optimization.
• Wikipedia:Binary_space_partitioning - An explanation of BSP.
• Visibility determination - This explains what the 2nd compile step actually does.
• Controlling Geometry Visibility and Compile Times -
• Visleafs - Visibility Determination Leafs
• PVS - Potentially Viewable Set