I honestly feel like I don't want to continue my map anymore. I'd rather bin it and start all over again. I apologize for not finishing it. 

I would try to find out what caused the leak so you avoid running into the same problem. 

Thanks, Rick. Parallels seems to have open gl problems indeed...

And thanks Willem, even though you Bootcamped me. 

What kind of leaks, like going straight through brushes?
How many are there, and what compiler do you use.
Try to not use the -forcegoodtree switch(in case you use it) 

Just finish the map, then once you've "sealed" the map from the void if it still leaks just get someone else involved with the map and they'll help you fix it. I guarantee someone will help you. 

JUST AFTER SPIRIT HELPED ME FIX THIS I DECIDE TO MESS AROUND WITH ROCK BRUSHES AND NOW THERE'S THAT FUCKING LEAK AGAIN! I AM CLOSE TO STARTING ALL OVER! GOD DAMMIT! 

Binding 'snap verticies to grid' to your spacebar and banging away on it like a madman as you do terrain. 

Seriously, someone else mentioned this too and it really works wonders IMO. 

I won't be continuing work on this map and I've disappointed you all and I am disappointed myself. encountering errors like this is just another way of learning to map and hopefully I won't make the same mistakes in my newer map.

Sorry guys. :( 

You're getting micro leaks between the brushes, this is just how TB works, for now at least.

There is also an option 'force integer snap' but this leaves it difficult to make anything that isn't a box.

I notice a similar problem with texture alignment as well - rotated brushes often end up with .36381819 scaling and positions. This inaccuracy seems to cause drifting as the brushes get moved around.

Shame I only noticed after duplicating a shit tonne of wonky crates around the level :L 

You're getting micro leaks between the brushes, this is just how TB works, for now at least.

There is also an option 'force integer snap' but this leaves it difficult to make anything that isn't a box.

I notice a similar problem with texture alignment as well - rotated brushes often end up with .36381819 scaling and positions. This inaccuracy seems to cause drifting as the brushes get moved around.

Shame I only noticed after duplicating a shit tonne of wonky crates around the level :L 

Force integer snap does NOT make anything difficult. It just prevents you from creating invalid brushes and it should be enabled at all times. You will have less leaks and you won't have to snap the vertices to integer coords anymore. In fact, what you're doing restricts you a lot more than just leaving the "force integer plane points" option on.

And what do you mean that rotated brushes end up with that particular value for scaling and position? 

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.