Optimization (level design)

From Valve Developer Community
Revision as of 15:39, 6 January 2008 by Bluestrike (talk | contribs) (External links: fixed a link from a site that moved.)

Jump to: navigation, search

Template:Abstract mapping 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.


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.

Note:Topics adequately covered in Controlling Geometry Visibility and Compile Times are not restated here, so be sure to read that too. Other resources are linked at the bottom of the article.


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 low and/or some bars jump significantly to the right). These trouble spots should be the initial focus of any optimization. As to how low of an fps reading is too low, 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.


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 rectangular 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 referred 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.

See also

External links