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/ 

If you limit the plane point coordinate precision, you will be unable to snap vertices to the grid in certain situations. 

It will eliminate drift, yes, but it leaves the problem of finding good representations of your brushes when exporting the map file. You must remember that TB will also support games like Hexen 2, where floating point compatible compilers are not available. I think it's better that the user actually sees what the geometry will look like to the compiler. 

But it would mean you don't have to use integers, but could use certain fractions of floats for your drift-free plane definitions - which could mean more accuracy to what the user intends - or am i seeing this wrong ? 

Sorry if I sound like an idiot for asking, but if a brush is just a collection of planes at a certain vector how can they even become degenerate? Convexity?