I know that there are leafs (volumes) created by vis, the open space within the map. From what I understand, if a leaf touches a brush, and that leaf is visible or potentially visible, than the brush will also be rendered.
Let's say you have a really long brush that touches several leafs, will that entire brush be rendered even if only one of the leafs is visible?
Creating brushes for Vis (leafs & brushes)
When the map is compiled it converts the brush faces into groups of triangles called drawsurfs. The drawsurfs are split off from the brushes and regrouped into chunks by the compiler that do not directly correspond to the brush faces they are taken from. However, in the case you describe the chunks would probably correspond to the long faces of the brush, so the whole face would get drawn if any of the leaves it touched was in the PVS. Not the whole brush though - might seem like splitting hairs but its an important distinction.
If you've got a big long wall it might look a bit dull and you'll be best off splitting it up with some support pillars or alcoves with pipes in or something anyway. Do the same with the floor as well, or you might end up with a MAX_POINTS_ON_WINDING, which is when the compiler tries making more splits than it is able to on a single brush face.
If you've got a big long wall it might look a bit dull and you'll be best off splitting it up with some support pillars or alcoves with pipes in or something anyway. Do the same with the floor as well, or you might end up with a MAX_POINTS_ON_WINDING, which is when the compiler tries making more splits than it is able to on a single brush face.
That is pretty much the end result - the drawsurfs get assigned to whatever leaf they are inside.
Once you get to that point, it no longer matters whether the drawsurfs were made from faces of a structural or detail brush. Once a drawsurf is created from a brush face, it's just a bunch of triangles and doesn't really have a structural/detail property any more.
Once you get to that point, it no longer matters whether the drawsurfs were made from faces of a structural or detail brush. Once a drawsurf is created from a brush face, it's just a bunch of triangles and doesn't really have a structural/detail property any more.
How does the engine deal with caulk/nodraw faces? Are these faces omitted from the bsp file?
For instance, building a staircase. I build a triangle that is under the staircase (same slope as the stairs), build each rectangular step so that half the rectangle can be subtracted, eliminating one of the unseen faces for each step. I know this elminates one uneccesary line of code for the brush in the map file, and if repeated this could reduce filesize. Are there any general rules to making brushes that will reduce overall size of bsp?
For instance, building a staircase. I build a triangle that is under the staircase (same slope as the stairs), build each rectangular step so that half the rectangle can be subtracted, eliminating one of the unseen faces for each step. I know this elminates one uneccesary line of code for the brush in the map file, and if repeated this could reduce filesize. Are there any general rules to making brushes that will reduce overall size of bsp?
Caulk brushes are still in the BSP (they are after all solid, even though they are invisible, it still has collision). Not entirely sure about nodraw, I think they are removed.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
Alright, so if all brushes and faces are present in the bsp, then removing unneccesary faces or combining multiple brushes would be ideal for lower the overall size of map/bsp file. It seems that there is a trade off between filesize and map performence. My question is, should I combine brushes to eliminate unseen faces (thus reducing filesize) OR break up the brushes so that it will only be present in each vis leaf. I know this can go either way depending on the situation. Any ideas?
The number of brushes is pretty trivial with regards to BSP file sizes anyway. It's like taking out a cup of water out of the ocean.
By far, lightmaps take up the largest chunk of BSP size followed by everything else. You are going to get much better gains in overall performance/filesizes by ignoring brush counts and focusing on optimizing useless stuff. So, delete stupid orphaned brushes that don't serve either visual or structural purpose, texture unseen sides with caulk so you don't generate lightmap data for them, etc, etc.
You generally don't have to worry much about load times, but you do have to worry about in game performance. What takes up most of the room of your distributed map? Textures, sounds and other assets.
A single brush is what? 8 sets of coordinates? Remove 2 faces of that and you save a few bits of information, nothing more. Not worth the effort.
By far, lightmaps take up the largest chunk of BSP size followed by everything else. You are going to get much better gains in overall performance/filesizes by ignoring brush counts and focusing on optimizing useless stuff. So, delete stupid orphaned brushes that don't serve either visual or structural purpose, texture unseen sides with caulk so you don't generate lightmap data for them, etc, etc.
You generally don't have to worry much about load times, but you do have to worry about in game performance. What takes up most of the room of your distributed map? Textures, sounds and other assets.
A single brush is what? 8 sets of coordinates? Remove 2 faces of that and you save a few bits of information, nothing more. Not worth the effort.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
Mostly: What obsidian said.
To add a little more; the reason brushes are in the BSP is because the brush volumes are used for collision. For the purposes of collision, less brushes is better because it uses less processor time thinking about it. In overall terms of what the BSP/engine does each frame collision is incredibly trivial. Collision is only likely to cripple a map's performance in extreme cases, e.g. where you have a few hundred brushes within a single vis leaf (could happen easily with ill-advised autoclipping of models), or where excessively complex patchwork is involved (collision with patches is more expensive than simple boxes)
(Er, yeah, just noticed a contradiction there - I said earlier that brushes aren't assigned to vis leaves. That's true for the visible, rendered geometry we were discussing then. However, the brushes DO get attached to leaves as non-rendering collision volumes)
On the scale we're talking at here though, I don't think it matters as much. I'd just go with whatever makes it easiest to work with. People tend to beat themselves up over optimisation when in 90% of cases it would be fine without worrying so much. Basically, unless you know there's a problem, don't fret.
To add a little more; the reason brushes are in the BSP is because the brush volumes are used for collision. For the purposes of collision, less brushes is better because it uses less processor time thinking about it. In overall terms of what the BSP/engine does each frame collision is incredibly trivial. Collision is only likely to cripple a map's performance in extreme cases, e.g. where you have a few hundred brushes within a single vis leaf (could happen easily with ill-advised autoclipping of models), or where excessively complex patchwork is involved (collision with patches is more expensive than simple boxes)
(Er, yeah, just noticed a contradiction there - I said earlier that brushes aren't assigned to vis leaves. That's true for the visible, rendered geometry we were discussing then. However, the brushes DO get attached to leaves as non-rendering collision volumes)
On the scale we're talking at here though, I don't think it matters as much. I'd just go with whatever makes it easiest to work with. People tend to beat themselves up over optimisation when in 90% of cases it would be fine without worrying so much. Basically, unless you know there's a problem, don't fret.
It's fine to talk about this sort of stuff on a purely theoretical basis to understand the philosophy, but in real world applications, other practical things come into play that changes the whole formula immensely.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
Thanks for all the help 
I understand what you guys are saying, brushes are not as important as lightmap, visiblity, tris, texture rendering passes, etc.. I'm building a map from scratch so I want to make sure I get all the basics about structural/detail brushes for vis clarified before proceeding. Also, I would like to understand more about how vis actually creates the leafs. Could someone refer me to helpful documentation about how the algorithm works? Would creating a prt file from scatch (manually writing the leafs into the file, or writing a program to create the leafs) be a reasonable task if you know exactly where the leafs should be?
I understand what you guys are saying, brushes are not as important as lightmap, visiblity, tris, texture rendering passes, etc.. I'm building a map from scratch so I want to make sure I get all the basics about structural/detail brushes for vis clarified before proceeding. Also, I would like to understand more about how vis actually creates the leafs. Could someone refer me to helpful documentation about how the algorithm works? Would creating a prt file from scatch (manually writing the leafs into the file, or writing a program to create the leafs) be a reasonable task if you know exactly where the leafs should be?Why would you need to do that? That's what caulk hull and hints are for.
For an advanced practical guide, see here:
http://www.quake3world.com/forum/viewtopic.php?t=3620
See Q's sample map thread for details on caulk hull linked at the top of that article.
And for more technical explanations of the algorithm to satisfy your curiosity of the theoretics. In particular SPoG and Digibob's articles.
For an advanced practical guide, see here:
http://www.quake3world.com/forum/viewtopic.php?t=3620
See Q's sample map thread for details on caulk hull linked at the top of that article.
And for more technical explanations of the algorithm to satisfy your curiosity of the theoretics. In particular SPoG and Digibob's articles.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]