Almost every HL2 level optimization tutorial I've seen says overlapping brushes are bad news, and basically to avoid them wherever possible. They say it makes VVIS have a fit, it causes shimmering textures, overlapping brushes killed my father, etc, etc. But I've never seen a reason with proof of why they are problematic, and in fact there are many instances of overlapping brushes in the HL2 source VMFs.

Until recently, I diligently made sure none of my world brushes were overlapping, at the advice found in many tutorials and guides, but it takes more time, and makes mapping much more tedious. But from what little understanding of Source BSP I have, I'm pretty sure VBSP nukes everything that isn't facing the inside of properly-sealed map, including faces inside intersecting brushes. I've not seen any ill effects of having world brushes overlap, besides coplanar faces with different textures being split at an unpredictable point, but coplanar faces aren't hard to avoid. The more I look and experiment, the more it seems it's another myth born from ignorance, like texturing all outer surfaces of your map with the nodraw material.

What are your thoughts/experience? and to the few professionals here, what is the norm regarding this at your workplace?

It seems to me that carefully used overlapping world brushes do nothing but save time. And saving time is always a good thing.

---

o

Well, in general I think it's a great philosophy to drill into a new persons head. Starting with a strict goal of super efficient construction will do nothing but teach good habits. Even if the engine culls overlapping faces, the real problem is that people develop sloppy technique. A good mapper really needs to be as effecient as possible whenever possible, as all of the little shortcuts could add up to real performance problems in the end. This was true in the days of r_speeds and low detail, and is still true - no matter the polygon budget.

I do think, however, that overlapping brush based entities is fine for certain situations. I have in the past overlapped detail (func_detail) brushes when needed. You will see this in Valve maps also; for example they might create the roof of a house out of one large brush, then push other details right through that brush. These are always detail brushes intersecting world brushes, or detail brushes intersecting detail brushes.

It was a long time ago, but it was definately documentation from valve that I read, and it gave very technical sounding explainations of why overlapping brushes will indeed be responsible for the death of a loved one.

.....which reminds me of the old joke, where a three legged dog hobbles into a bar, pulls out a six-shooter, and declares in a broad Texan accent, "I've come for the man that shot ma paw."

---

i eat paint

It has to do with building the bsp tree. Most people don't know how that data structure works (nor would I expect you to if you don't know anything about graphics programming).

