BSP Map Optimization: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
m (Changed redirect target from Visibility optimization to VIS optimization)
Tag: Redirect target changed
 
(29 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 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 so that we can further optimize the PVS. 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 the 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==
===[[func_detail|Detail Brushes]]===
Func_details 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.
*If it doesn't contribute to blocking the view somehow, make it an 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.
* BSP engines love indoor areas.
* 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.
 
===[[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]]. This is used to
*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.
 
==Examples==
Func_detail and groups. One func_detail can have multiple brushes.
 
 
==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==
*[[Wikipedia:Binary_space_partitioning]]
*[[Visibility determination]]
*[[Controlling Geometry Visibility and Compile Times]]
*[[Visleafs]]

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"