Overlapping brushes. Good, Bad or Ugly?

(psychosanity) #1

From the Radiant Manual:

Brush Construction

It cannot be overstressed. If you want shorter compile times and small file sizes, efficient brush construction is “critical” in building your map. There is one rule that stands above all:
DO NOT OVERLAP BRUSHES AT ANYTIME.

No matter what you have to do to build your map, do not overlap brushes. Overlapping means that all or parts of two or more brushes share the same physical space. If brushes overlap, you can expect to add time to your compiling, and add size to your .map, .bsp and, .aas file sizes.

Efficient map construction means that all brushes butt up against each other, but never intersect.

  1. Goldrush has overlapped brushes EVERYwhere.
  2. Some brushes, in fact, MUST overlap other brushes (origins? clips? triggers? fog? etc. etc.)

What exactly is the problem with overlapping brushes? Is it simply that the shared space is calculated twice, once as part of each brush? That doesnt sound like much reason to avoid overlaps at all costs, and since the Goldrush mappers obviously disregarded this, I am very curious as to how hard I should work to avoid it.

(carnage) #2

imo this is bullcrap, anyone who builds a map to have a short compile time is heading in the wrong direction. ime pretty sure when someone played a map there not going to like it more cos it compiled quicker for you

pluss this removes the davantage of being able to build a astheticaly nice map and then give it a very efficint and well placed set of structural caulk brushes

so dont go mad but there are load of places where overlaping brushes is the best or only option, how would u place a decal without overlaping brushes?

(thore) #3

Lol, that’s funny, I just talked with a friend of mine about exactly that topic… and now you posted it :smiley:

I was very diappointed when I started mapping just because of the “word of wisdom” you quoted.
“Do never never never overlap brushes” I read in every tutorial. When /noclip-ping around in some of SD’s maps
I realized that even those pro mappers didn’t take it too seriously when it comes to overlapping brushes. By now
I take care not to overlap the visible faces because z-fighting isn’t really that beautiful. When it comes to the
caulked backside of the brush I try to shear or clip the brush… but there are these moments when it’s just
a LOT easier to have two brushes overlapping instead of spending hours on vertex editing, splitting faces,
using brush cleanup, see half of your brushes being “cleared” and creating all those twisetd brushes from
the beginning.

Messy brushwork WILL give you z-fighting when visible faces overlap and MAY cause some lighting issues.
Whether or not overlapping brushes have an impact on fps I don’t know though. Again, I’ve read the
warning several times… but never found an explanation why it shouldn’t be done.

Anyone interested in building a testmap “clean vs messy brushwork”… a study on fps?

~ Greetings

(carnage) #4

i think u have another issue there, overlaping brushes is differnt from interesecting faces

two overlaping clip brushes i think would not have a effect of fps however when two tris overlap there must be some kind of calcualtion as to what point to draw that brush before it meets the next one. saying that looking on goldrush the buildings intersect with the floor brushwork and on other map u can see where faces overlap. probably as its outweighs the extra number of faces that would have to be draw to get a nice border with the faces

(SCDS_reyalP) #5

That section of the manual is pretty much wrong.

What you do want to avoid is overlapping faces which are actually drawn in game. Things like caulk, clips, hint etc which are non-drawing can overlap each other, or a single drawing face, without causing any problems.

(Ifurita) #6

search for the t-junctions tutorial I wrote with the help of ReyalP and Detoeni. You can see the different between efficient and inefficient construction, though at some point you have to ask yourself what is actually worth doing.

(EB) #7

I have one about 40 percent done…dealing with -vis, tris and FPS.
If you’d like to share ideas…you will get a nice cozy spot in the README file. >>>Otherwise…another FPS test map for the community would be beyond a great benefit.

(DWM|Commando) #8

I wouldnt care what that says, I tend not to overlap just so I can caulk more parts and make it look cleaner, but sometimes its impossible not too. Like when you have maps that are build on angles, and things dont fit perfectly, but its usually a 1 unit overlap that no-one sees.

