don't really know what the eye position is, or if it does anything.

the 'bottom' of the monster is determined by the bounding box set in the QC.

This is -24z for all monsters (unless you are playing around with non-standard bounding boxes)

As long as the bounding box is set normally like it is for small and large monsters, then any vertex on the model that is 24 units below the origin of the model will be on the ground. 

Yes, that was it - looks like a typo in QC as the z was -34. Thanks. 

Has anyone come across a texture set that even remotely evokes the Australian bush or outback? 

I think I saw it converted somewhere. 

Is there any guides on how to setup GTKradiant for quakeworld? which version should I use? 1.4, 1.5 or 1.6? 

http://kneedeepinthedoomed.wordpress.com/tutorials/ 

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!