At least in the case of BJP's tools, qbsp will always choose the face of the newer brush, the one that is further down the list in the .map file. 

even though qbsp doesn't have a problem with it

seriously, I remember reading an article about how the technology was devised which had diagrams showing how qbsp can take overlapped rough-shaped brushes and subtract everything outside of the inside space. It was what it was designed for! You can get some really neat effects by overlapping brushes, especially with things like rock work.

Things to watch out for which ARE important:

1 - illegally shaped brushes. No concave brushes please.

2 - corners of brushes being off-grid.

I have discovered that you can have overlap points off grid, qbsp completely re-models the brushwork anyway into wireframe. But having corners of brushes off-grid is a real no-no. Likely to lead to leaks, holes in the clipping hulls, homs etc. 

Anything of grid is a no-no. Basically because qsbp snaps them to grid, which might not be where you were expecting. If you've got a load of stuff like that that's intersecting then you get a mess of unnecessary (and probably invisible) polys, holes in between structures and so on.

The grid is 2x2 though, and you can always spawn in models with a scrap of code for detailed stuff. Not many people realise / use bsp model spawning - which is the mutts nutts for rotating detailed stuff. 

I've made a part of a map that was perfectly playable in normal skill, the skill I test on because I'm a lazy bastard, but can't be done at all on Nightmare, the skill I always play on.
The Shamblers reload too fast for the player to have any chance of getting past them. Does anyone know where I can find the exact difference in skill settings ? 

"There is nothing wrong with overlapping brushes. Infact overlapping brushes is what the technology was made for. DO overlap brushes!!!"

Yeah, I wish this myth would go away but it persists for whatever reason. Overlapping brushes are totally fine and completely acceptable. QBSP will cull away the unseen portions.

"Having 2 faces at the same place on the same plane isnt a good idea because you have no controll as to which face qbsp will choose."

Untrue. It will pick the one that appears last in the MAP file. You can control this simply by cutting/pasting the brush that you want to appear last in the map editor. That moves it to the end of the brush list - unless your editor is doing something where it writes out the brushes in an arbitrary order. In that case, it's a failing of the editor rather than Quake/QBSP itself. 

I've found a new way on how to get by them.
Funny how your own maps can bring out the creative player in you, I guess that's why I love Quake so much. 

Enemies fire faster on Nightmare, that's the main difference you cannot influence. The rest is item spawnflags to make them not appear.. 

Or die!!! 

Anything of grid is a no-no. Basically because qsbp snaps them to grid, which might not be where you were expecting. If you've got a load of stuff like that that's intersecting then you get a mess of unnecessary (and probably invisible) polys, holes in between structures and so on

this. like i say, even if it compiles without a hitch most of the time, having loads of off-grid overlap points still leaves your map more susceptible to random leaks & the like, as well as being not very nice to build stuff on (say if you wanted to cut a cave out of the rockface, or build some architecture into it later on).

but hey, personal preference. i used to do it all the time but have much prefered working with natural terrain stuff since i stopped doing it. much prefer using triangular faces now 

you should never need to test nightmare or find a way of making it easier, it's supposed to be fucking hard :P 

not only should stuff be "on grid" meaning on the 1x1 grid, you should also build stuff so that it fits on the higher grid levels when possible. So if you have a 32-unit-thick wall, try to align it to the 32x32 grid. If you add an 8-unit-wide railing, try to align it to the 8x8 grid.

As for overlapping brushes, this is fine BUT the thing to avoid is having things overlap slightly, when they could just touch perfectly. So if you have two brushes side-by-side, don't just put them so they overlap by 3-5 pixels, make the edges actually line up flush. This is mainly for the same reason as the previous paragraph about aligning to the largest grid size possible. 

What is that information on grid alignment based on? Is that a gut feel thing, or is there a technical foundation behind it?

I'm not challenging you, but I've heard a lot of level design advice over the years that is basically couched in "this is the way I learned to do it". Well, great, but if there's no QBSP related reason to do it... :) 

