Brushes ---> Faces / Verts / Polys / Edges

[Baker]

[WeeGee9000]

intresting
ill keep that in mind

[Spike]

aye, its a plane/pain...
anyway, figure out the plane equation, figure out the s and t vectors (doesn't actually need to be the ones specified, just use some random directions so long as they're perpendicular to the normal), generate an absolutely massive quad using those s and t vectors, then clip that quad against the other planes in the brush. This should get you usable geometry for each face.

remember: dot(point, planenormal) - planedist = 0;
by calculating the value at two verts, you know the plane cuts the edge if one is negative and one is positive. you can then calculate the the fraction along the line based upon their relative magnitudes, and interpolate them to find the point where it intersects. you just have to trim away the extra verts beyond the boundary.

You might want to keep that poly/planes clipping code - it could be useful for clipped decals too (where you take the entire world and clip away anything too far from the center)!

[mh]

3 points is all that's required to define a plane and with 3 points any shape is guaranteed to be planar (one reason why gfx cards use triangles). I've always thought it would be pretty cool to store the original map brushes in the BSP file and use them for drawing with (after the appropriate processing) - I believe HL2 does this. Lightmaps would be a bitch though, but if you could resolve that it should be considerably more efficient that the evil QBSP does to them. It's sometimes better to just pass the extra gemoetry to the GPU and let it clip/cull it than it is to waste time building complex structures on the CPU at runtime (some brush models are good candidates for this trick - don't bother with the backface test, just put the entire model in a static VBO and draw it with one call, see if it works in your favour).

[Spike]

my problem is that if I ever made a brush renderer, I'd want to do some red faction type carving far far too much.
brushes are certainly useful for more accurate collisions at alternative box sizes ala q2/q3, though you'd still want something optimised to ignore irrelevent ones (octtree with nodes added when the previous tier gets too full, perhaps)

[Baker]

[Baker]

Btw ... I have some funny ideas on some easy "free" lighting that mostly involves a using a single 256 x 256 RGBA texture (to query just like R_LightPoint) plus a height map texture. Would look better than full bright. It wouldn't look realistic but it'd add some sense of variation to the surfaces for "free".