(Ifurita) #9

EB, you should put together a single, simple room, with a square column in the middle, but layer it with complex, multiple pass shaders, etc to demonstrate that tris count is only part of the equation, the other part being how many times each face is being drawn

(EB) #10

excellent point ! This will be a nice expansion.
-Cheers

(psychosanity) #11

Well, I went ahead and performed a little down-and-dirty experiment:

I made a big 'ol box with a spec, red, and blue spawn.
Then, I imported the terrain (9800 brushes) from the map I am struggling thru…twice.
I spread the two terrain entities apart and compiled.

Then I overlapped the two terrains.
I recompiled.
Then I boggled at the numbers.

Separated : 106 secs.
Overlapped: 94 secs.

It appears that overlapping actually speeds things up a bit :drink:
Anything wrong with my methodology? I dont know much about the inner workings of the compilation process.

(Ragnar_40k) #12

For overlapping brushes: You should test the map with 16-bit z-buffer setting. When it starts to flacker alot (z-fighting!) you should do something about it. Otherwise its ok (IMHO), since with overlapping brushes you can simplify some things.

(psychosanity) #13

ya, z-fighting sucks but thats from overlapping textures…isnt it? I believe these are two completely different issues…

(Ragnar_40k) #14

Overlapping brushes usually lead to overlapping textures (even if you try to avoid it).

(Detoeni) #15

but layer it with complex, multiple pass shaders, etc to demonstrate that tris count is only part of the equation, the other part being how many times each face is being drawn

I had a quick play with this, theres 900 surfaces in view (they are there, you just cant see them without show tris), each with two layers that blend with the layer below. In the map there is just 9 brushies
screenshot

(SCDS_reyalP) #16

Which is why all but one of them should be non-drawing textures…

Note that z-fighting can be caused by brushes that are just near enough, they don’t have to be overlapping.

Then I overlapped the two terrains.
I recompiled.
Then I boggled at the numbers.

Separated : 106 secs.
Overlapped: 94 secs.

First of all, note that the difference is pretty minimal. Did you do a couple of trys to see what the normal range of times was ? The second compile may have been faster just because the disk caches were warmed up by the first one.

Secondly, overlapping brushes are more efficient in some respects. Identical planes are only stored once, for example.

You don’t say what compile you did, but I would expect vis and light to go faster given a smaller area, which the overlapped version would provide.

As you can see, this kind of test isn’t likely to tell you much about real world maps. Honestly, I wouldn’t worry about compile times unless they are hindering your development. 10% one way or the other isn’t going to matter. Runtime performance is another matter…

(psychosanity) #17

Oh Im not worried, just curious… and the compiles were all just BSP, and I did each twice, and got exactly the same times, down to the sec.

But like I said, just curious. I’ve just been overlapping whenever I felt like it…no probs so far

(EB) #18

If you want shorter compile times and small file sizes…<< stress the " IF "
[humour]You’ll read alot more “not fully non-sense” statements as you scape your way through mapping.[/humour]
They are meant to save you headaches in the end. Whether or not you understand “why” is of no consequence as they have gone to an extent to inform you.

The compile time is something that you can work with during testing…but as REYALP said, “Runtime performance is another matter…”
And as Loffy says below, " FPS is KING!!! "

(Loffy) #19

Frames-per-second is king, as Sock said once in this forum.
I try not to overlap, but sometimes it is much faster just to let them overlap. And performance does not seem to be affected negatively so I just ignore those brushes as long as it looks good in the game.
Z-fighting is something else as said above and no-one wants that. I found some z-fighting under a table in one of the first levels in DoomIII. “Is that z-fighting? Well, even the professionals.”, I thought.
//L.

(carnage) #20

well i read that if something is inside a strictural brush at will be removed at compile time, so…

if u have a messy detail wall with lots of caluk sticking out that back then u make a structural caulk brush as a stuctural hull pice it should neaten up the detail bits from the back of the wall

much quicker than having to shear of the wall bits urself with same performance in the end. overlaping is not all bad