Mostly gut feel, based on what i've seen, what i know about qbsp, and what i've absorbed from others. I think you are correct to challenge this advice as perhaps more "mapper lore" than solid fact.

Scientifically, i would have to make an entire map the "messy" way and compare it to a "clean" map to have any evidence that it mattered.

But, since brush faces determine BSP planes, it seems plausible that it would make a cleaner BSP if there were fewer unique planes and more nodes that cut along the same planes.

I can say from experience that maps with more orthogonal brushwork compile faster than maps with many angled planes, since i've done both of those types. And i see more (seemingly) extraneous face cuts in areas of maps that have a lot of non-orthogonal brushfaces.

I can also say from experience that when two nearby brushfaces are parallel but not coplanar, it is more likely to create additional cuts on nearby faces. (presumably because if they are coplanar there can only be one cut on nearby faces since there is only one plane.)

Qbsp does do a decent job of merging neighboring faces when it can, this mitigates the problem in terms of raw poly count, but i believe the extra bsp complexity is still there.

More facts on this topic would be useful. On the other hand, I have heard that even John Carmack has been suprised to hear certain results (such as the reported finding that 64-unit walls produced better vis than 32-unit walls.) [citation needed]

In terms of "advice to a newbie" i still feel better advising 'clean' brushwork, since it is proven successful, rather than 'messy' brushwork, which might be harmless but i don't think has the same track record. 

I spent about 1 week making a small test map in ut2k3, for a job application. I built everything the quake way, all clean and lined up on a grid and flush with each other (though of course i used the subtractive brushes to make the initial rooms and some of the smaller alcoves.)

... and had all sorts of headaches with compile errors, geometry errors, etc!

Then i opened up one of the ut2k3 maps in the editor to see how they did it. What i found was: 1. there were only about 15 brushes in the entire map (rest was static mesh), 2. all the brushes were subtractive, 3. and they were all random sized, non powers of 2, off-grid, and slightly overlapping! And of course it compiled perfectly.

I ended up getting a job on a Q3-engine game instead, so it all worked out in the end. :) 

Haha, yeah, we rarely use BSP for anything these days other than floors and the occasional wall. Everything else is meshes. 

really like the term "mapper lore". 

n 

I finished a map two years ago. It was broken and ruined with brushes used on all gridsizes.
When I realized I could never get a clean bsp, as the map started leaking and homming like a rascal, I decided to start again.

I compiled everything clean on grid. It was a repetive thing to me, but to my surprise the map rounded out good.

Then I decided to add a terrain map, which was a construction of triangle brushes ending up in sloped edges. Apart the map compiled well.
When I added the terrainmap I had to realign all brushes to fit them on grid.
And this broke up all my smooth pathway, but it worked. 

It's just good practice to keep stuff neat and orderly. 

please 

but now my smooth terrainmap only imports on rougher brushes by marking all on grid. Or I could ignore warnings.

Ricky.., you played the map. More or less..,
https://homedrive.ziggo.nl/gimli@home.nl/publiek/gimli30.htm

Is there something to do about model skins that keep get mirrored?
I broke an evening to get me a good baseframe,
and now it keeps removing front with backparts. 

http://members.home.nl/gimli/gimli30.htm 

Is this really a MadFox map?! Looks neat.
Though I suggest you change the texture on the railings to something without rivets, a simple brown or gray metal. 

Looks great, MadFox ! 

Railings are dxf files which have no shadows, same as the hillslopes. This makes lighting a little tricky seeing the clear dxf file near a brush. Could have another texture but the hexen2 wad is rather bloomish.

My concern is that the middle low pix is a sloped pathcorner around. In the testmap the pathcorner was well closed, while in this map it suddenly shook all brushes in it.

I had to use "force to grid" for all and now it has more of a stairway. But I wanted to make a map once whith all brushes integer.

When two maps with both integer brushes is put together, is the need to replace the imported brushes back into integer origins normal?