It's the contrary, actually. The sounds function on range. Otherwise you would run around a corner and the all the ambient and monster sounds from the previous room would suddenly stop. More often than not you also hear sounds through solid walls when they really should be blocked for logic reasons. 

used slime water portal/brushes but they're real loud. At the moment I'm just using Bengt's TreeQ alongside Tyranns light/vis, once the map is done I'll be using his bsp tool too. I tried using -noambient and -noambientsky but vis recognises neither of these things and it doesn't vis quite right. 

you guys are saying that snapping vertices usually fixes most brush problems? 

Version 1.05 managed to fix the more simplistic geometry in my map that I created in version 1 that was creating the errors. It didn't work on the really crazy terrain geometry that I had made. But I have yet to retry making the terrain, I have some ideas on how best to approach the terrain but my fear is that I will be fudging around the real problem (and I could still end up creating bad shapes that you can fall through), we'll see how it goes. 

Because the more planes you have per brush, the more likely it is to get errors. 

I made a grid of cubes and then selected all of them so that I could edit multiple vertices at once. I hope this is the right method. 

Czg: is that an important distinction? Maybe if TB snapped to a 0.125 grid? 

Isn't that idTech4 resolution? 

The compilers don't give a shit because the map files only contain the planes. 

Sounds good to me. Necros? 

So it's an editor restriction?

I'm just asking because I've been dealing with 24 sided circles and curves, and there are severel limitations on what can be done with a 1x1 grid, at the scale of Quake. 

several? or severe? Take your pick. Was meant to be the latter.... 

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....