An Overview

By now, you should have a basic idea of how BSP-trees and PVS-tables are generated. The examples in the previous sections are very basic 2-D representations of what a map will look like. In real-world scenarios, a typical map would be much more complex, filled with a multitude of 3-D structures and details. The culmination of all these details means that the BSP-tree and PVS-table can become exponentially more complex. This can affect performance while compiling your map (or even cause your map to return a compile error!) as well as affect in-game performance as the engine has to do excessive reads of the PVS-table.

In this section, we will still be working with a simplified 2-D representation of a map, but we will add a small number of details to intentionally complicate things as they would in a real map. You will see how a small number of details will quickly complicate the BSP and VIS process.

To solve for this problem, we can flag certain brushes in a map as "detail". This basically tells the compiler to ignore these brushes when generating the BSP-tree and PVS-table during the BSP and VIS stages. Note that marking a brush as detail does not alter its physical or visual properties in any way, it is merely ignored from generating additional leaf-nodes and portals.

Complications

Taking our 2-D map from the previous sections, we added a few basic details to our map. These represent typical structures you would find in a map: door frames, light fixtures, bulkheads, columns, stairs, an offset piece of floor tile, etc. We are not adding a lot here, and keep in mind that we are only considering a 2-D example along the X and Y-axes, in a real 3-D map we will be generating additional leaf-nodes and portals along the Z-axis as well.

Already, this simplified example generates a high number of leaf-nodes and portals, and while I pride myself on my Photoshop skills, it is far too complicated to draw the BSP-tree or PVS-table by hand. The compiler and engine are designed to handle a lot of this data, but even so they have memory and performance limitations.

Taking a step back and looking at the bigger picture, let's remember why we do all this complicated BSP and PVS stuff in the first place: For GPU rendering performance reasons, it is a good idea to hide large sections of the map that are beyond the player's line of sight. If you can't see it, don't draw it. All these relatively small details don't do much in limiting line of sight, but they do contribute to complicating the process of determining what is or is not beyond the player's PVS. Since these extra brushes are causing so many problems, wouldn't it be great if we can tell the compiler to simply ignore them for the process of generating the BSP-tree and PVS-table? Well, we can do exactly that.

Structural and Detail Brush Flags

To control whether or not a brush creates additional leaf-nodes on the BSP-tree, we can flag these brushes and tell the compiler to ignore them for this process. We commonly call these two states structural and detail brushes. When creating a new brush in the editor, their natural default state is structural, meaning that they will by default be used to create additional leaf-nodes on the BSP-tree. By flagging the brush as detail, we are telling the BSP and VIS process to ignore these brushes for these functions.

Fundamentally, this terminology can be confusing to the uninitiated since there is no real difference between a structural and detail brush, they are both just brushes. The only difference is how we instruct the Q3Map2 compiler to use these brushes in generating the BSP-tree and PVS-table. Before illustrating how to use structural and detail brushes, we need to clear some common misconceptions:

• "Structural and detail brushes look different in-game."
  There is no difference in appearance between a structural and detail brush. In both cases, the compiler still processes each brush and breaks each textured face down to their component triangles and saves the mesh to the .bsp file. The game engine reads all the polygons stored in the .bsp file and renders them to the GPU. Only shaders can affect the visual properties of a brush (eg. surfaceparm nodraw).
• "Structural brushes are solid, detail brushes are non-solid."
  Whether a brush is structural or detail does not affect the brush's physical properties. By default, all brushes are solid to player and weapon collisions. The only way to alter a brush's physical properties is by applying a shader that contains specific directives that changes the surface's physical properties (eg. surfaceparm nonsolid).
• "Detail brushes should only be used on small objects of detail, like bits of trim, railings, and other small objects."
  While detail should certainly be used on such brushes, they should additionally be used on any brush which generates unnecessary leaf-nodes and portals, and does not have a positive effect in limiting visibility. Practitioners of the Caulk-Hull Methodology will actually convert all visible textured brushes to detail and overlap the geometry with a structural caulk hull specifically for a well optimized PVS.
• "I don't need to worry about structural and detail brushes if I'm not getting any compiler errors."
  Not making use of structural and detail brushes will result in excessive compile times and will affect in-game performance.

Using Structural and Detail Brushes

With GtkRadiant, you can convert selected brushes by using the keyboard shortcut CTRL+M to flag structural brushes as detail, and CTRL+SHIFT+S to flag detail brushes back as structural. These options are also available in the right-click menu. Since GtkRadiant 1.6.4, a structural/detail toggle button has been added to the toolbar that switches the creation of new brushes from structural to detail.

To see what brushes are flagged as detail or structural, you can filter brushes in the View menu as well as using the keyboard shortcuts, CTRL+D to hide detail brushes and CTRL+SHIFT+D to hide structural brushes.

Next Steps

In real world scenarios, you may often find yourself with some ambiguity as to whether or not a brush should be converted to detail. Converting a brush to detail may cause your map to leak, but on the other hand, not converting it to detail would result in a bunch of unnecessary portals. Traditionally, you could convert the brush to detail and then patch up any holes with a structural caulk brush. You might find yourself doing this with some frequency. This lead some veteran mappers to form a paradigm shift and develop a new method of map building called the Caulk-Hull Methodology. We will see how mappers can utilize this to fully optimize their maps and remove any guesswork when it comes to flagging brushes as detail in a later section.