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. 

I'm trying to make an info_trap shoot towards a moving func_train to emulate randomness, but the projectile keeps flying towards the map origin instead.

The next thing I tried is using func_train_rotate... which then keeps saying "Next target is not path_rotate" when it clearly is. :(

Any halp? 

After doing some really heavy duty optimising in one of my maps it's started saying I have a leak when I compile

Using a couple different compilers points to slightly different areas of the map... I'm at a loss as to where it is! 

my shoddy brushwork created some terrible microleaks...

Which idiot was it that was saying mitre'd corners were pointless??? 

Try using a func_train_point (or if that fails a misc_teleporttrain). The info_trap aims for the origin of the targeted entity, but brush-based entities in quake treat the origin key as "displacement from initial position", hence why it's firing near to the origin. I really must write a blog post which explains this properly, it's a common source of confusion. 

Teletrain did it, thanks. 

"Which idiot was it that was saying mitre'd corners were pointless???"

Probably me. Hey, welcome to Quake mapping. Leak hunting is part of the experience.