I tried it in a much earlier version and found it very restrictive. Didn't mean to crap on your editor!

The drifting is that the decimal values appeared over most of the rotated crates I've got, and the alignment has gradually shifted as I duplicated them around the level. It's probably you've already fixed this, since I've been building this map for quite a few months now.

I actually have a few test maps to send you on the bug tracker, a hard crash and the texture drifting issue. Probably of academic interest only, since I think these should both be corrected with Trenchbroom2, from what you've mentioned of it.

I'll try and get those maps to you next week in any case, give me a nudge if I forget / am too slow. 

Thank you! 

.. TB suffers from the same floating coordinate issue QuArK has... 

everything will be fine if you check the damn "force integer plane points" option in the map properties.

TB offers you the freedom of using FP face coords, but it should only be used by someone who absolutely knows what they are doing. Which is why it should have been disabled by default :-( 

But inaccurate or floating vertices have plagued every single game editor I have ever used. Back when I was mapping for Unreal Tournament I noticed if you have too many vertices occupy the same area in the grid then the grid snapping stopped working and they acted like 2 magnets with the same polarity.

It also depends on which compiler you use too, I find BJP's TreeQ tool to be the best compiler since any microleaks tend to be fixed due to it only allowing vertices to 2 decimal places. At least I think that is how it works. Plus the pointfile it writes if you do get a leak works well.

http://user.tninet.se/~xir870k/ 

the problem aren�t values like 34.348827.
Thats most like an editing error made by the mapper.
More annoying are values like 256.00187.
Which occured to me when for example aligning textures on that a brush in Quark or Radiant with ETP enabled.
Snapping the vertices back on grid again garbles the texture alignment :( 

You mean when you snap vertices to the grid in TB the texture alignment somehow becomes corrupted? 

This is nothing compared to the hilarity of the Doom3 .map format's floating point issues.

For some reason in D3, id made the "genius move" of storing brush planes in the map file in the (distance, normal) format, so any plane that's not orthogonal (i.e. doesn't have a unit vector normal) is going to be stored with a certain amount of inaccuracy. Simple operations such as moving brushes around in the editor result in degradation of your plane equations and everything ultimately ends up off grid by a tiny amount.

I also believe planes drift every time you load a map into the editor, so your map slowly decays over time, like that badger carcass in the grass verge that the kids can't stop poking at.

The doom3 compiler however welds nearby vertices, so your cracked, leaky maps actually just seal themselves and it rarely causes an issue (or is noticeable) in the final map.

It does, however, make absolute mincemeat of your OCD, and is one of the reasons I just couldn't face D3 mapping any more. 

vertices would be whole numbers only in most instances? I can understand that if you clip across a face that it would then have a vertex off the grid depending how you clipped it?

I think I have learned to stick to the grid as often as possible even with clipping. I used to clip to make circular shapes but I try to use vertices now so that I don't get wandering geometry. 

I meant mostly quark, and it occures in Radiant irregulary. TB hasn�t got that issue to me, as i�m texture-finetuning in an editor capable of ETP. Meh, i know but i�m a bit pedantic when it comes to alignment:) 

 

Simple operations such as moving brushes around in the editor result in degradation of your plane equations and everything ultimately ends up off grid by a tiny amount.

I also believe planes drift every time you load a map into the editor, so your map slowly decays over time, like that badger carcass in the grass verge that the kids can't stop poking at.

SO THAT'S WHAT THAT WAS!

Fuck. At one point (before I gave up) I was building 95% of my map geometry in Max to stop that happening because it was driving me crazy. 

I think it's important to mention there are 2 places where floating points can affect a map file.

Quick synopsis of map file format:
Brushes in .map files do not store vertex information at all. Instead, all the faces of your brush are converted into infinite planes, and the editor and compiler figure out, at run time, where the vertices of a brush are by doing the intersections of each of the infinite planes against the other planes in the brush.

The checkbox Sleepwalkr is talking about forces the planes stored in the map file to be integers.

Here's the thing:
You can have a brush face that was all it's vertices on grid but it's plane is floating point. Rounding the face plane to the nearest integer can make the vertices off-grid.
If this happens at run-time with not-as-good compilers, you get leaks that don't appear in your map editor.
All good compilers support floating point planes (like Aguirre's TXQBSP and other new ones).

Sleepwalkr: Is there ever a chance that having Force Integer Plane Points checked will round a floating point plane as to create off-grid vertices?
This is why I am afraid of using that option. 

If an editor wrote vertices to the map file instead of planes, could we make a compiler that creates standard Quake .bsp files from it? 

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. 

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