PrinceOfFunky wrote:Why would you need all the vertices of brushes if you can have less than half usually in an entire map? Why keeping a brush which of most vertices are stuck in another brush? Or keeping the vertices of a subtracted brush. I believe the brushes get converted into Level when you build them, indeed when you build a brush and move the brush somewhere else the built brush is still there until you rebuild.
ya true - this reminds me of some thoughtful things. It is not too hard to imagine what the compiler is doing with brush data in order to process the "bsp-tree". I actual have/had (engineering) documents how these algorithms work.
Abstractly, the business of lining vertices up all neat and tidy on the uu grid otherwise it's a disaster is a bit silly. That's just humans being tidy.
It's all 3D math using double-precision numbers, rounding (at some depth/tolerance) and triangles with normals so the compiler knows which face is in space, or the void.
Basically the compiler/algorithm only cares about the faces in the space side of normals, ignoring the void. So really, additive csg brushes that exist in or extend into the void is basically IGNORED by the complier. Of course the exposed part is used in calculations.
There's more to it obviously, like occlusion (data to support what to render to the camera (FOV / POV), collision, lightmapping blah blah). Lots of room for ERRORS - resulting in things like hommies, holes, invisible "walls", black blotches etc.
Some guys, knowing this, would consciously throw mud in the face of the so-called "guru" mappers (in the editor, of cource). A favorite example of mine is Blito3 and his map "Island of the skull devils". Open it in the editor and have a look. Hilarious! And it works - of course it does
Now try and find HOMs. Good luck - i don't believe you'll find any. Now open CTF-Tuesday (by you know who) not hard to find HOMs in that one, as I recall.
Anyways, fun stuff, as always