TB doesn't simply round the plane points. Instead it will find integer plane points that represent the original plane as closely as possible. However, some planes cannot be represented with integer plane points at all, e.g. a plane whose normal is the Z axis, but which is offset by 0.5.

To answer your question, since the result of the plane point finding algorithm can differ from the original plane, your vertices can change. However, TB will take this into account as the algorithm is applied whenever you perform a vertex operation. So what you see in the editor is what the compiler will produce also. I would say that this is what you want in most cases.

As I said earlier, if you know what you're doing, you can get away with using FP plane points, but you will likely run into microleaks sooner or later.

TB2 disallows floating point plane points altogether for now. If there is demand, I will bring back the option to use them, but it will be off by default. In any case, the editor will warn you about floating point plane points, and you will be able to auto-correct them using said algorithm in one fell swoop.

As for writing vertices to the map file: I think this should be possible, but the vertices would have to be stored in HEX format, which can be stored in text files and read back without loss of precision.

But I think that using integer plane points is the better option, because it retains compatibility with all compilers out there. TB2 can be used to map for other games, where such compilers will surely be unavailable. 

When I'm working on a map, I never continue if there are any errors or leaks in the BSP process. I will either fix the problem or revert to a previous version of the map.

I keep my maps in a separate folder from where the compilers are. I copy the map to the compiler folder and then run BSP, Light and VIS from a batch file. After that process completes, I rename the map copy as Name (what the major changes were).map, and continue work on the original file.

While working on Wish13 I have been including the marksurfaces count in the renamed map file just to keep track. I also try to work on either brushes or entities and textures only in a single session. Too many times I've lost a lot of lighting and texture changes because I also changed some brushes and then had the marksurfaces count go insane. 

Enhanced Texture Positioning. 

Hah, that Doom3 story is great ... so they created a problem and then patched the tools to compensate for it. I wonder what they were trying to fix in the first place.

Honestly I don't really know what they were trying to accomplish by changing the way that brush planes are stored. The only benefit is a smaller filesize (it's only 4 floats to store a plane in the (normal,distance) format vs. 9 floats in the (pointA,pointB,pointC) format).

But was map filesize really such an issue that it was worth having such nasty side-effects?

One of the Doom3 community guys (it might have been Sikkpin) got so pissed off with this, that he modified DoomRadiant to use the old quake brush format (it was an almost trivial change apparently) and all the problems just went away.

To late for me though, I've long since lost interest in D3. 

What does that mean? 

Its a term used in relation with the valve 220 (Hammer) file format i think.
You can shear textures with this for example.
Some of the light compilers support it by -etp switch. 

 

450 warnings? 

I thought I'd mention that the Quake compiler actually works internally with those Doom 3 style plane definitions - it calculates a normal and distance from the 3 points when it's computing the BSP. So maybe the thinking was to make the map format more closely match what the compiler sees. I think I'd agree with Kinn that it's not a wise move though. The Quake compiler also has limited healing - when it creates a "new" plane it tries to match it to an existing one, and it will merge a pair of planes that are "close enough" in angle and position. 

Incidentally, merging of planes offers one (of many) possible explanations as to why adding or removing brushes can affect remote parts of a map. Suppose a brush on the left of the map has a plane which is "equal enough" to that of a brush on the right hand half. Whether left is merged into right or right into left now depends on which brush compiles first! And if you delete the former, then the latter slightly changes.

I understood that one of the useful properties of BSP trees was that it was easy to merge two together. Does this mean that we could make a compiler that builds a bunch of rooms independently, then merges them together? Obviously there's not just a technical issue of whether such a thing could be written, but also a practical question of how to tell the compiler which brushes are part of different rooms. But it would certainly deal with some of the weirder cross-map interference issues. I wonder if the detail brush code could be a launching point... 

Yeah, with Quake, you always lose a bit of accuracy at the compiler stage when it turns those 3 points into a normal,distance - but it's a one shot deal and what you lose is negligable and usually harmless.

In Doom3, those inaccuracies just keep piling on top of each other just by doing routine brush manipulation in the editor, until that time when you zoom in to raise a decal off the floor by 0.125, and all those cracks and misalignments stare back at you like a British smile. 

I totally agree it's a change for the worse in the .map format. It was just a really good opportunity to explain that aspect of the compiler - the merging of similar looking planes isn't well known - once you'd done the groundwork of explaining the format for us! 

The D3 problem is worse the further you are from the map origin - and also worse if the geometry is grouped under an entity (as it involves an extra calculation to offset the brush local coords from the entity coords) 

I suppose this planemerging creates leaks in hull 1?
Instead of having visible gaps between brushes (hull 0 leak)? 

I always assumed .map stored verticies

SleepwalkrR: this doc explains Quark ETP:
http://quark.sourceforge.net/infobase/src.topics.face.html 

