Will emliminating intersectng brushes optimize my map?

I am pretty aware that having world brushes intersecting (having a part of one brush inside of another) with func_brushes increases the compile time, but what about just world brushes with other world brushes? Would it be efficient in terms of optimization to ensure that NO brushes are intersecting?

Does this also apply to decals, overlays, and props as well? I want to know this because I prefer to optimize maps as I go, and I wouldn’t have the patience to take care of it later on in development.
Sorry if this has been spoken about before, but search won’t work.

Absolutely. I find having intersecting brushes can often fuck up your visleafs. It’s just good practice to make sure all your brushes are separate.

However, don’t worry about decals, overlays and props. It won’t affect anything if they’re intersecting something, but if a prop has it’s origin outside the map that can cause a leak.

It doesn’t matter because vbsp handles this.

No. Intersecting brushes are still rendered, ever try having two different textured brushes occupying the same space? Shit happens.

For OP: Use angled corners as much as you can, it looks bad when bordering textures aren’t lines properly.

So you get this:

| |
| |

Instead of this:

| |
| |

You’re wrong.

What an intelligent response I am inspired

Don’t feed the troll.

If nothing else, intersecting brushes make the 2d view more cluttered, so keep it neat for your own sanity if nothing else.

I’m not trolling. He is wrong.

I’m really OCD about intersection brushes and always join corners with mitre joints to minimise the number of exposed faces.

I’m fairly sure vbsp cuts intersecting brushes, although it may only be brushes with the same texture.

Nope. Even brushes with the same texture aren’t cut. If two brushes occupy the same space, they’ll both be rendered ingame.

Its still always a good habit to make sure your brushes don’t intersect. Just for the sake of organization. Even with organized visgroups, the grid still gets to be quite the clusterfuck.

VBSP can handle most intersecting brushes. If you don’t believe me, make a small map with two rectangular walls that intersect. Compile it, then noclip inside the walls.

You will see the inside faces of the walls (which are inside the corner) are not rendered.

Completely covered faces are not rendered and I assume this is true if the face is completely covered yet inside another brush. (See yellow areas in diagram).

You may have a valid point but there is no doubt that fixing intersections can and will improve visuals.

Lets look at a diagram depicting overlapping brushes.


Purple areas are rendered twice which is unnecessary. Also note the visleaves which are cut excessively. This is quite unnecessary not to mention the textures overlap and flash violently when you move your view.

I hope this clears up the dispute and please correct me if I mentioned anything untrue.

I did do that a lot, however I still left most of my brushes how they were initially placed, which was bad. I didn’t also think that this problem would hurt your map so bad. Thanks for the help, I guess it’s time to be more careful.

It’s good practice not to have overlapping brushes or brushes that cut into one another. Overlapping brushes can cause things like flickering faces to be seen by the player. Another thing is it can make it a bit more difficult to navigate the 2d viewports. It’s also a sign of laziness. So don’t be lazy build shit correctly. VBSP will probably compile faster, not that noticeable on small maps I am sure but on complicated maps with tons of brushwork, probably. Could also possibly cause funny visleafs that may somehow see all visleafs or a lot of them, causing random lag spots(just a theory, don’t have anything to back it up).

Would you guys consider this very needed, because I think quite a few brushes in my map are intersecting. But on the other hand a majority of them aren’t and are all organized, so do you think it would help tons or it would just reduce compile time a bit and give players a slightly better framerate?

Probably just reduce VBSP compile times and contribute to a marginally higher framerate, unless your brushwork is epically fucked up.

My brushwork is quite decent, I was just curious how much this would help. In the future I’ll take care to prevent intersecting brushes though to buy myself as much optimization as I can get.

This phenomenon is known as “Z Fighting” where two objects in the Z buffer are so close together that the renderer can’t figure out which object should be rendered in front of the other, so it alternates back and forth rapidly.

It used be common on older engines (the WON version of the HL engine had it really bad, and was easily exploited to see people behind non-solid opaque walls) due to the fact that the Z buffer used for the engine was less precise than it is now (8 or 12 bits vs 16, 24 or 32 bits now.)

It basically does this when two planar brush faces occupy the same space: