What would be handy would be if it automatically created a group from the resulting brushes. 

Isn't that in the entity inspector at the bottom? Or the map inspector? 

https://www.dropbox.com/s/oa8zpvbkvymiiuo/tb.jpg?dl=0 

Ok, I've figured it out... using TB2 is like trying to find something in your room after your mum has cleaned it. 

Yeah, but I'm going to take some of the UI changes back before the final release. But this particular setting stays where it is ;-) 

Your Mom hasn't cleaned my room in ages. It's a mess in here. 

Does TB2 have it's own bug list? I can't remember and can't find a link if it does... 

not it's own, but you can filter by milestone on github:

https://github.com/kduske/TrenchBroom/milestones/TrenchBroom%202.0.0
and
https://github.com/kduske/TrenchBroom/milestones/TrenchBroom%202.1.0 

When are you going to convert Trenchbroom to UE4??

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

Oh, nice! 

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.