Some brush questions

[bob+M|M+]

I've always wondered if playerclip, func_detail, trigger_teleport, and func_wall type brushes split other brushes in game. Or can I use these things without worry of overlapping and intersecting other brushes for fear of lowered FPS?

Also is it necessary to use nodraw on the backside of the skybox texture?

Thanks
bob

 

[Jive Turkey]

I would assume playerclip only effects the collision mesh, not visibility. As for the others, it is my understanding that anything that is turned into an entity does not anymore affect visibility. That would cover func_ and trigger_ anything.

Also, whatever brush faces are completely obscured by other brush faces (say the touching faces of a mitered wall corner, and all edges must line up) or that touch the void are automatically nodrawed. So no.

 

[Sgt Frag]

The main purpose of func_detail is to NOT split vis_leafs.
This helps keep vis leaf count down which does helps fps. Not an expert on it but the game uses vis_leafs to calculate which areas the player can see (what will be drawn). If you are in a large square room it can be as simple as one vis_leaf to calculate. If you add 20 stairs in that room it can turn into probably 21+ vis_leafs to calculate, for no real reson.
Making the stairs func_detail allows them to not split terrain/vis_leafs. Thus lower polycount/lower vis-leaf count/lower fps.

I haven't looked into it yet but this is alot like func_statics in Radiant (Doom3 engine). In that engine the brushes on a func_static stairway will cut each other up, but not surrounding terrain. I suppose that Hammer does the same.
So splitting seperate pieces of stairways (like the stairs themselves and the trim along their edges) into different func_details should help lower polycount.
In radiant this is a balancing act as there is a limit to func_statics you can use, something like 4,000. Not sure if this is a limit in Hammer, but alot of TF2 maps tend to be small enough this probably isn't a concern anyway.

Player_clip shouldn't cut polys of terrain at all. Still they can have a benefit to FPS too. Maybe nothing major but when combined with everything else I'm sure it can help.
Reason being is like Jive Turkey said. They are used to calculate terrain. So used as they were meant to be they actually simplify player collision detection in game. Simplifing collision for 24+ players surely can have an impact in more complicated areas.

I would think that trigger brushes would not split terrain either as they are not rendered. Hammer doesn't have to calculate which tex goes where. And they are not used to calculate vis_leafs since they can't be seen.

func_wall, I have no idea what that's for yet. Due to the fact it's a func_ brush I would guess it doesn't split terrain either.

 

[bob+M|M+]

Thanks for the elaborate responses. I've never heard about collision mesh vs visibility before.

so let me get this straight... playerclip, func_, and trigger_ brushes are not visible and so they do not affect visibility and thus do not split other brushes.

but playerclip, an invisible brush with volume, has a collision mesh which meshes with other brushes in such a way that does not hinder performance, but instead can actually increase performance. am I right?



Sgt Frag as for func_wall I can tell you a little bit about it. I think the most common use is for disallowing engineering buildings. It also allows you to make transparent walls, such as turning a texture into glass, or making a colored or additive wall. my personal fav is for preventing a demoman stickybomb's adhesiveness.

 

[Jive Turkey]

It isn't just that they're invisible as nodraw brushes are themselves invisible yet they do affect visibility (the division of the bsp tree). Likewise hint brushes are not drawn, but they explicitly affect visibility.

For the most part the "collision mesh" can be thought of as a separate concept mostly divorced from aspects of visibility. For instance, a regular brush will affect visibility and collision, a nodrawed brush will affect visibility but not collision, a playerclipped brush will not affect visibility but will affect collision, etc. Whether something blocks entities physically or not has little to do with how the level is rendered.

Btw. From the wiki for func_wall:

Obsolete entity from Half-Life provided for backwards compatibility. Has been replaced by the func_detail entity and the func_brush entity with its Solidity property set to Always Solid.

Also, a distinction here. playerclip is just a texture. You assign it to normal world brushes without creating an entity. Something like a func_ or trigger_ brush are brushes which are explicitly made into entities, and anything you make into an entity stops becoming part of the "world" and thus stops affecting the way the world is cut up (visibility). This is because entities cannot be assumed to be static, as through their own volition or in so far as they can be parented to other entities they have the potential for movement or being enabled/disabled.

This page contains a quite lengthy and invaluable discussion of the concepts of visibility in source mapping and the tools at your disposal to affect and optimize the final rendered level.

 

[Foreverkul]

Just a tip: stairways will take a lot longer to compile than ramps so you might want to keep that in mind.

 

[Jive Turkey]

Actually stairways don't have to take longer to compile. The page I mentioned in my previous post deals with this very same situation on this page. Basically you build a ramp under the stairs (to simplify, but not eliminate their effect on visibility) and then build the steps out of func_detail brushes