More Advanced Rendering Topics

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?

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.

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.

Hmmm. Interesting stuff.

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.

Well, part of my interest in these questions is there needs to be a decent map editor and I am wondering if maybe I might end up doing that.

I was kind of angling at whether or not there is a need to actually compiled the .bsp

Here is the logic of using the .map:

1. Forego lightmapping. Try to use some sort of real time lighting.
2. Cut up the surfaces? Well, no software or lightmaps seems to mean this isn't needed.
3. Visibility --- ??????? No answer at this time. Apparently I need to learn what portals and anti-portals are.
4. Textures. Well, put them in the zip file.
5. Collision hull. Hadn't thought about that and I'm not 100% on how the collisions are really determined in Quake. Seems to walk the BSP tree but that is a little fuzzy to me what is in the BSP tree.

Anyway, if I do make a map editor, I wouldn't want to have to load up a client to test the map. I mean "try it". Like with physics and being able to walk around it.

quaterions? Are these guys matrix4 somehow flattened into 4 numbers with some sort of margin of error. Like lossy compression.

Physics

As far as I can tell even though I don't yet fully understand SV_RecursiveHullCheck, physics is probably just checking all 8 corners of the box. I figure the BSP format does something to help rule out what surfaces to check against by using visibility maybe? I need to look deeper into this.

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

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.

f an engine can get playable fps with novis=1

/Smacks self. Sheesh. Why didn't I think of that.