detail brushes

So is it safe for me to use detail brushes on most of my surfaces, i.e. building fronts, my gas station, subway tunnel, etc? My compile time is going on 40 hours as we speak and I don't know if it's because I have an open area the size of a football field or what. I'm not entirely sure what I should do at this point. I hear rumors that this significantly speeds up compile times. Thanks.

http://www.snarkpit.com/forums.php?forum=1&topic=3396&highlight=optimizing&findpost=66176#post66176

<DIV class=quote>
<DIV class=quotetitle>? quoting Mouse</DIV>
<DIV class=quotetext>Indeed, detail brushes are amazing things. I used them for trims, entire buildings, walkways, stairs. The whole gas station in my map was all detail brushes. Also, the whole broken building, which is actually about 7 or 8 different brushes, is all func_detail.
</DIV></DIV>

Detail brushes are perfectly safe, but you shouldn't just use them all
over the place. Its important to learn where they are suitable for use,
and where they are not. What stage of your compile is taking so long to
run? If it is VIS, which I'd assume it is, then you will almost
certainly be able to use detail brushes to cut that down. As a short
reply, you ought to use detail brushes for complex or small pieces of
brushwork, that do not really block the visibility of the player and do
not contribute to the outer hull of the map. Try looking for info on
func_walls for HL1, as their main use was the same as the new
func_detail for source.

<DIV class=quote>
<DIV class=quotetitle>? quoting ReNo</DIV>
<DIV class=quotetext>Detail brushes are perfectly safe, but you shouldn't just use them all over the place. Its important to learn where they are suitable for use, and where they are not. What stage of your compile is taking so long to run? If it is VIS, which I'd assume it is, then you will almost certainly be able to use detail brushes to cut that down. As a short reply, you ought to use detail brushes for complex or small pieces of brushwork, that do not really block the visibility of the player and do not contribute to the outer hull of the map. Try looking for info on func_walls for HL1, as their main use was the same as the new func_detail for source.
</DIV></DIV>

You're correct. It's the VIS that's taking the longest. I've placed the nodraw texture on all surfaces that the player cannot see which cut my file size from almost 10 mb to now 6.5 or so, which I thought would drastically cut down on compile time. The main area in my map is just an open city block with a service station in the center and a subway underneath the street. I have a skybox all the way around my map and am using a 3D skybox for nearly every building model that surrounds my city block. There are maybe 3 or 4 rooms total in the entire map as most of it is just building fronts. If it cuts down on my compile time considerably, i'd like to make my building fronts (including the building trim which isn't in excess) using the detail brushes. There really isn't anything over technical in my map and 80% of the outside area can be seen at the same time, save what the one story service station is blocking. Any advice with this new information would be greatly appreciated. 40+ hours is rediculous. In the mean time, i'll take a gander at the func_wall write-ups. Thanks.

System specs:
P4 2.6ghz, 768 mb ram, ATI 9800 Pro 256mb video card, Win xp

I think you need to do a little reading up on what the compile tools actually do.

Basically, VIS splits the map up into convex sections known as leafs.
From each of these leafs, it figures out what other leafs might be
visible. Everything in the potentially visible leafs is rendered, even
if it is actually hidden behind a wall or something.

A leaf has its boundaries on world brushes, and as mentioned, it has to
be convex in shape. Therefore, if you had a simple box room with no
contents, it could be made up of only a single leaf. If you then added
in a thin cylindrical pillar to the centre of the room, then the number
of leafs would increase drastically. This in turn would increase
compile time during VIS, as it would have to calculate for each of
these leafs, what leafs are potentially visible. The benefits of this
are negligable in these circumstances - even if one or two leafs were
culled at any given time, chances are the performance increase in game
would be next to nothing. In this scenario you would turn the pillar
into a func_detail as this means it is not taken into account during
VIS, and the room could once again be made up of only a single leaf.

Meh, that probably isn't overly clear, I might write up a tutorial on the topic if I can be bothered.

I'll definitely do some reading up on the comile tools. In the meantime, I found this on:

http://members.lycos.co.uk/EditHalfLife/tutorials/funcwall.htm

"The func_wall entity is often used by mappers when they want to prevent polygon subdivision and encounter leaf warnings/errors.Should this be the way? The answer is not always. You can't always depend on func_wall to be your easy solution to any problems you face.

The most important point in this whole tutorial is that turning a brush into an entity means that this entity polygon(epoly) does not block visibility...VIS ignores entity polygons.Also entity polygons may not subdivide wpolys into more wpolys but you must remember that once you can see any part of an epoly, all of it is visible to the engine so all of it is drawn.


<H4>So when should you turn wpolys into epolys?</H4>

It really depends on the situation.If you have leaf warnings/errors you have 3 options,

• Simplify the area thats causing the problem.
• Delete the problem area.
• Turn it into a func_wall.

