I have a few questions that I hope you can help me with, about the detail brushes you mentioned in this video.
As I understand it, these should basically be all brushes that do not have the task of closing off your map from the void.
1. In the case of a space floater, would this mean all brushes except for the skybox (or spacebox if you will) should be detail brushes?
2. Can you explain a little more as to why this is, and what the difference is between structural and detail brushes?
3. How about patches? In the example of a space floater, can I simply select the skybox and hit I to select everything else (including entities, patches) and hit CTRL+M to convert to detail?
Will this simply not affect entities, or should I filter them out of the view or deselect them before I do this?
Does and should it affect patches?
4. What about clip brushes, player clip, bot clip, etc. Should they be made detail brushes or left untouched by this?
Last edited by Aliencat; 03-20-2013 at 12:24 PM.
Hey, detail brushes are a bit of a complicated topic for starters but I will try to explain it a little. Q3map2, the compiler which converts QL .map files to .bsp files, divides the compile process in 3 parts: BSP, VIS and LIGHT. During the BSP stage q3map2 creates the basic bsp structure or in other words the basic geometry. In the second stage, VIS, the compiler looks at the brushes and depending on which brushes are structual/detail the compiler adds portals to the .bsp file. Portals are 2D planes which you can't see ingame; they only exist for technical purposes. In particular, QuakeLive reads the portals when running the map and depending on portal visibility it renders the geometry of your map.
In the picture above you can see the top view of a basic room and a corridor. The green line symbolizes a couple of portals created by a common/hint (this is the manual way of optimizing performance, it is not exactly what q3map2 does but it is sufficient to explain the idea of portals). Where the green line hits a wall it gets split so in this picture you can see 3 different portals: one between A and B, one between B and C and one between C and D. What QL does if you as a player stand in section A is , it takes the portal between A and B because it is within your player pov and it calculates what other portals are within the line of sight of the section A (or within the "line of sight of the portal A/B"). Obviously, the portal between A and B can't "see" the portal between B and C which effectively tells the engine that a player standing in section A is able to see B but not C; that's why nothing beyond the portal between B and C will be rendered.
Back to topic, the difference between structual brushes and detail brushes is not only that detail brushes can't be used to seal off your map from the void. Detail brushes as opposed to structual ones don't create new portals during the VIS compile stage. During the VIS stage, q3map2 draws a lot of linear portals depending on your brush work. If you don't convert small brush detail, light fixtures, stairs, doorframes or simular structures to detail the compiler will create one or more portals for each of those details which were left structual. That's why you want to convert any geometry that is not crucial for your visibility (i.e. sight blocking walls, floors, ceillings, main layout brushes in general) to detail. If you don't do that, in a complex map portals might intersect in a weird way and the game might render areas of your map that are nowhere near to being visible from the player's pov which will obviously result in more triangles being drawn at the same time and eventually result in poor performance/fps.
On a map like cobalt station which is also a space float it is probably a different story because you might be able to keep some geometry structual and have the basement area not be rendered from everywhere.
I hope I was able to explain this in a way so you can understand it. If you want more information on portals and hints you can read the Advanced Portal And Hinting Optimization Tutorial written by Obsidian (This is also the source of the image I used above).
Lastly, don't get demotivated if you don't understand all of this immediately. You certainly don't need to know hinting or the VIS calculation to make a map unless you put a lot of detail into it.
Thanks for the clear and detailed answer. This does indeed make sense.
I did make maps for Quake 3 "back in the day", but I think like most people who "casually" did and never really got more into it, mine were only played on our clan's server with the rest of the clan for a fun night of running around somewhere new, before switching back to the same old CTF maps for tournament practice.
Although I did have a basic grasp of portals and hinting from online tutorials, it didn't really matter that much in that setting.
Now for Quake Live it has happened that I get the MAX_MAP_VISIBILITY exceeded error when compiling, if not enough brushes are converted to detail, and I'd have to find the fine line between not enough structural brushes (if I were lazy it would almost be tempting to make one structural box around everything, and make everything else detail) and that affecting performance when playing the map (mind you I don't find this discouraging or demotivating at all, I only find it more interesting).
In the case of for example a very detailed wall, am I right to assume I could just convert everything to detail brushes, and make a structural caulk brush inside it for the structural part?
Last edited by Aliencat; 03-21-2013 at 09:19 AM.
There is a sweet spot, indeed. Of course you'd always try to have as little structual brushes as possible but having a large structual box around everything is not the right approach either. If you do that visibility becomes pointless as there wont be any portals created and all of your brushes will be rendered at the same time. That's why in the videos I advise to only leave your fundamental layout brushes structual and convert everything else to detail.
Yes, you can do that, but only if the wall is truly solid. Caulk brushes block VIS so if you try to cheat using them (i.e. place an entire caulk brush over a wall that actually has a window) you might get rendering issues.In the case of for example a very detailed wall, am I right to assume I could just convert everything to detail brushes, and make a structural caulk brush inside it for the structural part?
Nice video-tutorial an nice explanation about the detail-brushes. But one thing must be outlined: Cityy gives the none-visible-faces of the detailbrush in his video the caulk texture. This is really, really important. If you put two faces of a detail brush (or the faces of a detail and a structural-brush) together that are not caulked, the compiling-prozess wont clip them away. They will be rendered by the engine, even if the player will never see them. That is a waste of performance. Test it with /noclip (start the map with /devmap mapname) and fly right into the detailbrush. If you put the faces of two stuctural brushes together (like this: [_][_]) the faces that touch each other wont be rendered, even if they are not caulked.
@ citty: I think you gave the teleporter a shader-texture with the alphaGen portal. That makes the HOM-Effect, cause there is no camera.
Last edited by TaraHadrian; 03-21-2013 at 01:13 PM.
Yes I'm already very familiar with and used to caulking non-visible faces of a brush
First, let's clear the table of your immediate questions from someone who actually knows what they are talking about.... (j/k)
There is effectively no difference between structural and detail brushes. The BSP process sees them the same way, the engine sees them the same way, the player playing the game will not be able to know of any difference between them. "Structural" vs. "detail" is a bit of a misnomer, since they really are the same thing (did I just blow your mind?).
What is different is that you can flag certain brushes to be ignored by Q3Map2's -VIS process. It's just saying, "Don't mind me, -VIS. Pretend I'm not here because I am not significant to what you are doing anyway." We like to call brushes with these flags "detail", and everything else we call "structural", but really... you should think of them as just the same only you are flagging some to be ignored.
Patches are obviously not brushes, so they don't have any "detail" flags. They are always ignored by -VIS, as if they are a brush flagged as "detail". It's technically incorrect to say that patches are always detail.
On caulk-hull method of building, I am certainly an advocate for it. It removes any guess work as to what visibility is doing with your textured brushes, the only caveat is that you need to actually understand what you are doing. Plus, it's easy to filter out everything and just concentrate on laying hints near caulk brushes. Caulk-hull is for the cool kids.
The whole optimization thing is a huge topic, I made some pointers in the article I wrote years ago that cityy linked above, but reading over it I could explain things better and more accurately now than I could back then. Here is a quick stab at it, I hope to rework it into a more complete work explaining the whole process...
So, what's the major fluff about this structural/detail visibility portals stuff and why should I care?
Ultimately, your end goal is about improving in-game performance. Q3Map2 and the engine automatically do the best with what they are given, but idTech 3 is an old engine and lacks many of the GPU optimizations that modern engines inherently have, so it's rather integral that you manually optimize things.
Instead of rendering your entire map all at the same time (which is taxing on the GPU), what the engine tries to do is draw only the parts of your map that are directly visible to the player, while hiding everything else. You can see this working if you start up a medium sized map in developer mode "devmap mapname" and run around with "r_showtris 1", what you'll see are polygons that pop in or out of view as you move around the map.
The currently rendered section of the map is called your Potentially Visible Set (PVS), that is, a group of convex volumes that makes up everything that you might be able to see from your current location. You can lock your PVS with "r_lockpvs 1" (and use "r_clear 1" so your eyes don't bleed when you run into a "Hall of Mirrors" or HoM). When you find yourself in front of a giant wall of HoM or pink (depending on whether you enabled "r_clear"), what you are looking at is a portal that marks the end of your current PVS.
Q3Map2 tries to automatically generate a PVS based on the generated BSP volumes, but because the BSP is usually much more detailed and complex than what is required for visibility, you end up with all sorts of extra stuff that has little or no effect on visibility other than to complicate things. Your job as a level designer is to simplify and coax Q3Map2 to do a better job, thereby optimizing visibility and gaining better performance.
What's Q3Map2 doing anyway? (The complicated technical stuff)
BSP (Binary Space Partition) is a recursive (it repeats itself until the task is done) function that takes the entire volume of your map and continuously breaks it up into smaller volumes until every single area is a convex volume. The planes between each individual convex volume is what we call a portal. As Q3Map2 continuously refines each volume to smaller convex chunks, it indexes it all into something called a BSP-tree. Each convex volume is a node on the BSP-tree. The more complex the map geometry, the more complex the resulting BSP-tree. That's a lot of stuff that Q3Map2 has to sort though, so imagine if we can help it out a little my lessening the amount of nodes it has to worry about (*cough* "detail brushes" *cough* - I'll get back to that later).
Here is an image representing how part of a map is broken down to convex volumes (G and F) and part of the resulting BSP-tree:
The VIS (visibility) process takes a look at the BSP-tree and uses it to generate a PVS table. The PVS table is an index of all the groups of BSP nodes that form the same PVS. When the player is standing in a particular part of the map, the engine looks at the PVS table and uses it to determine which parts of the BSP tree are part of the player's current PVS. It then draws only the geometry that are part of the same PVS and all the nodes under the same branch of the BSP tree.
So, Q3Map2 generates the PVS based on automatically generated convex volumes. As with all things automated, sometimes it doesn't do things the best way. With a little manual control, you can give Q3Map2 a few suggestions (*cough* "hints" *cough* - more on this later as well) on how to create portals between nodes that are more effective.
More to come...