I can't think of an instqnce where this would be beneficial. But then again I have my own boxy style of mapping.

Why not make it an option, default on? 

So you resave multiple times to get irregular spheres?

Maybe that could be a 3dsMax style 'noise' function...

Which could also be used to instantly generate terrain - and then tweak it to fit the level requirements with the vertex tools. 

Now that I have a map that compiles properly I have noticed that the ambient sounds for the water is very loud. What gives? 

Are you using?

It shouldn't affect anything greatly, some of Bengt's stuff allowed for control over the ambient sounds from sky volumes as I recall.

Quake sounds function on visibility, more than audiable range. They're quite primitive in that respect. Maybe you don't have enough other ambient sounds? If they're drowning out weaponfire or monsters then something very weird is going on. 

to avoid confusion:

there are 2 types of ambient sounds:
- point sounds which are made with ambient_* entities and attenuate with distance centered on the entity.

the other type is area ambient sounds which are based on if specific vis leafs that contain either sky or liquid are visible to the player. in simpler terms, if the player can 'see' water, then a water sound plays, if they can 'see' sky, then a sky sound plays and this sound is full volume until you can no longer 'see' the area in question, at which point the sound just stops. 

Would still be possible as the result of anything but vertex editing. Going into vertex mode would snap the veers however. 

Honey is all on grid; The 0.125 grid. 

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.