You should only use the last solution if this problem area will not affect visiblity calculations.For example things like wall brushes should never be turned into an epoly.Other brushes such as pillars really depend on their size, large(complex)pillars will in general be better off if left alone while smaller pillars should be turned into a func_wall in order to prevent polygon subdivision.

For small complex brushes i'd recommend turning it into a func_wall but if you encounter problems with these brushes (leaf warnings/errors), you need to simplify (or maybe delete) the problem.

Finally there is one thing i haven't mentioned which is something obvious but something that has to be kept in mind.Entity polygons are also polygons ie they need to be rendered by the engine."

With that being said, I suppose my building faces shouldn't be used in this way. However, the only complicated (if you can call it that) world brushes I have are probably stairs, or rotated 2x4 pieces of wood covering a window. Could this be a problem? I have my sidewalk overlapping my street, just to ensure that a player can't see through underneath the map. Can this be contributing to the VIS problem? Also, on my gas station, the roof has 2 layers butted together and are pretty thin. Don't ask me why I did that. I need to change that regardless, but I really don't know what else to say. I do have some models such as cars models in which the model box in the 2D view goes into the street, and a few handrail models that go into the wall on the 2D views. I don't know, just trying to narrow down my problem. Again, thanks.

Unless my knowledge on this topic has always been flawed, entity
brushes do not start adding to epoly as opposed to wpoly - only models
contribute to epoly counts. The truth behind this is redundant in HL2
editing anyway though - detail brushes act exactly like world brushes,
bar the fact they do not cause face splitting and do not block VIS.

In my opinion, much of that tutorial (or at least what you posted of it) is incorrect, or at least I disagree with most of it.

I sound like a broken record, but detail brushes can cause face splitting in certain situations. Basically if the vertexes of a func_detail touch the edges of a natural face split between two brushes they will cause additional face splitting on both brushes.

EDIT: my little ascii drawings didn't work

Now func_detail does a perfectly fine job of reducing compile times, so if that's all you're worried about go nuts. But if you are trying to optimize your map and reduce world rendering (face splitting increases this to my knowledge) you need to be careful how you use the detail brushes, as you may not be accomplishing anything on that front.

I sound like a broken record, but detail brushes can
cause face splitting in certain situations. Basically if the vertexes
of a func_detail touch the edges of a natural face split between two
brushes they will cause additional face splitting on both brushes.

Could you expand a little on this description? I don't understand what you mean by "a natural face split between two brushes".

I've been playing with func_details in a test map, and have yet to find
them causing any face splitting in any arrangement. I've tried them
touching the middle of a world brush face, on the edge of a face, as an
extension of a brush, etc., but no splitting yet.

I had a look at that other thread you posted screenshots in, and I
can't replicate the effect you're seeing (though I may be
misinterpreting the arrangement of brushes I'm seeing in your shots).
It may be due to the low level of complexity of my test map, so it'll
only happen on a real map, I don't know.

I'd like to know what situations to avoid using func_details in, or where to watch out for problems, anyway.

<DIV class=quote>
<DIV class=quotetitle>? quoting Yak_Fighter</DIV>
<DIV class=quotetext>I sound like a broken record, but detail brushes can cause face splitting in certain situations. Basically if the vertexes of a func_detail touch the edges of a natural face split between two brushes they will cause additional face splitting on both brushes.

Now func_detail does a perfectly fine job of reducing compile times, so if that's all you're worried about go nuts. But if you are trying to optimize your map and reduce world rendering (face splitting increases this to my knowledge) you need to be careful how you use the detail brushes, as you may not be accomplishing anything on that front.

</DIV></DIV>
Yes, this is true, they sometimes cause face splitting (to me it seems to happen most when you have some kind of wall made of a func_detail, causing the floor to be cut up) but a cunningly placed HINT brush can usually solve this.

<DIV class=quote>
<DIV class=quotetitle>? quoting Rof</DIV>
<DIV class=quotetext>I'd like to know what situations to avoid using func_details in, or where to watch out for problems, anyway.
</DIV></DIV>
Say you have a connection b/t two large rooms that you would like to have connected, but at the same time have them be in rendered separately. You can achieve this by placing a solid brush to block out whats on the ohter side, I cant really show you the aplication of this without a picture, or an example map. I actually used this same concept in my contest entry, but currently its over 5mb and my server wont allow me to upload it. Basicly don't use detail if you want a brush to block vis, or to cut vis up into more leafs.

Basicly don't use detail if you want a brush to block vis, or to cut vis up into more leafs.

Oh yes, I know this stuff. I realise you should only use func_details on brushes that wouldn't block vis significantly normally.

What I'm wondering about is in what situations will func_details split
the faces of world brushes (because they're basically useless if they
do that, except to reduce compile times).

I dont know what Yak is talking about (although im sure its true), all
I can say is type in "mat_wireframe 3" to see the BSP cuts, and to see
if a detail does cut up faces.