Overlapping brushes. Good, Bad or Ugly?

(SCDS_reyalP) #41

http://www.quake3world.com/forum/viewtopic.php?t=3620

The post there is more to do with hinting etc, but check the links in the first post, in particular, Qs sample map http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20020703-6-020488.html

Other examples of overlapping brushwork tend to involve non-drawing things like clip, hint, triggers etc. Water and fog also also come to mind.

One problem with the ‘rule’ in the radiant manual is that it doesn’t mention any of the exceptions. The other problem is that the mere fact of overlapping isn’t a big deal in terms of compile time, assuming you are using overlapping brushes in one of the sane ways described above.

What should be stressed is that overlapping drawing faces is something to be avoided, although there are cases where it is the lesser of evils. That is largely a visual concern, not a compile time concern.

(psychosanity) #42

I cant help but notice the SD guys are avoiding this subject completely. Anyone?

(Detoeni) #43

Anyone?

I thought SCDS_reyalP is doing quite well at laying it down in detail.

(mortis) #44

The mapping forums seems to be more or less staffed by the mappers. reyalP seems to have an inhuman amount of knowledge about the Q3 engine in general, especially as it relates to ET. Many of the mappers here probably know as much as anyone you could find anywhere.

I am no expert of Radiant, but I can tell you that for my maps done in unrealed (for Unreal Tournament), overlapping brushes can lead to issues, especially if too many subtract brushes are used. When this happens, you can get weird vertices, zfighting, the hall of mirrors effect, compile errors, brush clip errors, lighting errors and many other bugs.

In Wolfy, the negative/positive space thing is reversed, so I’m not sure whether the same issue exists at all in Radiant. Maybe the gurus here know more. A sure solution for good fps is caulk, caulk, and more caulk. Also, a zig-zag map design that only allows one portion of the map to be visible at a time (like in Fueldump, tank to bridge sequence, tall mountains block al visibility beyond the caves, curvy caves block large portions of both sides of the map, fueldump side of map is isolated by tall, caulked terrain).

Designing a map for high FPS is a lot easier than trying to clean it up later.

–Mortis

(EB) #45

This thread has worked out quite nicely, the links are a plus to the newer guys…and the elaboration on the utilities of brushwork will no doubt be of considerable help to any new mapper.

Here are some better-made test results… for the curious. (used: BSP -meta)
All faces are drawn(unless specified). I seperated tests 1,2,3,4,6 from 5 and 7 because their results were not as extreme.
While this is of little importance to advanced mappers, I figure having it as a reference, would be good

(all test compiles were done within the same skybox/skybox volume size did NOT change)
#5. I Cloned 1452 cubes and made 100% of them structural & overlapped = 2904, 256-unit cubes which were 128 units overlapped on the x and Y axes. [rows 12x11x11] times 2
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 6.3 MB (6601952 bytes)
115 seconds elapsed

#7. I Cloned 1452 cubes and made 100% of them structural and then checkerboard stacked them = 2904, 256-unit cubes which were checkerboard stacked on an ‘no block’ to ‘block’ rotation. [rows 12x11x11] times 2
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 6.2 MB (6468404 bytes)
57 seconds elapsed

The following are the residue tests;
#1. 1452 Structural 256-unit cubes which are 256 units apart on all sides [rows 12x11x11]
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 3.0 MB (3167444 bytes)
20 seconds elapsed

#2. 1452 Detail 256-unit cubes which are 256 units apart on all sides [rows 12x11x11]
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 2.6 MB (2693164 bytes)
20 seconds elapsed

#3. Cloned 1452 cubes and made 100% detail overlapped = 2904 boxes, 256-unit cubes which are 128 units overlapped on the x and Y axes. [rows 12x11x11] times 2
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 5.1 MB (5314812 bytes)
70 seconds elapsed

#4. Cloned 1452 cubes and made 50% detail and 50% structural = 2904, 256-unit cubes which are 128 units overlapped on the X and Y axes. [rows 12x11x11] times 2
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 6.1 MB (6363692 bytes)
84 seconds elapsed

