InsideQC Forums

I never really gave the brushes in a .MAP file a lot of thought.
Then I realized there are only 3 vertices for each rectangle face of the 5-faced wedge in the .MAP file. (Enough to define the plane, but not enough to render with that data as is ... it's got to be processed)

So I guess this is the part where the map editor or the BSP compiler turns the verts into polygons, edges, surfaces and such. Ironically, the only good way to research into this is looking through the QBSP source code. A look at the brush model rendering code shows the rendering part uses a "chain" of vertexes.

intresting
ill keep that in mind

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)!

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).

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)

Spike wrote: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.

Ok, this is a great start. I can visualize that so I bet taking a look at the source to either QBSP or one the map editors with the above explanation I can get what is happening here.

At least I get the general idea. That's rather interesting. And makes sense. So this is why concave brushes are illegal.

remember: dot(point, planenormal) - planedist = 0;

I've seen that kind of calculation more than a few times. I can sort of wrap that around my head and sort of not.

The normal is one of the 2 angles perpendicular to the plane. That equation is something about figuring out whether or not it is the near side of the plane or the far side of the plane using distance to the plane.

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)!

I think I've got enough to work with to start reading some code. Definitely in a much better position with that explanation. Once I figure this out, yeah that'll be great that I might have a shot at understand decal clipping and so forth. Thanks!

I'm probably only 8-9 concepts of 3D math away from being able to do some interesting stuff. I have to work through this kind of stuff on my own, but greatly appreciate the general description of what's going on which is not obviously commented in the code much of the time. I think these days clues to what something is doing is more helpful than anything.

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".