Surely this would be testable ny making a vertical map 

Nope. It's something I got from early Q2 mapping and assumed was the same for all.

Maybe I should do a test map before each post. 

It almost reads like mapping lore they gets passed along and nobody ever really understands or questions it.

Like, I have friends who make Quake maps who clip and miter every brush so that nothing ever overlaps. Ever. Totally clean construction. I've tried to explain they are wasting their time and QBSP takes cares of all that but they will hear none of it! "It makes for cleaner and better performing maps", they say. I say it makes for a lot of wasted time that could be spent more productively... 

Mitering convex corners is optimal. 

In what sense? I mean, if you're slamming up against engine limitations, sure, go for it but otherwise ... What's the point? 

It still comes out a more efficient map to run, however negligible the gains might be.

A few weeks ago I went through my map to try to get some vertexes back, as I'm nearing the limits of bsp29. I mitered most convex corners and got about 2k verts back from that alone.

I also fixed a lot of my early brushwork, it was really shoddy. brushes in brushes in brushes in bushes, all sorts of random shit of all sizes, off the grid even, all in one big mass of noob mapping.

After going through and optimizing the map, I had about 6k back and shaved 30 minutes off the compile time.

I can't explain it, those were my results. 

You better miter those brushes damnit!!

I'm partway through making a vert map right now with a door in every ceiling (it's a 768 map), I just tested this theory using r_showtris 1 and it doesn't appear to be true, it's definitely not drawing every single floor. 

Prepare for a possibly dumb contribution to the visibility discussion, but FWIW, what I remember from Q3 mapping was along these lines (it would be easier to do this with pictures but oh well):

Let's say you have a big cube of open space. A vertical wall divides the cube into two halves, but the wall is only half as tall as the cube. So you essentially have two rooms sharing an open space overhead.

The visibility here depends on how the compiler chooses to subdivide the space.

If it first cuts horizontally along the top of the divider wall, then the nodes for the space of each "room" will end up being only as tall as the divider wall, and they can't see each other.

However if the compiler first cuts vertically up the side of the divider wall, then there is going to be a tall node on that side of the wall, that goes all the way to the ceiling of the cube. In this case the nodes on each side of the wall can see each other.

The solution in Q3 was to have a horizontal hint brush face dividing the cube at the level of the top of the divider wall. So even if the compiler chose to chop vertically along the wall face first, the cut and therefore the room node would stop at the hint face.

If I'm misremembering/misunderstanding, or if the Q1 visibility issues are different, please clue me in... 

That's a really clear explanation. 

In that example, the compiler is going to prefer cutting up the side of the divider, without being given a hint. Every plane in the map is ordered based on preference for splitting. Vertical planes are higher priority than horizontal ones, and axial planes are higher priority than slanty ones. The map is assumed to be architectural in nature, so this assumption makes the compiler more likely to catch doorways or subdivide large spaces in a way that respects the layout. I think that's what we're really talking about.


This is why outdoor bits with lots of rocks tend to go kaleidoscopic, the compiler doesn't have a lot of vertical axial faces to go on so it digs deeper and starts using the sides of your wacky boulders to slice the space up. 

qbsp will usually clobber any fancy brush mitering you've done anyway.

i remember the doom3 compiler being really amazing about mitering things. i don't remember ever seeing it cut a wall up in anything but the best way.

quake bsp compilers aren't that good and rarely make the right cuts. to be fair, they are working under more stringent limitations (such as max face size) than doom3. 

you can FORCE qbsp to honour your face divisions by offsetting textures by 1 unit (because then the compiler must consider them as a separate face) but you're just giving the compiler less leeway to work with and it'll probably perform even worse.
i find it's better to keep your brushwork clean enough so you can work well but to not fuss overmuch with what the compiler is doing. 

Isn't Q1BSP more of a software era thing? Cutting things into small triangles to minimize overdraw. Iirc the software renderer only uses z-buffer reads for models and the world bsp is rasterized front to back? D3 doesn't have those limitations and does a fair bit of culling at runtime afaik. 

IIRC the old QBSP used to or at least had a tendency to produce weird results on overlapping brushes or multi-face walls even if they were all on the same plane with the same texture and offset. This is why "clean" brushwork was propagated. Another well-known example apart from mitered corners is that technique where the brushes on arches are turned into triangles that meet in the upper corners.

Newer compilers take better care of such cases, although their results can still be arbritary at times. I found that occasionally "sloppy" constructions caused better splitting than "clean" brushwork for whatever reason. 

Newer compilers can combine faces, while older ones only split them. Doom3 doesn't need you to do any mitering because any extra cuts in a continuous surface that are introduced by the brushwork are optimized away again.


Doom3 also doesn't do any previs calculations, instead relying entirely on designer-placed portal surfaces that it tests for overlap in screen space in real time. (you can turn on r_showportals or something and see them turn red and green as you run around.) This is much simpler, and completely avoids any wacky how-is-qbsp-hacking-my-rooms-apart trouble, but also means you can't build any kind of large or interesting space that can't have its visibility constrained by little doorways. Yada yada yada and you get Doom3's level design.

This room was a bitch:

http://matthewbreit.com/images/q4dm11/1.jpg

That big solid platform in the middle blocks the view of doorways on either side of it from each other, but because those portals overlap in screen space they were always considered open. The proper solution is to have some kind of occluder or antiportal inside the platform, which doom3/quake4 didn't have, so we had to - surprise - cut the room apart in wacky ways with huge portals instead. 

wow, that looks really pretty. 

And assumed there was some stuff I was missing because of handling cases as described above. The reality seems rather depressing :) 

but only for special cases like that. i found that usually it was a very easy system to use. 

Was it similar to how mapping in Unreal Tournament was by putting a non solid plane in doorways to make each room its own portal? 

sounds very similar.
in d3, you make a brush with a non-solid texture on all but one face. on the last face, you put the portal texture and that becomes the portal. 

in a map.

So I made a test map just to see if it works, it works fine. so I copy and pasted the whole set up into my actual map and now the lightning no longer fires at the target... anyone have a clue what the hell is going on?? 

If you're using the Chthon lightning entities, you should know that they're a bit hacky, and you can only have one beam of lightning on the go in a map. Might it be that in your copy-pasting you created two overlapping endpoints, and so the lightning beam is zero-length? 

I'm using quoth...

I re-did it all again several times and on the 4th time it now works again. 

I want a door with lip 0.
Setting it up causes it to reset to default(lip 8). So after a while i found that lip of -0 is doing the trick, i have a door with no lip.
Tadaa!
Is this in any way bad? For gamelogic or sth? 

From a technical POV that is cool. It has always been a little problem in QC that you can't distinguish between a key that hasn't been set, and one that's been set to zero. It would be nice to make the convention that -0 means "explicit zero". I don't think there's anything immediately bad with it while it works. What I do worry is that something might break it somewhere - I can imagine two ways:

1) An altered QC compiler might just be able to add a bug-fix everywhere for this surprising behaviour, and end up cancelling out the feature.

2) A new engine also might notice buggy behaviour relating to this and patch it out.

In both cases you'd end up back with 8 unit lip. The question is whether anything breaks it already, and if not, whether it's compelling enough as a feature to become a de facto standard, so engines that deviate are considered buggy instead.