brush-coordinates - how do they work?


(MuffinMan) #1

hi people i found a description of the .map format in the quake documentation project:

The planes are specified by three points in clockwise order. The
points that define the plane are not necessarlily points on the brush,
but just three non colinear points on the plane. I chose this
representation instead of an explicit normal/distance plane
representation because it allows me to keep perfect precision with
integral values: it guarantees integer values for anything we create
in our editor, lessening concern over floating point creep.

Each brush defines a solid region. Brushes define this region as the intersection of four or more planes. Each plane is defined by three noncolinear points. These points must go in a clockwise orientation:

1–2----------------->
|
3
|
|
|
|
|

i found this while searching for some info for my collaborative-mapping
tool i’m currently doing and i have to admit i don’t understand it completely - take a normal brush, 6 sided - this brush has 6 lines in the .map like this one:
( 192 128 0 ) ( -128 128 0 ) ( -128 -128 0 ) miltary_wall/concrete_c06 0 0 0 0.500000 0.500000 0 0 0

here we have the 3 points that define that plane with all the xyz-coordinates - but: this seems to define an edge of the brush, 3 coordinates are afaik only enough to define an edge not a complete plain with 4 sides and edges, otherwise a plane with an arbitrary angle than 90 degree couldn’t be defined…? so i would have assumed the brush has 6 planes -> 6 lines in the .map with each 4 coordinates for the edges…

you see i am quite confused and mabe talking nonsense, anyway it would be great if somebody could explain that to me or point me to some explanation, couldn’t find any more info on that by simply searching…


(MindLink) #2

3 points are enough to define an infinite plane. The edges are computed by intersecting all planes that belong to a brush.


(ydnar) #3

A Quake brush is a convex polyhedra composed of the half-spaces on the backsides of all its component planes.

The 3 points that make up a brush plane in a map file can be any set of arbitrary points as long as they lie in the desired plane and are not colinear.

y


(MuffinMan) #4

ah thanks!.. i guess i understand, i didn’t assume the planes to be infinite…
it’s quite a bit of work to calculate the real coordinates then, right?

read a bit on the bsp-structure as well, slowly the stuff is starting to give me an idea of how things work!


(MuffinMan) #5

what would happen if there’s no integer-value at an edge of the plane? is this the actual problem happening when you rotate a brush - it turns and doesn’t find an integer value at the new angle - so the points are set somewhere behind the plane where the next integer is available?

why is it so important to have integer values at all, is it because of more efficient BSP-compiling or does it affect game speed as well?

edit: forget the last question i guess i found the answer, using floating point numbers could lead to “unclosed” brushes with planes not meeting perfectly, right?


(ydnar) #6

They’re not always integers…

…and you seem to have stumbled upon the main problem with using brushes.

y


(wudan) #7

Yeah I went in to the channel where the gtkradiant devs are at to ask this question, and it pretty much boils down to the ‘integers are not floats’ problem. If you’re clever you can work around it.

If you have a map object (brush masterpeice) that you need to rotate, compile it to BSP and then convert to ASE.


(Emon) #8

They could be double precision, but then it’s getting too big and slow, and still a pain in the ass to work with.