Optimization/Level Design: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
{{abstract mapping}}
{{abstract mapping}}
'''Optimization''': how to make maps run faster. Areaportals, hint brushes, occluders, detail brushes, design, debugging, and so forth. This information applies to any [[Source]] mod, including [[HL2]], [[HL2DM]], and [[CS:S]].


__TOC__
'''Optimization''' is the act of reducing the computer's workload. In level design terms this is almost always related to reducing the amount of rendering that the video card must perform at any one time.
==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.
== Areas ==


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 going 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 latter require some detailed understanding of the way the Source engine works.  
;[[Optimization (level design)/Leaks|Leaks]]
:There's no excuse! Leaks will invalidate almost all of your efforts elsewhere.
;[[Optimization (level design)/Visibility|Visibility]]
:Reducing the number of surfaces and objects that are be drawn in the first place. This is the largest section.
;[[Optimization (level design)/Physics|Physics]]
:There are various tricks to avoid overloading the CPU with physics calculations.
;[[Optimization (level design)/Materials|Material choices]]
:Correct material choices will allow your map to scale down its demands on slower computers.
;[[Optimization (level design)/Lighting|Lighting and reflections]]
:Real-time and file-size optimisations.


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.
== Commands ==


{{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.}}
;<code>[[showbudget]]</code>
 
:A panel which displays how your computer is spending its [[budget]] for each frame. It's the premier tool for working out exactly what's sucking up performance in your map.
==showbudget==
:It's invoked with <code>+showbudget</code> and <code>-showbudget</code>, which means that you can bind the former to a key (i.e. <code>bind <key> +showbudget</code>) and it will only appear when you hold that button down.
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!
;<code>[[Optimization_Commands#mat_wireframe|mat_wireframe]]</code>
 
:A console variable that lets you see through walls. This way, you can see exactly what is being drawn - for reasons described in the [[Optimization (level design)/Visibility|visibility optimisation article]], often more than you might think is sensible.
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.
:There are three wireframe modes, <code>1</code> through to <code>3</code>, which display the information you need with progressively fewer lines.
 
==mat_wireframe==
The other major tool you can start using from the beginning is [[Optimization_Commands#mat_wireframe|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==
==See also==


* [[Budget]]
* [[Controlling Geometry Visibility and Compile Times]]
* [[Controlling Geometry Visibility and Compile Times]]
* [[Intermediate Lighting#Lightmap_optimisation|Lightmap optimisation]]
* [[Optimizing and Checking Your Map]]
* [[Optimizing and Checking Your Map]]
* [[Optimization Commands]]
* [[Optimization Commands]]

Revision as of 06:03, 16 September 2008

Template:Abstract mapping

Optimization is the act of reducing the computer's workload. In level design terms this is almost always related to reducing the amount of rendering that the video card must perform at any one time.

Areas

Leaks
There's no excuse! Leaks will invalidate almost all of your efforts elsewhere.
Visibility
Reducing the number of surfaces and objects that are be drawn in the first place. This is the largest section.
Physics
There are various tricks to avoid overloading the CPU with physics calculations.
Material choices
Correct material choices will allow your map to scale down its demands on slower computers.
Lighting and reflections
Real-time and file-size optimisations.

Commands

showbudget
A panel which displays how your computer is spending its budget for each frame. It's the premier tool for working out exactly what's sucking up performance in your map.
It's invoked with +showbudget and -showbudget, which means that you can bind the former to a key (i.e. bind <key> +showbudget) and it will only appear when you hold that button down.
mat_wireframe
A console variable that lets you see through walls. This way, you can see exactly what is being drawn - for reasons described in the visibility optimisation article, often more than you might think is sensible.
There are three wireframe modes, 1 through to 3, which display the information you need with progressively fewer lines.

See also

External links

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Optimization/Level_Design&oldid=83475"