how problematic is it or no problem at all?
intersection of detail brushes with structural brushes
You should try your best not to intersect brushes as there is no reason that it can’t be made that way.
That said, as long as no faces try to exist on the same plane(s) then the only problems are overdraw and potential lighting issues. Might I ask what you are trying to overlap? If it’s terrain, it’s quite common to let some terrain overlap other brushes here and there. However, in ET the terrain code has been revamped so you can now cut the terrain back to fit the brushes exactly without too much trouble (but don’t quote that as gospel)
He didnt say he was intending to overlap anything. He asked if it was ok if a detail edge shared the same edge as a structural brush… and the answer is, yes it is ok. It doesnt matter.
::points to initial topic::
psst…he asked about intersection, not sharing edges.
Well what exactly is the intersection? An intersection of edges, planes or brush volumes? It all depends on how each person interprets it. The topic is unclear and therefore is getting crap answers.
There is NOTHING, i repeat NOTHING, wrong with intersecting brushes.
There are problems that CAN be caused by doing this, but that is by no means a reason not to do it.
Was gonna say - creating an entire map without any intersecting brushes would give me nightmares… 
Coplanar textured faces, now THAT’s something you should avoid 
This largely depends on the system being used. I have 2 computers, one high end and one low grade. On the high end one you can violate as many brush rules you want (merging brushes, tweaking vertices etc.) you want notice anything, everything draws out fine.
On my crappier computer you notice everything. And I do mean everything. I can see the edges of brushes even when they don’t touch each other and are properly aligned. If brushes are touching I get big shmeers and all kinds of Z-buffer problems. I notice problems with edges not touching and faces dissapearing (caused by edge or vertex dragging and arbitrary rotation). Basically on my crummy pc I notice every flaw of the map. By crummy I mean 800MHz PIII, 64 MB GeForce4 MX440, 394MB ram.
I could show you screenshots of this but I’m too lazy right now.
Anyway try to avoid irregular transformations and overlapping (occupying the same physical space) brushes because they DO MATTER.
Plus brush overlapping reduces performance because volumes have to be computed twice.
That is totally incorrect.
Z-Fighting CAN be caused by overlapping brushes, but overlapping brushes do not automatically cause Z-Fighting. In some circumstances, overlapping brushes can actually be more helpful, as it can reduce the number of unique planes and/or bevel planes.
If there are problems being causes by overlapping brushes, but they are only VISIBLE on a lower spec machine, then you have a problem with the map, and this has nothing to do with the machine. Problems caused by overlapping brushes are simply due to people, not constructing things properly, NOT that overlapping brushes themselves is a problem.
Overlapping brushes do not cause “volumes to be calculated twice”, nor will they cause performance hits, at least, not inherantly.
Z fightingcan occur on non-intersecting brushes too - it’s really down to making sure you don’t have 2 brush faces too close together, regardless of proper overlap / intersection / whatever. Have to agree with djbob, overlap isn’t in itself evil, it’s just if it’s done badly.
As for it showing up on your poor system, that’s undoubtedly simply the difference between a 16bit z buffer and a 24/32 bit one. A good reason why mappers should test their maps on 16bit ones and tweak accordingly.
As indeed didn’t appear to happen in the official RTCW maps 
what exactly is totally incorrect. The fact that when I overlap brushes
I see all kinds of problems on my computer? That’s not incorrect… that’s a
fact. You know a lot more about this than me and you might be completely right when you say that this is not caused from the brush overlap. I don’t know and frankly I don’t care. The truth of the matter is:
State 0: brushes intersecting --> all kinds of problems, map looks like shit.
State 1: brushes not intersecting —> no problems, map looks fine.
That’s reason enough for me to try and avoid intersection of brushes and say that brush overlapping might cause problems. I never said you should never do it because i can’t imagine how you could get around certain things, or that you’ll definitely get a problem if you do it, all I’m saying is if you can get the same design without overlapping any brushes, than spend the extra time and do it because it CAN cause problems. I think a lot of people on this forum work on very high end machines and they forget that there are still a lot of PIIIs out there, so just because something looks good on your computer, doesn’t mean it’s gonna look the same on everybody else’s. That’s why I said that I usually test everything on my PIII as well to make sure everything will look fine for everyone.
By the way, the following quote is from the radiant manual the section that talks about working with brushes:
““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””"
I don’t know if this is still true, it might not be. I just wanna make sure people don’t think I just made this stuff up.
The manual is wrong. It should have been updated long ago. Ydnar and djbob have been mucking about in the tool and engine source for a long time, and I would suggest they know what they are talking about in this case. They are largely responsible for a mapping technique which relies extensively on overlapping brushes.
If you see artifacts from overlapping brushes, it is most likely because the overlapping (or intersecting) faces are textured, resulting in z-fighting. that is incorrect construction on your part. It has little to do with the fact that they are overlapping. Any time you have faces rendered closer together than the precision of the z-buffer, you get z-fighting. This effect is much more visible in 16 bit modes, because those usually come with a 16 bit z-buffer as well. It has nothing to do with low or high end machines, except that users of low end machines usually select 16 bit color. This also varies between cards. Some will give you a 16 bit z-buffer even with a 24 bit color buffer.
Your blanket statement that brushes should never overlap is flat out wrong.
Well that clears it out for me. I think there’s a lot of confusion because there is so much stuff out there about the quake III engine and I guess a lot of it is outdated. In any event thanks for clearing it out.
By the way, the following quote is from the radiant manual the section that talks about working with brushes:
""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
I just have to chime in here…overlapping brushes arent the same as intersecting brushes. Overlapping brushes are what cause Z-fighting, like when you have 3 copies of the same brush right on top of each other…intersecting would if you used the auto hollow out command on a brush, or made a cross with only 2 brushes.
Both of these conditions can cause z-fighting, because at the corner of the intersecting brushes, the faces get arbitrarily close. If you play ET in 16 bit mode, you can see this all over the place on the official maps. You can also get z-fighting with non-intersecting, non-overlapping brushwork.
Note that in either case, it is only an issue when when more than one of the faces in question has a drawing texture on it. If the face is non-drawing (like caulk or nodraw) then of course z-fighting in game is not an issue. You will see it in the editor, but aside from giving you a headache, it is not a problem.
