Are func_details any harmful to maps?

[pogviuemper]

I get a lot of inspiration and ideas from Valve maps (not just officially added ones, maps that were made by Valve workers), and I also learned most of the important stuff from just analysing their maps.
And I noticed in Valve's maps that there are a lot of brushes that could have been tied to func_detail, and there are some useless brushes that could have been connected into one brush with func_details (for example, the building's roof is separate from the whole building and that roof is tied to func_detail (And I know that normal brushes below roofs usually seal maps). And I don't understand this. Are func_details any harmful for the map in any way, or is it that Valve workers just don't notice these things?

 

[FloofCollie]

World geometry is what creates visleaves that determine visibility, so often buildings are composed of world geometry for optimization. The roofs often protrude from the walls' bounds at obscure angles, which would create incredibly messy visleaf cuts and they're too thin to occlude anything, so they're turned into func_detail for compiling speed and clean visleaves.
I don't know if I'm interpreting this correctly by the way, but the grouping of brushes when you turn multiple ones into a brush entity are only relevant in Hammer for convenience selecting stuff to my knowledge.

 

[Idolon]

I'm not really quite sure what you're asking. Can you provide some images of what you're looking at?

Regardless, here's a few things you should know:

1) Having more visleafs is generally always better for in-game performance. The main downside is that it inflates compile times. Custom mappers are working on home desktop computers, so minimizing compile time is often a concern for us. Valve has beefier machines, and can get away with more complex visleaf structures, so their maps don't always reflect best practices for us, depending on how much you care about compile times.

2) Decompilers don't know what brushes are grouped together as a single func_detail. When you look at func_details in a decompiled map, the groups are just the decompiler's best guess. If you want to look at original Valve vmfs, you can take a look at the vmfs that ship with the old SDK.

Hope this helps.

 

[pogviuemper]

I'm not really quite sure what you're asking. Can you provide some images of what you're looking at?

Regardless, here's a few things you should know:

1) Having more visleafs is generally always better for in-game performance. The main downside is that it inflates compile times. Custom mappers are working on home desktop computers, so minimizing compile time is often a concern for us. Valve has beefier machines, and can get away with more complex visleaf structures, so their maps don't always reflect best practices for us, depending on how much you care about compile times.

2) Decompilers don't know what brushes are grouped together as a single func_detail. When you look at func_details in a decompiled map, the groups are just the decompiler's best guess. If you want to look at original Valve vmfs, you can take a look at the vmfs that ship with the old SDK.

Hope this helps.

Thank you for SDK maps, I've only heard about them but never seen them.
And here's an example from koth_lakeside_event.

So what I'm asking: is there any reason not to make things like on the image? Should I just make as many func_details as I can and minimize the number of brushes used, and will these func_details affect the optimisation of the map? I've read a first thing of what I should know, and that pretty much answers my question. But I hope you understand what I'm asking so you can give me, like, the full answer

 

[Idolon]

Thank you for SDK maps, I've only heard about them but never seen them.
And here's an example from koth_lakeside_event.

So what I'm asking: is there any reason not to make things like on the image? Should I just make as many func_details as I can and minimize the number of brushes used, and will these func_details affect the optimisation of the map? I've read a first thing of what I should know, and that pretty much answers my question. But I hope you understand what I'm asking so you can give me, like, the full answer

As far as I know, this doesn't really matter. This brush isn't really doing anything to block visibility between two areas, so it doesn't need to be a world brush. It's also very basic geometry and won't introduce a ton of complexity to the visleaf structure, so it doesn't really need to be a func_detail either. The first option might be better when it comes to minimizing waterindices?

In other words, I'm not sure what the better solution is, but I can tell you that it isn't very important and you probably don't need to worry about it. Do whatever makes more sense to you.