The basic point is that if you have a lot of overtly complex overlapping pieces (such as world brushes) then it will be a very poor tree. I believe it involves backtracking and managing the tree while creating it at the same time. You get poor balance and things like that. All of a sudden, when you're playing the game and parsing that portion of the tree, it gets very slow, because there's a cluster of nodes because of the poor brush configuration (as an example, I don't know if HL2 has any sort of contingency when creating the tree).

That's the only thing I can think of. It also leads to mis calculated portals, lighting, and things like that. But, if the thing is written properly, there will be some pre-processing step that goes through, clips all this stuff neatly (which it does) and eliminates parts that wont be seen and all that crap. But there's still situations where it's a problem and we already know that Source isn't the most optimized engine.

To be honest, it's a moot point, the source engine was built on outdated techniques. My best guess as to why they continue using this ancient technique is that's how it was done in quake. It's not how I would personally do it ... ever.

---

Blame it on Microsoft, God does.

It's to do with how faces are 'cut' when the map is compiled. If you let brushes intersect willy nilly, it will cut brush faces however it pleases. Placing the brushes (or shaping) them so that they dont overlap gives some control over face intersections and therefore a lower poly count.

Don't know about HL2 but activate wireframe view in HL1 to get an idea. My map Sorrow's poly counts would have been through the roof if i'd let everything overlap in order to save time.

---

You Got To Get Through What You've Got To Go Through To Get What You Want But You Got To Know What You Want To Get Through What You Got To Go Through

Overlapping brushes? Geez, I always thought this is only about visible, overlapping faces (faces in the same plane). Which will obviously cut themselves in the most unfitting way or both stay in the BSP and flicker back and forth.

I never experienced any problems with overlapping brushes. Vbsp cuts them fine.

---

Why snark works.

Overlapping brushes have no effect in map performance, since BSP has
discarded those extra bits of brushes in the vbsp process. Vvis
interprets the resulting faces as if those overlapping sections never
existed. Portals and leafs are calculated after the tools have gotten
rid of them.

The only thing that they can affect is how long vbsp takes to do the
math, which is a very minimal amount of time compared to what vrad
takes to light up surfaces with a low lightmap scale.

It offers no real advantages either. If you avoid them, it will help your vmf look tidy, but not much more than that.

As far as I know.

I'm gonna go with Finger and Crono's advice.
I know for a fact that overlapping brushes are harder on light calculations.

---

Also change the texture of the dock. Docks are rarely tile. -Facepunch
As I Lay Dying

There have been many threads discussing this topic. Some might even be in version 4.5 of this site so search them.

The general consensus is DON'T DO IT!!!

Now mind, everyone has their own personal opinions and all might, or might not have some personal experience to back it up so you will need to just take all of it with a grain of salt.

However, it is so easy to NOT overlap solids that discussing what the issues will be if doing so is rather a moot topic TBH.

My personally opinion is DON'T DO IT!!!

My experience with it is, that some maps have issues some do not. Its rather like the weird event of one map having high R_Speeds for an unobvious reason, and another having low R_Speeds, when all common rules say it should have high ones.

In other words, sometimes the rules just don't follow.

But the basic rule of thumb is, its so easy to NOT overlap solids that doing so is just plain lazy and stupid.

\opinion

---

The best things in life, aren't things.

The way the compile tools work, any faces and sections of world brushes
located inside another world brush or in the void will be discarded.
That means that no performance issue will ever derive from overlapping
brushes. VIS and RAD don't know they were ever there.

But since we are discussing Source mapping, it might be good to point
out that the use of func_detail adds a whole new parameter. Overlapping
func_details is a different issue, since the BSP process doesn't take
them into account when discarding faces (wireframe still shows
face-splitting though...) We might have a case of faces being rendered
and calculated by the compile process but discarded because they are
not inside a vis leaf...

It might be just a myth. But pulling a brush some extra units so that it enters another one is just not useful at all :smile:

I'd say anyone who is going to distribute rmf's or vmf's should think twice before doing sloppy brushwork.

I had a conversation with Scary_1 when I was, lets just say, more of a n00b than I am now.

I was working on Thrasher, which BTW had some major input from him. Sadly, I cannot even recall now if I ever added him to my txt file. I was such a n00b.

Anyway, he was scanning my rmf and asked me why I had so many overlapped solids. In my fear I told him straight up, I overlapped them to blend them better.

He laughed and told me in no uncertain terms that I was in error. The compile dosen't blend.

Anyway, it was he who told me to not ever overlap. I just took him at his word and to my knowledge have never knowingly overlapped again.

Mind, I do not count func_walls and their kin as solids to not overlap.

I have done experiments and found that the only real problem was increased compile times. You got to understand that back then, most of us had machines that were barely big enough.

Now, my machine wouldn't care about compiling an HL1 map of any kind. Back then, I had compiles of 10 to 15 hours+

Anywho....

---

The best things in life, aren't things.

That's mainly the kind of places I'm talking about using overlapping, where in order to seal something properly without overlaps I'd need to split or create one or more new brushes. The way I see it, it's saves a little bit of time when working on those brushes, for example {select brush > Shift+V > move end}, rather than {select brush > Shift+V > move end > Shift+S > select 16x8x8 brush covered by func_details > move tiny brush}

Those are two of the three instances of overlapping in dm_soylent, unless some others snuck in without me noticing. IMO that's tidier than the alternative of having the aforementioned tiny brushes. Just to clarify I'm not talking about pushing walls through eachother willy-nilly :razz:

Starting with a strict goal of super efficient construction will do nothing but teach good habits. Even if the engine culls overlapping faces, the real problem is that people develop sloppy technique.

I definitely agree with this, and while I know I'm not a great mapper by any measure, I've sandboxed around in Hammer for two years, and I've started looking for these kinds of small time-savers, I'm just trying to figure out if there are any adverse effects. What I've seen through testing and read on the VDC seems to indicate there aren't in Source, due to VBSP's removing of intersecting geometry, like Kasperg said.

---

o

It's going to split the face anyway when you do that, it's sloppy practice.

It's going to split the face anyway when you do that, it's sloppy practice.

Well, the choice is: Do we slipt them manually (clipping or creating
the brushes one by one) or do we let the compiler do the job?

<DIV class=quote>
<DIV class=quotetitle>? quoting Kasperg_JM</DIV>
<DIV class=quotetext>

<DIV class=quote>
<DIV class=quotetitle>? quote:</DIV>
<DIV class=quotetext>It's going to split the face anyway when you do that, it's sloppy practice.</DIV></DIV>

Well, the choice is: Do we slipt them manually (clipping or creating the brushes one by one) or do we let the compiler do the job?

</DIV></DIV>

Neither. You make a bit on the end func_wall and stop it from happening. I assume that this would be preferable anyway.

[EDIT] Found my map Thrasher. I did thank Steve in it. Guess I wasn't such a n00b after all. :heee:

---

The best things in life, aren't things.

Face splitting is a natural part of the process needed for a BSP
structure. Leaving space (even one unit) instead of making brushes meet
each other just creates new portal information for VIS, making it much
harder to decide the leafs. Compile times will be much higher having
these micro-spaces throughout the map.

The reason this func_wall method was used was not for compiling
efficiency. It was to get a much better visual result. Face-splitting
taking up more time than leafthreading is yet another myth IMO.

In the case of those brushes in the screenshots, I guess turning the
whole thing into func_detail would do the trick if the other walls are
world brushes and the void is sealed.