It's an editor restriction. 

Come to think of it, I think WC allows for stuff to be off grid, so the real issue is the grid resolution in the editor because you need to use snapping to make sure that your faces are truely flat. If not then you get compiler errors when compiling your map, HOMs etc. So in theory I can create more complex brushwork in another editor and import it into WC/Hammer.

Hmmmm..... 

Vertexes are not stored in the map file. Face planes are stored in the map file.
The editor derives the vertexes and edges by intersecting the planes in a brush.

Take a look at this:
http://i.imgur.com/Uk8xH4q.png (modo)

Imagine that's a wedge brush to begin with. Ignoring the third dimension, it is defined by the planes A, B and C. Those planes are stored by storing the coordinates of three points the plane passes through. Traditionally, these three coordinates have to be integers. The two dots on each "plane" in my drawing show suitable coordinates for this. (Again, ignoring the third dimension here.)

Now if we clip that brush using the plane D, we are simply adding plane D to the brush definition. The coordinates for this plane is also easily stored using integers.
HOWEVER, one of the new vertexes that the brush gets, circled in red, is definitely NOT on grid. Its coordinates would be 2/3'ds of something.
The brush is still perfectly valid and "on grid" in a sense, even if its vertexes isn't.

SPoG wrote a really excellent document about the technicalities of the MAP/BSP format a while ago. It was hosted on PQ but then that died, so I rehosted it but then spawnpoint.org died, so now I have no clue where on might find this again.
If someone has it, please link it here because it is essential reading imho. 

As has been said, the compilers don't give a toss about whether or not brush planes/verts are in integer coords, or powers of two or anything like that.

That said, in terms of building a nice bsp tree, the less unique planes, the better. Being "on grid" generally means that more of your brush faces will share the same planes, and the bsp algorithm can build the tree in a nicer and more optimal way, minimising the number of faces that need to be split because they straddle planes, and the complexity of the bsp tree.

Of course once you start making terrain maps, planes will be all over the place whether you are "on-grid" or not, so the bsp tree will be getting all chewed up regardless. 

 

http://www.quakewiki.net/archives/spog/stuff/technical.html

Seriously go read it. Some parts of it are quake 3 specific though. 

Why don't you guys go work on that one instead? 

Sounds good to me. Necros?

You're asking about Fifth's terrain method? I would recommend triangles instead of cubes, but yeah, the essential method is the same. You build a flat mesh of stuff and then pull vertices up and down to make terrain. 

As has been said, the compilers don't give a toss about whether or not brush planes/verts are in integer coords, or powers of two or anything like that.

That is misleading. The compilers do not give a toss about vertex coordinates at all because they will recompute them (and try their best to fix any errors). And of course as far as the compiler is concerned, floating point coordinates for plane points are fine, too. But these have inherent problems in that there is always rounding involved. When the editor saves the map file, it will round the floating point coordinates and when the compiler loads the points, rounding may occur again.

So bottom line: The only way to accurately transport any brush through a map file is to use integer coordinates for plane points. Everything else will result in vertices not showing up where you saved them unless the plane points happen to be all integer.

That said, the errors introduced by floating point coordinates are usually negligable in the BSP - it will look just fine. However, it might be the source of two problems: Microleaks and wandering vertices. By the latter I mean that vertices don't have exactly the same coordinates after saving and reloading the file.

I think for TB, the best way to go is to keep the vertex editing as it is. The user already has a way to correct almost all errors. However, I intend to:

- Recompute all vertices when the user leaves vertex mode. This way, the user sees what QBSP will see.
- Let the user choose whether they want floating point or integer coordinates for plane points.
- Show warnings for brushes with off-grid vertices and floating point plane points (can be suppressed).
- Improve error handling when loading maps (auto-heal super degenerate edges and such).

I think that gives us the best of both worlds. You can use TBs vertex editing unrestricted, and the editor will show you have the geometry will actually look like in game when you leave vertex mode. Users with very old compiler tools without floating point support can also still use the editor. 

The suggestion of snapping the plane points (not verticies!) to a 0.125 makes the most sense - you won't get any rounding errors in that case. You could make it a configurable option too - 0 for no rounding at all, but place a warning on it or bury deep so only people who really know what they are doing will mess with it. 

you won't get any rounding errors in that case

No rounding errors during writing the file or reading it back, just to be clear. Obviously precision limits still apply to everything after that, but then the ball is in the compiler's court ;) 

Bad idea - that's not what I mean - you can still end up with bad surfaces, from a mathematical point of view. If you have a surface with four or more corners, then in order for that surface to be truly flat the corners have to be on the same plane. So snapping (even to a 0.125 grid) can still result in surfaces not being flat.

I just mean when I'm creating brushwork, for stuff like 24 sided circles and weird angled stuff, it would be nice to work at 1/8th of the scale I am currently limited to working at on a 1x1 grid. 

Can split a four corner face into two three corner triangular faces, I know that.... 

 

But it's only the plane-definition triangle that would have it's points snapped to grid, so it won't matter how many points there are in the face/winding ( see czg's post ). 

ricky - you can't make invalid planes just by altering the plane coords, and you won't make an invalid brush with such a tiny amount of snapping unless the brush is basically degenerate already. 

What if the snapped plane coordinate cannot be represented as a floating point number? I'm still a bit confused by floats, to be honest. Also, where did you get this idea? Does any editor do this kind of snapping? 

but surely any multiple of 0.125 within a realistic range (ie a range of values you'd find in a quake map) can be represented perfectly in floating point unless im missing somthing? 

With standard single precision, you have 23 bits of mantissa, so if you stick to 1/8 precision you will use 3 bits for the fractional coordinate and you have 20 bits left. Which means that any coordinate on the 1/8 grid will have a precise floating point representation with the coordinate range +/- 2^20 (1048576).

I'm not aware of any other editors that snap to a fractional grid, but I do remember looking at a version of radiant some time ago and seeing the code which always snapped their plane points to integers. 

Well I have an algorithm that will find quasi-optimal integer points for any given plane, but even then it doesn't work too well. I could try snapping to .125 or an even lower value and see how that goes. 

Yeah, that only says how precise the final representation can be. You may (and probably will) need extra precision for intermediate calculations. It's tricky stuff! 

The Doom3 editor supports 0.5, 0.25, and 0.125 grids. 

I can add that to TB in a jiffy, but the major problem right now is how to represent the planes with maximum precision across file saves. 

One option, and you probably don't want to do this, is to go the Worldcraft route. Store maps in your own format and export to MAP for compilation. That would retain perfect precision at all times and only need to snap once, eliminating drift. 

Of course, but it does show that even id ( and JC ) are fine with that kind of granularity.

And as others have stated already, certain fractional steps ( 0.5, 0.25, 0.125, 0.0625 ... ) should not cause rounding errors - as long as the absolute value "in front of the dot" is not too large.

This page is pretty handy to see whats going on : http://www.h-schmidt.net/FloatConverter/