#6. Cloned and made 100% detail = 2904 cubes, 256-unit cubes which were checkerboard stacked corner to corner. [rows 12x11x11] times 2
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 4.8 MB (5039356 bytes)
52 seconds elapsed

Now we have an explanation of “Sane brushwork”, the backbone of an old rule= broken and a set of tests to backup the fallacy of a ‘once true’ Rule.

Here are my Fave test results;
The structural checkerboard stacked 2904 cubes textured in Caulk:
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 1.3 MB (1411860 bytes)
9 seconds elapsed

The detaill checkerboard stacked 2904 cubes textured in Caulk:
Writing C:/Program Files/Wolfenstein - Enemy Territory/etmain/maps/boxes.bsp
Wrote 0.3 MB (269868 bytes)
4 seconds elapsed

(psychosanity) #46

.

I thought SCDS_reyalP is doing quite well at laying it down in detail

I didnt mean to imply that any of these fine and knowledgable people were not contributing. I am just curious what the people at SD thought about this, as I would certainly think that they could explain that statement in the manual more thouroughly, correct me if Im wrong.

(SCDS_reyalP) #47

Thanks EB for taking the time to do such a detailed test and write up.

All else being equal the overlapped case looks more costly. However, all else is rarely equal :moo:

One thing worth mentioning is again is that brushes which share planes are cheaper than those that do not. In the BSP, a given plane is only stored once, no matter how many brushes use it.

So checkerboard is something like this


 __
|  | 
|__|__
   |  |
   |__|

with 6 unique planes*

Overlapped (if I have understood EB description correctly) is like this:


 __
| _|_ 
|_|  |
  |__|

With 8 unique planes.

  • the above isn’t quite accurate, because coincident planes with oposing normals aren’t the same. However, if the pattern repeats, you get the same effect, but drawing it would challenge my ASCII art and counting skills. A description of how these things are stored in the .bsp file can be found here: http://graphics.stanford.edu/~kekoa/q3/

In the case of structure, the overlapped version would also result in a much more complex bsp, not due to the fact that the brushes are overlapped, but due to the fact there are a lot more unique splitting planes.

(thore) #48

(When disregarding front and backside faces / planes.)

Thanks for the link to Quakin’s samle map… quite interesting things to read.

(psyco_mario) #49

there is z-fighting in goldrush, if you look hard enough.

(psychosanity) #50

Ive found z-fighting in fueldump, too…although I have no idea what that has to do with this thread…

(EB) #51

NP…and to extend on this thread in hopes it may be used as a portal reference as well;

2904 Detail brushes-checkerboard .PRT---------- 2904 Structural brushes-checkerboard .PRT
------------------------------------

These are the only 2 pics I took… I wish I had the structural overlapping PRT pic.

(G0-Gerbil) #52

A long VIS compile only shows that your structural work and hints are could be improved a lot.

Not always true, and of course it’s relative.
EG - Minas Tirith in it’s current incarnation takes over an hour for the VIS stage. It did used to take less time but I had to up the blocksize again because VIS was so ‘inefficient’ that I couldn’t actually get it to light - my comp ran out of memory in the setuptracenodes section :slight_smile: As of now, it takes 2 1/2 hours total to compile on AMD 2400+ w/ 512 megs of ram. Which is, of course, a long time :slight_smile:

[quit]My VIS stage (and its not a -fast compile) is down to 2 mins or less for TheRiver II Redux (upcoming map) which has the same size as The River II.[/quit]
Compiling in all stages is often dependant on complexity of map regardless of how well structured it is.
Obviously, a map with more brushes will take longer to compile than a simpler one, and I must admit, this is often where the difference comes in between many customs and my own maps (if you wish to disagree that most custom maps are not in fact devoid of detail and are more than a bunch of semi-random brushes, feel free to say so :)).

On the other hand, I will agree that ‘generally’ long VIS times are down to poor structural - my old constant example is my first map, MML Footy. First time I did it, it took, well, I dunno anymore, but I think it was a couple of hours. Then I learnt about the joys of structural / detail and the whole lot came down to < 5 minutes. Yes, my very first map did NO detail brushes whatsoever :s

