8Monkey Update

This is an update on what's going on at 8monkey Labs these days.

I've been working on a couple of things recently. I've finally got a texture loading class I like and support for TGA and PFM files. PFM (Portable Float Map) is our HDR format of choice from now on out. It consists of a weird but mostly harmless header in ASCII (ew) and a binary dump of floating-point data (complete description here http://netpbm.sourceforge.net/doc/pfm.html). Best of all, both HDRShop and Photoshop support it. I'm very glad to see Photoshop is on the ball with HDR. CS2 comes with HDR editing tools as well as exposure compositing, creating an HDR image from a set of LDR images at different exposures. I'm hoping Photoshop will eventually handle panoramic transformations too (e.g. mirror ball to vertical cross pixel transforms) so HDRShop can finally go away (no offense to Debevec but that program is no Photoshop and is just another link in an already cloogy art pipeline).

I'm also glad we found an alternative to the Radiance .hdr format. Radiance is stored as RGBE, the E being for the exponent on the red, green, and blue values. This limits the relative difference between color components, so you can't store an image extremely bright in red but dim in blue and green. Only problem is PFMs are friggin' huge, one 1024x1024x6 cubemap is 72 megs!

So far our approach to data size has been to fix the problem when it becomes one. The artists have been taking ridiculously large HDR pictures (with our badass 11 gigapixel camera) for texture creation, and eventually we'll downsample the high-res images to run in real-time. This will allow us to release the game with high-quality content suitable for the time. We can even re-release the game with higher quality content years down the road (Half-Life: Source comes to mind). We're going to try to take the same approach to modeling with subdivision surfaces in Z-Brush but that's a slightly more complicated pipeline problem.

Jeff has been working on a shadow algorithm for use with SpeedTree. We need to go with a shadow-map appropach because SpeedTree is all about sprites. So Jeff's been playing with various forms of shadow mapping. He gave up on the traditional depth compare shadow-maps because they result in very aliased, jaggy edges and all sorts of other problems. Now he's going with a different projected shadow approach that doesn't necessarily involve depth-compare. I'll post more about it once he's got it figured out.

For the last three days Jeff and I have been pulling our hair out tracking down the dumbest of bugs in the cubemap code. Turns out textures are invalid until you set the min/mag filter parameters; OpenGL just won't sample the texture until filters are set! Man that pissed me off, it doesn't even throw an error!

Once we figured that out we spent all afternoon fixing our cubemap loading code. We were trying to load cubemaps from a vertical cross format and could not figure out how OpenGL wants the individual cubemap faces oriented. Turns out when you're passing in images for the individual faces of a cubemap, the +/- X and +/- Z faces need to be rotated 180 degrees. This means if you have a horizon in your cubemap on the +X face, before it's uploaded the data needs to be rotated so that the sky is pointing down and the ground up in the image.

I still cannot figure out what frame of reference this makes sense in, so 50 points to anyone who can tell me what the ARB was smoking.