Optimization/Level Design

Optimization: how to make faster maps. Areaportals, hint brushes, occluders, detail brushes, design, debugging, and so forth. This information applies to any Source mod, including HL2, HL2DM, and CS::S.

INTRODUCTION

Map optimization is complicated and often difficult. However, even simple optimization can yield tremendous increases in map speed and decreases in map compilation time. Ideally, optimization begins when the level is being planned, but this article applies both to that case and to existing maps.

The first part of learning optimization is knowing the basic tools. Those tools are showbudget and mat_wireframe, discussed in their own sections below. With them, you can find out what the graphics engine is doing, and begin to identify what it is doing wrong. Optimization consists of telling the engine that you know better than it does, and instructing it in how to do a more efficient job. It is appropriate to divide optimizations into geometry-based and non-geometry based categories. The former are easier, while the later require some detailed understanding of the way the Source engine works.

Of the geometry-based optimizations, detail brushes are the most important, followed by hint brushes. Area portals and occluders are advanced topics, although hint brushes are somewhat advanced too.

In addition to this article, you should also review the Map Editing section of the Source SDK Documentation (from Valve ERC, the people who made the Source Engine that we're using). Topics adequately covered in this document are not restated here, so be sure to read that too. Other resources are linked at the bottom of the article.

SHOWBUDGET

Before you start doing any optimizing on an existing map, you should know what to optimize -- it'll be a waste of time and effort to optimize, say, your world brushes if your dynamic lights are what are actually killing performance. So your first tool is showbudget. Get to know it well!

To effectively use showbudget, you should turn it on and run around your level. Look for areas that cause trouble (fps goes too high and/or some bars jump significantly to the right). These trouble spots should be the initial focus of any optimization. As to how high of an fps reading is too high, or how far a jump is significant... that's for you to decide. You might try comparing your readings to those of the sample maps.

MAT_WIREFRAME

The other major tool you can start using from the beginning is mat_wireframe. This is a console variable that shows everything that the graphics engine is trying to draw. You will very quickly find that it tries to draw a lot more than a human would think it should.

Notice that many brushes, especially large ones, are broken up several times. Some of this is unavoidable, but much of it can (and should!) be corrected. It is unavoidable that rectanglar faces are converted into two (or more) triangles--Source only draws triangles, so this is fine. But sometimes a face is broken into dozens of oddly-shaped triangles, and this is a problem, since more triangles means that the map is slower. One aspect of optimizing a map is to reduce the number of triangles your world is broken into.

Usually, the engine will draw many props that are not actually visible. Another major aspect of map optimization deals with that problem: how to encourage the engine to draw only as much as it should. Hint brushes and occluders can help here; both are discussed later.

Try using mat_wireframe to compare the maps of beginners to those of professionals. If using you own maps, running the VIS stage of compilation will help.

CHEAP AND EXPENSIVE

Every object/event/whatever in a map will make the map run slower. Some things don't cause enough of a slow-down to worry about (except in large numbers); these are refered to as "cheap". Things which will significantly hurt the speed of a map are called "expensive". This notation makes it easier to talk about some parts of optimization. For example, "Brush-based fog is expensive, but env_fog_controller fog is relatively cheap." tells you that using env_fog_controller fog is the faster way to go. Of course, maybe you need to use brush-based fog for other reasons, but at least you know which is faster.

Anything done during compile time is considered "free" because it has already done before the game begins. For example, static lighting (done by the RAD program during compiling) is free, while dynamic lights (which are simulated while the game is running) are not (in fact, they're quite expensive). "Cheap" and "expensive" have nothing to do with how long it takes to compile a map--only with how fast the map will run when played.

NON-GEOMETRY OPTIMIZATIONS

Geometry optimizations can be complicated, but there are several non-geometry aspects of optimization. Handling them can be an easy way to make your map faster. Keep these in mind when designing a new map, and consult individual sections where showbudget reports problems.

See Optimization (Non-Geometry) for specifics.

GEOMETRY-BASED OPTIMIZATIONS

Geometry-based optimizations are those that manipulate map geometry in order to change the way BSP behaves. These can be difficult, but extremely effective. Any professional-grade map will make use of some or all of these techniques.

See Optimization (Geometry) for specifics.

EXTERNAL LINKS

Optimizing and Checking Your Map

Improving Performance and Controlling Visibility

Official Mapping Forums