Why are brushes stored as planes and not verts + tris? Was it only to on save filesize? 

with a list of planes 

On top of that, enumerating vertices and adjacency information is considerably more complex than simply giving a list of planes. And of course there's much more that can go wrong. 

Oh,so this is a case of it being the best way to represent the data then? I guess it's only easier for puny human minds to think of it I'm terms of verts and faces. :) 

From today's point of view, it certainly isn't the best way. We all know the problems associated with this data representation. But in 1996, it was a different case because in QuakeEd, brushes were mostly manipulated by manipulating their faces. I'm not even sure it had vertex manipulation at all. 

Given a list of triangles, you've got no idea whether it's even a valid brush (convex polyhedron) without doing loads of maths.

With a list of planes - by definition, the brush is simply the intersection of all the inside half-spaces. Easy peasy. 

But with modern computers, those maths should be trivial? 

...let's just say this is a question of "how should the brush be defined for the purposes of editor manipulation?", which I think is the important issue here...

Regardless of how it is stored internally, in terms of user interface, you could try to treat it like a bunch of polygons - and I think WC/Hammer did that, allowing you to pull verts around willy-nilly.

However, this is pointless IMO, because all that means is you are exposing an interface that allows the user to produce an invalid brush. Now you either have to detect and prevent those manipulations - which simply means you might as well just go with Radiant-stype manipulation in the first place, or - in the case of WC/Hammer - go "sod it, let the designer spot the invalid brushes later and fix them himself".

This was basically the reason I ditched Hammer and moved to radiant. 

That's very annoying.

But I don't think its an issue that can ever be properly eliminated just because of the amount of tools and potential upsets in Quake.

We've all seen brushes that have no reason to provoke a leak, or deform weirdly when compiled. And then rebuilding the exact same brush typically solves the issue.

I still use WC for two reasons - the texture locking and general laziness to learn another editor. 

I think it was a good choice by Carmack for reducing user error. As was stated above, a brush formed via clipping planes is, by definition, convex. It has to be - or it's empty, in which case you can discard it.

The errors we see in maps are, I believe, a result of rounding errors and precision problems but the basic idea of how he stored the brushes was actually very smart.

Where it was a poor choice was in texture alignment control. If he stored actual verts, he could have stored actual UV coordinates along with them, and then we'd have some truly beautiful looking Quake maps because you could have real UV tools and make everything perfect. And texture lock would be the default action in level editors, not a specialized feature. 

But by today's standards, it makes operations like vertex editing and rotation very complex to do correctly. It's quite a hassle because the tool chain is not prepared for the brushes that modern editors can produce, even if they are correct.

As a programmer, I have to take care that what the user sees in the editor is actually what QBSP will produce after being converted to the halfspace representation in map files.

Also, the map format has nothing to do with "user error". The user should not have to look at map files. The editing software must take care that the user can only produce correct map files, and the compilers must correctly translate the map file into the representation the engine understands. Ideally, the user should not have to worry about this. And that would be much easier to achieve if you could store vertices in the map files.

The way it is now, the complexity is shifted out of the map files into the editor and the compiler. That's not a good thing. Ideally, the map file format would make it possible for an editor to precisely store in it what the user is seeing in the editor. But since this is not possible with the map file format, the editing software must not let the user create geometry that either cannot be represented in a map file or that cannot be reproduced by the compilers. A very complicated task, I will tell you. 

Hmm, I think by user error what I meant was tool errors. If the map editor can only spit out a set of planes, then it's impossible to feed a concave brush to the QBSP compiler. That sort of idea.

The guy using the software shouldn't have to think about it, I agree. 

He usually has to because no editor completely solves this problem. They produce invalid brushes, micro leaks , drifting vertices etc.

Also the half space format in map files does still allow a number of errors such as duplicate planes, empty brushes and open brushes.

I used to be a fan of the map file format, but writing an editor has killed my love for it. I'd much rather have to deal with bugs that I can reliably fix that with precision errors that keep cropping up all over the place.

Maybe if there was a specification on how vertices are computed from planes things would be better. But all editors and compilers have their own way of doing this. 

Oh please don't get the idea that I'm defending it. I would MUCH rather have verts and UV coordinates and just get on with it. I think the MAP file format made sense to Carmack at the time since his experience with 3D stuff was fairly low at that point but it's far from ideal. 

It's like the decision to planar map everything by default. That works, yes, but it's not as great an aid to level designers as he apparently hoped. You usually end up having to touch almost every face in the map anyway... 

That's why I intend for TrenchBroom to eventually support Valve 220 maps where you can change the texture mapping in any way you like. At least TXQBSP supports this extension. 

Hrm, can someone point me to an example map or two that uses the 220 format? Would like to support this in my qbsp as well. 

e4m1rmx.map here 

That's great, thanks! 

What would be the ramifications of building an entire map out of tetrahedrons where each brush only contributed a single face to the final mesh? 

If you mean like make an organic-looking mesh in a modelling program and write a converter that spits the mesh out as a .map of tets, well...

...it would generate a gargantuan number of different bsp splitting planes that may or may not cause the the bsp algorithm to take a shit. Also, hull1 and hull2 would likely be awful leaky messes as the tets expand in funky ways. 

from experience of mucking around with this kind of thing myself: Let's say you make a cave system as a triangle mesh in a modelling app and turn it into tetrahedrons.

- The larger the tets are, the less problems you get.
- If all the vertices are grid-snapped, and the chunkier the grid, the less problems you get. I found below grid-16, things pretty much leak 100% of the time. Above that size, things leak maybe only 70% of the time. Why? Not sure but it might be something like: the chunkier the grid, then statistically (over a large mesh) the less different clipping planes there are.

I personally think there is still promise in this approach, but the solution should come via a modified .bsp compiler...

Imagine a compiler that takes a triangle mesh as input. Hull 1 and 2 are found by "pushing" this mesh in a way so the hull 1 and 2 meshes are still nice and clean. Also, without having to treat them as tetrahedron brushes, then you don't have to worry about errors caused by figuring out the unseen faces and clipping them away. By definition, you are going the .bsp compiler a contract that says "there are no faces here that need clipping away, and every face there is, should be visible and in the bsp tree", which should allow you to cut out all manner of error-prone middlemen. 

after tarting around in trenchbroom this morning, I doubt I'll ever need to do it like that.

It seems I've been getting along great with a workflow that's basically: block out an organic area with big chunky brushes (cubes and whatnot) in Radiant (currently radiant's ortho views still make that my preferred way of laying stuff out quickly and accurately), but then I can now import the rocky bits into trenchbroom - and then proceed to trenchbroom the fuck out of those rocks, and import them back into radiant. Magic. 

Let's turn trenchbroom into a verb.

"Damn, you trenchbroomed the SHIT out of that map..." 

Thanks Kinn.

I was curious about the technical problems that might result from trying to compile maps made excessively out of tetrahedrons. Sleepwalkr and I briefly discussed ways of improving trisouping and I was thinking about having the user create a single triangle and then have the editor generate the rest of the brush basing the final vertex on center of the face and normal of the face and such: https://github.com/kduske/TrenchBroom/issues/316