func_detailing large groups of brushes vs small groups

[psihomir]

So I've always wondered, is there any benefit or drawback to func_detailing a big set of brushes, as opposed to func_detailing smaller sets within it? I have a habit of tying as many brushes as I can to a single func_detail, to reduce the entity count in my map.

Of course I realise that if you are able to see into the visleaf of just a part of such a group, the entire group will be rendered, so I take that into account. But say, when I'm making supports for something, I usually make them all a single func_detail, along with anything detail-ish around them.

So, good/bad, and why?

[grazr]

Ultimately anything that would create complex visleaves is bad and should be tied to func_detail/brush/lod. But, it is also important to block line of sight.

You seem to understand the principles though, and the ramifications of any mistake of either action or inaction of the use of func_detail-ing. Tying all func_details into one entity to reduce entity count is also good practice, as you say. Do you know how to use visgroups? Using this is a good way of detecting possible leaks and predicting your visleaf shapes.

At the end of the day you want to reduce visleaf complexity, number, and block as many line of sites as possible with walls and/or areaportals.

edit: You should also be aware that breaking up of visleafs in the compile process cuts texture faces. So you may have a single face in hammer, but that could turn out to be 2 or even 20 ingame. Generally if something touches another brush that may cut it into several polygons, you will want to func_detail it; and put a less complex shaped nodraw brush inside it to block line of site, if you wish to block vis' visiblity (but this may not always be necassery).

[MangyCarface]

Func_details are NOT rendered as groups. You can effectively make every single detail brush you have into one large one with no impact on performance; this lowers entdata volume.

[grazr]

Which reminds me, it is sometimes useful to make a displacement of a brush that might otherwise have been made into a func_detail. Such as roofs. I've seen a couple walls in out of bound area's on dustbowl that are also displacements.

Displacements don't block vis, and as someone mentioned elsewhere on the forum, are rendered in batches.

As MangyCarface pointed out, there is no effect of ingame performance, so Of course I realise that if you are able to see into the visleaf of just a part of such a group, the entire group will be rendered, so I take that into account is not true. Only the faces the leafnode you are in can see, will be rendered.

I believe this is not the same for props.

[psihomir]

Thanks to both of you. And another related qutesion, since grazr mentioned displacements - is a brush with all 6 sides made into displacements cheaper to render than a normal brush of the same size?

[grazr]

No, again, this really only saves on data as having a single brush is obviously less in your maps total size than 6 seperate brushes to represent each seperate face. Though sometimes it is unavoidable to use multiple brushes for several faces when you are trying to allign displacements together in a complex manner (such as a cave environment or anything with convex shapes).

The faces will be the same size, so there would be no impact on performance.

[FaTony]

func_detail's are cut after BSP, so they aren't entities ingame. They render as normal brushes. U can group all ur func_detail's in 1 entity in Hammer or make each single "detail" brush func_detail but it would have no differences ingame.