Oh and I second the comment about how much q3map2 has changed (IE sped up) compilations. It’s like a dream come true :slight_smile:

(kamikazee) #53

Well, this may be bumping old threads, but I 've just seen an error you can get from cloned brushes (which are in fact overlapping each other equally) placed in the same place, it looked like the detail brush itself was caulked. It was not caulked at all, the overlapping just caused the tris to be removed completely.

Deleting 1 of the two solved it here, of course.

(G0-Gerbil) #54

well yeah, but there’s a difference between overlapping brushes (= fine bearing in mind the comments above) and identically placed brush faces (= almost always bad as you discovered if they are to be textured, makes things disappear ;)).
Besides, while there’s often a reason for overlapping brushes, I can’t think of any circumstance where you’d want identical faces and BOTH textured.

I do get this ‘problem’ a lot though with early versions of maps though - I build my brushes as I intend them to be in the end, which occasionally does have identical faces (although naturally only one will ever be textured in the end). Then, I often just select all brushes and slap a texture on 'em for a temporary ‘look-see’ and voila! Disappearing faces :slight_smile: But it’s no big deal and is not how things either should be done, nor how they will ultimately end up, it’s just a stopgap solution until I texture things properly in the end (crops up a lot in FPs of Minas Tirith).

(SCDS_reyalP) #55

O_o

In general, there is no problem with overlapping textured detail brush with a structural caulk brush. If this caused a problem for you, something else was wrong.

(G0-Gerbil) #56

He’s more than likely got one of the following:

  1. More than one overlaid detail textured faces (can cause invisibility)
  2. More than one overlaid structural textured faces (can cause invisibility)*
  • As I type that I’m not even sure on it anymore, it’s been so long since I did anything like that - my brushes get changed to detail immediately these days and I only ever use caulk structural or sky…
(carnage) #57

some talk about vis compile times

might also be worth mentioning, vis is used at the light compile so good blocking vis realy reduces the lighting compile time

ah another question. when you place a brush inside a stuctrual brush it auto GCS subtracts at compile does this occour when two structural brushes overlap?

(G0-Gerbil) #58

I don’t think multiple structural brushes CSG, but then with structural brushes there’s both the ‘visual’ (should both be textured) aspect, which does get clipped, and the structural hull which if I remember correctly* has no concept of ‘overlap’ as such (although I’m pretty sure with overlapping brushes you can get the VIS data to mess up in some circumstances).

VIS compile times - a bit tricky to test. Surely even the worst mapper with everything structural in a map only has actual overlapping brushes in a few places?
IE it would only affect the tiniest bit of the time to compile surely. After all, most of the time lost in VIS is essentailly down to misunderstanding how VIS works in the first place.

  • My get out clause cos I’m probably wrong!
(]UBC[ McNite) #59

I think while u can easily work your structurals in a way that they don’t overlap, this is pretty impossible with detail. And i wouldnt worry about overlapping structurals, because any half-decent mapping with structurals has a short VIS-stage.

I read through all your posts, guys… and i think i m lost lol. Can someone do a conclusion plz? Or do we conclude so far that we didn’t really find out anything?

My 2 cts. on the overlapping brushes are: i d only care about them if they had serious impact on the game performance (FPS). I don’t really care about compile time. I have differences in teh compile time of 2-4 mins depending on whether my comp only has the compile running or whether i m chatting and doing forum posts too, so i don’t care.

(G0-Gerbil) #60

Essentially if you haven’t had problems with how you are working, don’t worry about it :slight_smile:
Some ways are more efficient and better practice, but again, don’t stress unless you have real problems.

After all, the single biggest thing people can do to improve compile times is simply to understand the difference between structural and detail - once you grasp that fact how you actually place either type of brush is not going to make any huge difference.

As to the disappearing faces talked about above, that’s entirely down to bad brush placement - overlapping brushes = not so bad, but identically placed brush FACES (with textures) can sometimes go wrong, but then you should never end up with that situation normally anyway.