Very long compile on VVIS (Source)

I'm a sucker for using hint brushes to the extreme to pretty much manually build my BSP. In a lot of places this is unnecessary as BSP would have cut things up that way anyway, but (if you know what you are doing), it doesn't hurt to do it's job for it. Even if you don't take it to the same extreme as I do, adding some well placed hint brushes can save masses of unnecessary BSP leaves, and therefore cut down VIS time significantly.

A good place to start with hint brushes would be in your doors and windows - BSP has a tendancy of pulling leaves out through doorways and into the open areas on either side, thereby making awkward leaf layouts. To minimise this, at each of your doors/windows, build a brush, covered in the skip texture, that fills up the hole. Now texture each of the open sides of the brush (the ones facing into the areas on either side) with the hint texture.

This won't help in EVERY case, but it does help in many, and so its good to get into the habit of shoving these hint brushes into doors and windows. Use GLView (as per Defrag's batch file) and/or mat_leafvis 1 in-game to get a feel for what effect your hint brushes are having. Once you've got a better understanding of how it all works you'll probably run into loads more ways that hint brushes could help optimise your BSP.

Hint brushes aren't only useful for cutting down on unnecessary visibility!

Quote from NykO18

Yeah, I agree. But with a 10 faces tunnel like mine, if you add a cubic shape outside, it adds 4 faces.. 40%. I think that adding faces just to shorten the compilation time isn't a good idea, especially when VVIS manages to make "cylindrical" vis-leaves at last. I don't think that's a problem.Also, isn't the lightning way much crappier on func_details ?

Anyway, it's a trick I often used on my past maps and I tend on not using it anymore. Don't know why, I think I'm giving to much hope in VVIS.

Calculation of a trillion weird vis leafs is for sure more expensive then a few additional faces. My technique not only decreases compile times it also improves ingame performance.

You are right that lighting on func_details can be crappier. But only if you got "overlapping" brush faces on them. the bsp compile often doesn't cut the faces correctly like it would do with static brushes so you have to help the bsp by hand.

