I lost link of "general discution about quake", in threads i am lost searching it... 

There is a part in the intro docs that is phrased poorly. I suggest a more technically accurate phrasing below.

In

http://kristianduske.com/trenchbroom/docs/getting_started.html

it says

"Planes are represented with 3 co-linear points (in other words, all 3 of those points are on the plane)."

I am used to the spelling collinear myself, but some dictionaries list the single-l form too. It's probably not important which one you use, as long as you are consistent.

I believe what you meant to say here is the opposite of what it literally says. As I'm sure you know, the 3 points must not be collinear for a map compiler to accept them. I don't remember off hand if they all just crash if you give them a hand-edited file with bad points, all on the same line, or if some compilers print an error message, but that's not important here.

I would recommend the following phrasing for the surrounding context, including actually not using the term collinear at all, because it's not important from the users' point of view. The editor takes care of the points not being collinear after all.

- - -

Each plane is represented by choosing three [unique] points from it that do not lie on the same line. These points don't have to coincide with the vertices of the brush that the planes define. Therefore, it is possible for the editor to find a representation for the plane using only integer points, even if the resulting brush has non-integer vertices.

- - -

The word unique is not necessary there, but if you feel it makes the idea clearer you can include it.

If any other improvements or suggestions for the docs come up as I read them, I can send them via Github from now on. I assume that's the way you'd prefer. I'm going to be reading the docs carefully, since I'll be trying to use a Trenchbroom for a bit of modest mapping soon and need a bit of a refresher :) 

It's co-planar, isn't it? 

It doesn't make much sense to say "three coplanar points," because all sets of three points in Euclidean space are always coplanar for at least one plane. So, I assume it was collinearity that SleepwalkR was thinking about when writing that sentence. 

Just hurry up and make a decision. I've been gagging to use this editor and the non-precise wording of that sentence has been blocking me for ages. 

While Trenchbroom and all other editors represent brushes as 3D meshes with polygons and vertices, brushes are actually defined as a set of faces created from intersected planes. Each intersection of at least three planes generates a vertex in 3D space, and since each brush must be convex, each face will have at least three vertices, and the lines between each pair of vertices will never be colinear with the lines between any other pair in the same face. Thanks to this, the orientation of those planes can be safely calculated from the position of three of its vertices in 3D space, and their edges are resolved by getting the intersections of those planes during compile time. ID chose to use this method because it reduces the filesize, is faster to render in software, and is safer against T-junctions. 

"is faster to render in software"

How does the MAP representation improve software rendering speed? 

 

ID chose to use this method because it reduces the filesize

Fun fact: In DoomEdit (The Doom 3 editor), id chose to reduce the filesize even further by defining a plane with just one vector and one scalar, representing a normal and a distance from the origin. This meant that every single brush face that was not aligned with an orthogonal axis was represented using imprecise float coordinates.

Further to this, opening and saving a .map file would cumulatively introduce float imprecision into these brush planes, including ones the designer had not even fucking touched in that session, meaning over time, the map they had been working on started to develop microscopic cracks in areas that were long since considered finished. A Doom 3 map literally decays over time as you work on it, along with the designer's sanity. 

Why on earth would they care about MAP filesize on Doom 3? Geez... Old habits I guess. 

Because it follows some essential principles used by the software renderer: convex brushes, convex polygons, and implicit texture mapping (which plane normals are used for).

The MDL format, on the other hand, uses things like direct texture mapping (each vertex is directly assigned to a texel's coordinates).

I said the method is faster to render, not the format. 

The renderer is reading the BSP so ... it's a glob of triangles, same as the models are. That's all I'm saying. The source format for the MAP file has nothing to do with anything renderer related. 

The software renderer didn't see the world as triangles originally, did it? wpoly and epoly were totally separate paths. 

the software renderer traversed the bsp tree and rasterised the convex faces, which were not necessarily triangles. 

True, and the epoly had that optimization we talked about before where it would only render the vertices if a model got too far away.

However, that doesn't change the fact that the source file format has nothing to do with how the software renderer works. QBSP shreds the brushes into a tree ... after that the source format is irrelevant. 

In fact in the actual bsp file the plane struct is a normal vector and distance (and a type field), so the three point version of a plane disappears completely after qbsp. 

 

Of course, you are right. What I wrote is nonsense. I will rephrase this in the TB2 docs. Thank you for pointing it out! 

Keep it up, looking forward to having HL1 support out of the box in TB 2.0, this has some serious potential to ignite the HL1 modding community back up again like it's 1999 ;) 

Haven't compiled the tb develop branch in a while and its failing with thousands of the same wx-3.0 Wdeprecated-declaration warnings where previously there where none. 

Those are just warnings, the error is missing pandoc.

make[3]: pandoc: Command not found 

Appreciate that. I was up very late when I attempted to compile and wasn't thinking clearly. 

Re #1907 by Kin on 2015/11/12 17:08:10:
I've read this post today and just fired up the Doom 3 Editor and looked at a freshly saved map file.
And oh my, this is real. They are really using the numerically unstable way of saving brush plane information using just a normal vector and a distance value.
Why on earth would ANYONE do that? Move the whole level geometry forward and back a bit a few times, and you're _guaranteed_ to have everything that's not perfectly straight entirely screwed up! That's lunatic!
O_O
X_X 

I think Sikkpin or someone modded the editor to use the quake-style plane format and the problem of course just went away - you could try to dig up some info about that. 

I lost a couple of maps to that feature before I realized that you're really meant to so complex get with models.