Using Trenchbroom to create rocky paths and walls ... these verts were all perfect sitting on top of each other. Is this just something I have to accept or should I be snapping all vertices to INTs or what?

https://dl.dropboxusercontent.com/u/161473/Misc/VertexDrift.jpg

(in before FifthElephant tells me he has snap to grid bound to space bar) 

in before FifthElephant tells me he has snap to grid bound to space bar 

I'd like to check that out. Maybe send just the part in the picture. 

I'll work on a solid repro and send that to you. I already fixed that area. I've got drift everywhere now and I'm wondering if I need to burn the boats and start over.

Is it recommended to turn "Force integer plane points" on for maps full of organic shapes? It seemed to do bad things to the brushes when I reloaded the map ... cuts moved into nearby planes and made extra verts on a bunch of brushes.

It's hard to describe.

Maybe I'll just make an interior map with axis aligned walls. :P 

Sorry to read about the headaches with the vertices etc., but it's awesome that one of my favourite mappers is making something for Quake again. Yay! 

Is it recommended to turn "Force integer plane points" on for maps full of organic shapes?

It's recommended to turn it on before you do anything else with the map. :P TB2 does not even have an option to disable int plane points.

Willem Is Making A New Map! Yay!

Yup! This will be cool. 

Oh, so it's the recommended way? I didn't realize. The warning it throws up and the description text in the dialog box made it sound like "Only as a last resort!" kind of thing.

Turning it on now! 

 

You'll be missed 192.99.166.15 ... I always considered you a friend. 

Forcing integer plane points will result in more vertex drift as the editor needs to move vertices around so that the planes are all represented with integers. You'll get vertices off grid and such. 

But isn't that better than the verts drifting slowly over time as I close and re-open the map? At least I can see it happen and fix it on the spot. 

You're wrong. TB2 doesn't have this option at all and always allows you to use float points for planes. It will give you warnings in an issue browser though, with a quick way to fix them.

int plane points may or may not safe you from drifting vertices. I can't quite remember how TB1 handles it, but I think the problem is in writing and reloading floating points through text files - it's always lossy.

But as necros said, integer vertices will cause vertices to wander. There really isn't a way to deal with this problem that completely avoids any headaches. Integer plane points will give you off grid vertices, and float plane points may give you drifting vertices. Both might result in microleaks. 

integer vertices will not cause vertices to wander, but it will often result in vertices which are off the grid. 

I have the thingy majingy bound to the doodly do 

How does one become a beta tester for TB2? :P I have a project I'm working on, so I can provide real world feedback... 

I was thinking ... Of course you've considered this, but I'm wondering why you would have rejected the idea. What about a custom .TB file format or something? Why use the MAP file format for all I/O? It seems like that's where the loss is happening. If you stored the map in your own format and just spit out a fresh MAP file for each compilation you would eliminate this problem.

Like what Worldcraft did... 

.TB being a binary format, I mean. Something lossless regarding floats. 

Good idea imo 

and I don't want a binary format for better compatibility with other editors, also being able to edit the files in a text editor is a bonus. 

Was very 'strong' in that regard... but the headaches created by the proprietary format weren't minor.

Although having full control over it would avoid things like texture conversion problems of course. Most of which were caused by Valve not releasing the source.

I suppose it all depends on if you want to create and then support an additional map format SleepWalkR.

Just musing aimlessly when I should be 'working' :) 

"but the headaches created by the proprietary format weren't minor. "

You mean the RMF format? What were those, I'm not aware of what happened.

I think it allows for a few things ... floating point stuff aside, it allows for editor proprietary stuff like groups or prefabs/instances pretty easily.

I did the same thing in ToeTag in that I used the MAP file for everything. This meant that anything non-Quake had to get stuck into special comment lines that I parsed later. Was a little hacky and if I did it over again, I'd probably just make my own format.

As long as you can read/write MAP files also it shouldn't be an issue. 

It was often a blocker for working in teams - often getting someone to pull out their own teeth than install a secondary editor was easier. Getting someone to convert a map before sending it the same.

The other issues were all caused by committee design, things like texture alignment and WAD conversion.

Really, human obstinacy was the only real problem.

And if you support map as well as have a 'clean' format which still plays nice with other editors after export then it should be a non-issue in a technical sense. 

Maybe we need AlembicQuakeCollada 

Oh yeah, everyone loves a good standards fight, right? Right? Guys? 

Writing a float to text and reading it back doesn't need to be lossy.

From wikipedia,
if an IEEE 754 single precision is converted to a decimal string with at least 9 significant decimal and then converted back to single, then the final number must match the original

So just use "%.9g" in C and you're good. (I guess it's stream.precision(9); in C++)

I made a little test program a while ago that just loops through all 32-bit values, copies the bits into a float, does a round trip to string with "%.9g" and confirmed that is lossless for all 32-bit float values.