On the contrary, the planemerging fixes leaks! At least that's the intent, it's meant to merge two adjacent brushes where some kind of rounding error occurs*. Of course, it can sometimes cause more problems that it solves if it starts affecting brushes further afield. I'd have thought it would affect hull 0 primarily; if there's no leak in hull 0 then the expansion of the brushes for the other hulls should overwhelm any chance plane merging has of creating a leak there.

* Rounding error is a constant worry, even with the best case integer coordinates. Imagine two adjacent brushes formed from a diagonal cut along a single brush. The editor has even been so good as to make sure the touching faces are defined by the same three integer-snapped points. Even so, because the two faces point in opposite directions, the order that these points are listed is reversed. This is enough to produce slightly different floating point plane values some of the time. 

Here are 3 brushes, all the same size and in the exact same space.

{
"classname" "worldspawn"
"wad" "quake101.wad"
{
//"0000" "0"
( 128 0 0 ) ( 128 1 0 ) ( 128 0 1 ) COMP1_3 0 0 0 1.0 1.0
( 0 384 0 ) ( 1 384 0 ) ( 0 384 1 ) COMP1_4 0 0 0 1.0 1.0
( 256 0 0 ) ( 256 0 1 ) ( 256 1 0 ) COMP1_5 0 0 0 1.0 1.0
( 0 128 0 ) ( 0 128 1 ) ( 1 128 0 ) COMP1_6 0 0 0 1.0 1.0
( 0 0 128 ) ( 0 1 128 ) ( 1 0 128 ) AFLOOR1_8 0 0 0 1.0 1.0
( 0 0 64 ) ( 1 0 64 ) ( 0 1 64 ) CEILING1_3 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 128 256 128 ) ( 128 128 128 ) ( 128 128 96 ) COMP1_3 0 0 0 1.0 1.0
( 256 384 128 ) ( 128 384 128 ) ( 128 384 96 ) COMP1_4 0 0 0 1.0 1.0
( 256 128 128 ) ( 256 256 128 ) ( 256 256 96 ) COMP1_5 0 0 0 1.0 1.0
( 128 128 128 ) ( 256 128 128 ) ( 256 128 96 ) COMP1_6 0 0 0 1.0 1.0
( 128 128 128 ) ( 128 256 128 ) ( 256 256 128 ) AFLOOR1_3 0 0 0 1.0 1.0
( 256 256 64 ) ( 128 256 64 ) ( 128 128 64 ) CEILING5 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 128 160 128 ) ( 128 128 128 ) ( 128 128 64 ) COMP1_3 0 0 0 1.0 1.0
( 272 384 128 ) ( 144 384 128 ) ( 144 384 64 ) COMP1_4 0 0 0 1.0 1.0
( 256 128 128 ) ( 256 160 128 ) ( 256 160 64 ) COMP1_5 0 0 0 1.0 1.0
( 128 128 128 ) ( 256 128 128 ) ( 256 128 64 ) COMP1_6 0 0 0 1.0 1.0
( 128 128 128 ) ( 128 160 128 ) ( 256 160 128 ) AFLOOR3_1 0 0 0 1.0 1.0
( 256 160 64 ) ( 128 160 64 ) ( 128 128 64 ) CEILING4 0 0 0 1.0 1.0
}
}
{
//"0000"
"angle" "270"
"classname" "info_player_start"
"origin" "192 256 192"
}

My point, eh I don't got one yet. 

is there a sound-emitting texture manifested in Rubicon2s progs.dat?

I�ve got an annoying watersplashsound all over my map, and i�m using the animated waterfall texture.

This drives me mad, maybe fullvis gets rid of this? 

On your vis command line:


-noambientsky
Disable ambient sound generation for textures with names begin-
ning with 'SKY'.

-noambientwater
Disable ambient sound generation for textures with names begin-
ning with '*WATER' or '*04WATER'.

-noambientslime
Disable ambient sound generation for textures with names begin-
ning with '*SLIME'.

-noambientlava
Disable ambient sound generation for textures with names begin-
ning with '*LAVA'.

-noambient
Disable all ambient sound generation.
 

Or do i have to set up triggers for them instead then? 

that is quite nice. I'm sure some mods have support for external sounds, maybe quoth? 

Those only affect sounds added automatically by the vis process, produced by textures.

All your ambient_whatever entities will still work fine.

We already have several custom sound ents; this is for the RRP project.

You can use the ambient_general for a looping ambient sound, the only restriction being that it needs to have 'loop' data setup.

the fx_sound is for single shot sounds, although it also has replay capability. 

Thanks Ijed! 

there shouldn't be any automatically generated sound from the waterfall. Aside from the vis.exe-generated ambient sounds, there are of course mapper-placed ambients.

The only special rubicon2 code in this regard is, there is an underwater loop that plays whenever the player is underwater. If you are not underwater you should not hear it. (There is also a loop for when you are on fire.) 

I got it fixed with the -noambient switches, ambient_general "survives" this. Still curious where it came from then.
It was one of the curnt.wavs, i�m sure.
Ijed?