Optimization/Level Design: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
(moved with permission from http://www.hl2world.com/wiki/index.php/Optimization)
(Maybe add a note about Propper++ here ? The reason is why yes is because it's very easy and quick to use.)
 
(91 intermediate revisions by 33 users not shown)
Line 1: Line 1:
'''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.
{{LanguageBar|title = Optimization (Level Design) }}
{{Abstract Mapping}}


__TOC__
It's easy to create a map that older (or even newer!) computers will struggle to draw at (or higher than) sixty frames per second. This article is the hub for all information on how to to prevent that by '''optimizing your map'''.


== Areas ==
; [[Leak]]s
:There's no excuse! Leaks will invalidate almost all of your efforts elsewhere.
; [[VIS optimization|Visibility]]
: Reducing the number of surfaces and objects that are drawn in the first place. The single most important area.
; [[Physics optimization|Physics]]
: Various tricks to avoid overloading the CPU with physics calculations.
; [[Material optimization|Materials]]
: Correct material choices will allow your map to scale down its demands on slower computers.
; [[Lighting optimization|Lighting]]
: Performance and file-size optimisation.
; [[Skybox Optimization|Skybox]]
: A properly optimized skybox will significantly reduce lag and map size


==INTRODUCTION==
== Brushes ==
; [[Areaportal]]
; [[Hint brush|Hint]] + [[Skip]]
; [[Occluder]]


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.
== Models ==
; [[Static Prop Combine]] {{csgobranch|since}}{{also|{{teamspen}}{{h++}}}}
: Maps using large amounts of static props can reduce GPU drawcall overhead by combining individual static props into batches.


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.  
== Commands ==
There are many more useful console commands than the ones listed here—find them in their relevant articles.


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|Most performance-related commands require {{Command|sv_cheats}}.}}


In addition to this article, you should also review the Map Editing section of the [http://www.valve-erc.com/srcsdk/ Source SDK Documentation] (from Valve ERC, the people who made the Source Engine that we're using). Topics adequately covered in [http://www.valve-erc.com/srcsdk/Levels/performance_and_visibility.html this document] are not restated here, so be sure to read that too. Other resources are linked at the bottom of the article.
; {{Command|cl_showfps}}
: A simple output of framerate. <code>1</code> is real-time, <code>2</code> is averaged over the past second, while also displaying the lowest and highest FPS, aswell the latency.
; [[showbudget|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 <code>+showbudget</code> and <code>-showbudget</code>, which means that you can bind the former to a key (e.g., {{Code|bind <key> +showbudget}}) and it will only appear when you hold that button down.
; {{Command|mat_leafvis}}
: A console variable that (when active) displays visleaves. The number of the leaf, area and cluster of the current leaf is reported in the console.
; {{Command|mat_wireframe}}
: A console variable that lets you see exactly what is being rendered - for reasons described in [[visibility optimization]], often more than you might think is sensible.
; {{Command|r_lockpvs}}
: Locks the [[PVS]] so you can walk around and inspect what is being drawn.


==SHOWBUDGET==
== External links ==
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!
* [http://www.nodraw.net/2009/12/optimization-in-source-a-practical-demonstration/ Optimization in Source: A Practical Demonstration] - Pictorial demonstrations of optimization by [http://www.nodraw.net NoDraw.net]
 
* [http://www.shamusyoung.com/twentysidedtale/?p=4759 The Truth About The BSP] - Step-by-step explanation on BSP and its application by Twenty-Sided
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.
* [https://www.mapcore.org/articles/development/displacement-vs-func_detail-a-comparative-fps-study-r73/ Displacement Vs. Func_detail - A comparative fps study] by Will2K on MapCore
 
[[Category:Level Design]]
==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==
 
[http://www.valve-erc.com/srcsdk/Levels/optimizing_and_checking.html Optimizing and Checking Your Map]
 
[http://www.valve-erc.com/srcsdk/Levels/performance_and_visibility.html Improving Performance and Controlling Visibility]
 
[http://www.chatbear.com/board.plm?a=boardlisting&b=4989&v=flatold Official Mapping Forums]
 
 
[[Category:MappingTutorials]]

Latest revision as of 13:17, 4 February 2025

English (en)Deutsch (de)Français (fr)Русский (ru)中文 (zh)Translate (Translate)
Abstract Mapping series Discuss your thoughts - Help us develop the articles or ideas you want

Ammunition | List of HL2 Animals and Creatures | Mapping with Antlions | Beams and Lasers | Cables and Ropes | Moving Clouds | Color Theory in Level Design | Combat | Combine | Compression (Source 1) | Doors | Dust, Fog, & Smoke | Elevators | Level Transitions | Environmental Lighting, Sun, Weather, & Outdoors | Explosions | Fire | Half-Life 2 Foliage | Glass & Windows | Headcrab | Health | Ladders | Lighting | Optimization (level design) | Physics | Retinal scanners | Sound and Music | Special effects | Terrain | Trains | Turrets | Water | Weapons | Zombie

It's easy to create a map that older (or even newer!) computers will struggle to draw at (or higher than) sixty frames per second. This article is the hub for all information on how to to prevent that by optimizing your map.

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 drawn in the first place. The single most important area.
Physics
Various tricks to avoid overloading the CPU with physics calculations.
Materials
Correct material choices will allow your map to scale down its demands on slower computers.
Lighting
Performance and file-size optimisation.
Skybox
A properly optimized skybox will significantly reduce lag and map size

Brushes

Areaportal
Hint + Skip
Occluder

Models

Static Prop Combine (in all games since CS:GO engine branch)(also in TeamSpen's Hammer AddonsHammer++)
Maps using large amounts of static props can reduce GPU drawcall overhead by combining individual static props into batches.

Commands

There are many more useful console commands than the ones listed here—find them in their relevant articles.

Note.pngNote:Most performance-related commands require sv_cheats.
cl_showfps
A simple output of framerate. 1 is real-time, 2 is averaged over the past second, while also displaying the lowest and highest FPS, aswell the latency.
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 (e.g., bind <key> +showbudget) and it will only appear when you hold that button down.
mat_leafvis
A console variable that (when active) displays visleaves. The number of the leaf, area and cluster of the current leaf is reported in the console.
mat_wireframe
A console variable that lets you see exactly what is being rendered - for reasons described in visibility optimization, often more than you might think is sensible.
r_lockpvs
Locks the PVS so you can walk around and inspect what is being drawn.

External links

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