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. 

Would this be something that could be supported in the future by TB?

https://www.youtube.com/watch?v=rJzguNJsivM 

but I have no interest in developing plugins for Unreal. If anyone wants to do it, I'll support it, but I won't do it myself. 

I am having trouble loading FGDs for Hipnotic and Rogue into TB2. Has anyone else tried these in this build? Maybe I am doing something wonky. Trying the FGD versions from Quaddicted archives. wanted to ask before submitting to Github.

Error and then crash:

Unknown entity definition class @Main (line 8, column 1)

TrenchBroom-Win32-2.0.0-36e49c4-Release 

Cannot load this in TB1 either same error although it doesn't crash.