[Blocked Image: http://img165.imageshack.us/img165/6149/funclightingvl9.jpg]

Quote from hessi

why should there be any additional polygons drawn? nodraw still creates leaves. creating non cubic leaves is ALWAYS a pain in the ass.

is there any way to completely get rid of them (assuming they're non-sealing brushes)? should i be using skip instead of nodraw?

Not sure I understand your question diss - completely get rid of what? The faces? The leaves?

Skip covered brushes won't do anything - the point of skip is that faces textured with it are ignored by the compile tools (which isn't entirely true, but its near enough). If you have a brush covered entirely in the skip texture, then there is no purpose to the brush (unless you created it to aid you in hammer, but that's another story), so you might as well just delete it.

Nodraw exists precisely for scenarios like the ones being talked about here - creating solid brushes for BSP/VIS purposes, without adding any rendering costs. If you want to simplify your BSP, then you can use nodraw brushes to make a simpler, not necessarily visible "hull" to your level, and use func_detail brushes to fill in the awkwardly shaped architecture.

Quote from ReNo

I'm a sucker for using hint brushes .....A good place to start with hint brushes would be in your doors and windows...

Right now, I put areaportals in all the windows/doors to help in performance -- I guess I should also be putting in hint brushes in these same doors/windows? Does it matter where the hint brush is with respect to the areaportal? ....to the outside or inside of the door/window?

Quote from Steppenwolf

You are right that lighting on func_details can be crappier. But only if you got "overlapping" brush faces on them. the bsp compile often doesn't cut the faces correctly like it would do with static brushes so you have to help the bsp by hand.

ahh, I am using some func details like the above picture to simulate an arch -- ideally, I should use vertex editing and fix the "arches" to be more like the one with the smiley guy?

Quote from ReNo

Not sure I understand your question diss - completely get rid of what? The faces? The leaves?Skip covered brushes won't do anything - the point of skip is that faces textured with it are ignored by the compile tools (which isn't entirely true, but its near enough). If you have a brush covered entirely in the skip texture, then there is no purpose to the brush (unless you created it to aid you in hammer, but that's another story), so you might as well just delete it.

Nodraw exists precisely for scenarios like the ones being talked about here - creating solid brushes for BSP/VIS purposes, without adding any rendering costs. If you want to simplify your BSP, then you can use nodraw brushes to make a simpler, not necessarily visible "hull" to your level, and use func_detail brushes to fill in the awkwardly shaped architecture.

but for faces that aren't part of the hull and are going to be culled anyway, should i be using skip rather than nodraw? if i understand correctly, both take nothing to render, but skip will compile faster. is this correct?

Diss: If a face is to be culled from your map (e.g. its outside the hull), then it really isn't of much importance whether you use skip or nodraw, or any other texture for that matter. Its gonna get culled whatever you plaster on it What texture you use only matters if the faces are inside your hull. In these cases, using skip would mean the face is culled completely (no collision, no lightmap, no BSP cutting, no nothing), whereas using nodraw would mean the face still exists (still has collision, BSP cutting) but doesn't have any properties related to rendering (no lightmap, and not rendered). For these reasons, you couldn't use skip covered faces as part of your hull, such as was the case in the "fake cubic shaped room behind a func_detail arch" scenariobut you COULD (and should) use nodraw.

Dradz: Area portals should generally be 1 unit thick and placed in the middle of the window/door's depth. The hint brush should be the same depth as the hole, so that its two hint covered faces are flush with the openings (e.g. if you have an 8 unit thick wall with a door in it, place a 1 unit thick area portal 3 or 4 units in from either side, and place an 8 unit thick hint brush with the hint faces flush with each side).

Thanks, that cleared a lot up. So, nodraw for hull brushes, skip for interior brushes? I'm trying to get the fastest compile possible.

Quote from ReNo

Diss: If a face is to be culled from your map (e.g. its outside the hull), then it really isn't of much importance whether you use skip or nodraw, or any other texture for that matter. Its gonna get culled whatever you plaster on it What texture you use only matters if the faces are inside your hull. In these cases, using skip would mean the face is culled completely (no collision, no lightmap, no BSP cutting, no nothing), whereas using nodraw would mean the face still exists (still has collision, BSP cutting) but doesn't have any properties related to rendering (no lightmap, and not rendered). For these reasons, you couldn't use skip covered faces as part of your hull, such as was the case in the "fake cubic shaped room behind a func_detail arch" scenariobut you COULD (and should) use nodraw.

Based on this reply, I would conclude that one should use the skip texture on any face that one doesn't want either the player to bump into or the vis leaf to be cut along ? If that makes any sense at all....

If that's the case, then I can't think of many reasons to use nodraw. Basically any face that is not going to be used to cut vis leafs should be skipped instead of nodrawed....

I can't help but think of this as the way a model should be made. As in, a skip textured face = a deleted face in a model and a nodraw textured face = an untextured face in a model, that the player can't see.

Am I getting what you're saying or am I completely off ?

To be honest, I don't use skip on anything other than hint brushes or brushes I make to help move things in hammer that I don't want in game. I don't know what sort of behaviour you would get if, for example, you applied it to the sides of a brush with 1 normally textured face. Would the textured face have collision, while the rest of the brush wouldn't? Even if you approached it from it's back side? Something worth testing I guess.

In general though, just use nodraw if you have faces you don't want in your map. The only costly parts of having a face when it comes to compile times are generating the lightmaps during RAD, and any implications it has for the BSP. If it's inside your map and you DON'T want the face to be rendered and DON'T want the face to complicate the BSP, then make it a func_detail with nodraw on it. Even if skip does mean the face is completely ignored, the only additional benefit I can think of would be that it doesn't have to account for it in the collision hull...not something the compile process normally takes more than a couple of seconds on anyway. And hey, if you want your brush not to have that, just make it a func_illusionary.

Right, then I won't change my own habits I must say I was surprised Valve only uses nodraw on those faces.

looks like skip being on even one brush face will get that brushed removed.

Well I learned something new, very nicly worder Reno. I should prob go through my BMS maps and do some changes to make them run a little smoother instead of the VRAD times I get.

Quote from NykO18

Hey, I know what func_detailling means.But, when half of the map is made of cylindrical tunnels, it's not really a good idea to shape it quickly inside cubic rooms. Especially when there's an insane amount of detail and expensive water.

I prefer waiting 7 or 8 hours (night compiling) and getting better FPS than doing a one hour compile and getting crapy vis-blocking.

You do realise that it isn't free to recurse the bsp tree during runtime? The idea that compile times and runtime performance are somehow disconnected isn't true -- if you have a million tiny little fragmented vis leaves then you also have portals connecting them, particularly when you have a local area that has a disproportionate complexity compared to the rest of the map. This slows down rendering, probably decreases the batching efficiency of the engine, collision detection and visibility determination. It's sometimes not a huge difference, but the assertion that doing it the way suggested will result in "crappy" visblocking and poorer framerates just isn't true. If you do it in an optimised fashion, vis won't suffer in terms of what is being drawn/not drawn. Furthermore, sometimes it is more costly to vis-block something than it is to render it! It's not a black and white issue really, you just need to experiment.