BSP Map Optimization: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (Changed redirect target from Visibility optimization to VIS optimization)
Tag: Redirect target changed
 
(27 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{wip}}
#redirect [[VIS optimization]]
[[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 [[leak|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.
 
===[[func_detail|Detail Brushes]]===
[[Image:Func_detail_face_splits.jpg]]
 
[[func_detail]]s 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_detail]]s.
*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.
 
===[[func_areaportal|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.
 
===[[HINTs|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.
 
==Examples==
 
 
==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:
<code>mat_viewleaf 1</code>
<code>mat_wireframe 1</code>
* Note: You can also set <code>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.
<code>bind f1 "incrementvar mat_wireframe 0 3 1"</code>
 
==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

Latest revision as of 12:09, 30 August 2023

Redirect to:

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=BSP_Map_Optimization&oldid=344006"