Very long compile on VVIS (Source)

[Furyo]

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 ?

[ReNo]

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.

[Furyo]

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

[dissonance]

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

[atrocity]

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.

[Defrag]

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.