More Advanced Rendering Topics

[Baker]

Maybe not advanced in the MH way ... but anyways ... here goes ...

I'm easily starting to see the merits of the way matrix calculations are supposed to be made in modern times. If you have objects that have parents ... which isn't so similar from tags I guess ... in OpenGL 1.x the matrix push/pops get ridiculous.

1) I've heard Spike talk about draw lists. Is this for better sorting (i.e. not just per entity)?
2) How is it possible to calculate the outer bounds of complex objects with multiple components? You have aggregated matrices with all kinds of factors stuffed in them. Or is that a "don't bother" kind of deal ... skip out on accuracy and just pick some numbers and if stuff pokes through walls rarely who cares?
3) Other than for vis and light map generation, what else does the BSP compiler do other than slice up polygons for software render + so that the pieces can be light mapped?
4) I've never compiled a Q3BSP but it is my understanding that it doesn't have vis. If that is the case, how is it culling off stuff it doesn't need to draw because it is obscured by other parts of the map or a wall in the direction you are facing?

[mh]

Q3A definitely has R_LoadVisibility. Doom 3 on the other hand doesn't use a precalculated PVS. There are plenty of ways to get visibility without precalculating it, portals and anti-portals being popular (DarkPlaces has an option to use these, I believe). Quake almost used portals late in it's development, but I believe that the difference between slowest and fastest scenes was too much. Would be interesting to explore again today.

I think Rage uses hardware occlusion queries, possibly in conjunction with a software method (which I think might be useful to get a rough working set before you really go for it).

QBSP also calculates collision hulls (gone in the Q2 version) and sets ambient sounds, pulls textures from WAD files into the BSP, sets contents flags and a few other things. It's brush splitting is the really nasty part - that was totally designed around the needs of a software renderer with zero overdraw, and is completely inappropriate for hardware (where it's often faster to accept some overdraw and extra vertexes in exchange for being able to batch up more stuff together). It took until Q3A to put that one right.

[Baker]

[Spike]

if you're looking to get an engine load a map without first compiling it, then you can quite frankly bruteforce it. if an engine can get playable fps with novis=1, then a few extra surfaces is at worst a 6-fold slowdown. offset that by no lightmaps interrupting batches and no maximum surface size, and you should be able to obtain reasonable framerates on any modern hardware.

recursivehullcheck requires a bsp hull to, urm, check... basically it just walks the bsp to find each leaf boundary between the start and end points.
you can instead walk through a surface list and directly clip against surface polygons, though you do tend to need to expand the traces slightly at the edges to cope with precision errors, and to move the surface plane outwards based upon normal and bbox size.
fte's r_d3.c D3_TraceToLeaf function attempts to do this, although if you prefer id's code, check out doom3's code which should do something similar (in doom3, there is a simplified axially-aligned bsp tree for collision. this bsp tree contains brushes and surfaces. surfaces are used for collisions, while brushes are used only for pointcontents).

a quaternion is a matrix3, not a matrix4, where each axis is perpendicular and of the same scale. the four components combine to give dot4(quat)=length, thus if your quaternion is of scale=1, you can forget one component and calculate it later. Due to their smaller size, quaternions can be faster to multiply together than matricies.
thus a quaternion is basically an 'angle with scale' as opposed to a full transform. it doesn't contain any more information than pitch+yaw+roll+scale, its just a little less arbitary and easier to combine together (at least when its known to not be constrained to a single axis).

[mh]

Frankly though, multiplying matrixes together is something that happens far far less often that multiplying matrix by position. That's the one you want to target if you're going to target anything (with shaders a 2D GUI transform can be collapsed from 4 DP4s to a single MAD - assuming that you're not rotating any of your 2D stuff).

Beware that Quake also uses the PVS for server-side stuff - cutting down the list of entities that get sent to the client and assisting line-of-sight tests. QW adds a PHS.

[Baker]