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. 

instead?

Surely this couldn't be broken. And having minus 1 unit isnt so bad. 

but what if you actually WANT the lip to be -1? 

You can add little brush for door in invisible zone (e.g. inside wall) and use neg. lip

http://s020.radikal.ru/i705/1406/8a/96603f4c1327.jpg 

Another way to do this is place the door on the position you want it to be when open (flush with frame). Set spawnflag "start open". Make the door 8 longer (or whatever the lip is) on the side that would be hidden in the frame and leave lip at default.

bam. kinda clunky, but it won't break. May wanna add a a trigger, depending on the situation. 

Just tested it. When I thought of it I pictured the default trigger to be hidden behind the wall for some reason, that's not the case it seems. Works fine, no extra trigger needed.

-0 doesn't work for me btw. 

Lighting the door properly would be a problem... lol, disregard everything i said. 

I've not tested this either, but if you tried it and it didn't work, it could be the result of your compiler or your map editor "correcting" a -0 to a 0. Checking the entities in the BSP file might be necessary to verify if this works.

There are other ways this could be fixed from a QC perspective. The first way would be to acknowledge that 0 is a valid value for lip and not apply a default to it - but obviously that's not backwards compatible. It is still a thing to consider for new entity classes.

The other thing to do would be to add a new spawnflag to the entity called NO_LIP, which would override the default (or any other value set) and make the lip zero. This would preserve backwards compatibility for doors. It might also be a useful pattern for some new entities, if zero is a permissible but rarely applicable value for the field, and the default value is much more sensible.