Plaidophile

I just dusted off the old code for Solace, my experimental research-oriented graphics engine from grad school. After going through and cleaning up some places where I was, er, abusing the then-current implementation of g++ (specifically with respect to some then-vague things in the C++ standard), I got it to compile, and link, and — amazingly enough — run!

Of course, performance wasn't as well as I expected it to be so many years after I wrote it (because when I wrote it I had a completely different set of expectations for how graphics hardware would evolve; it seemed like GPUs would be optimized for massively-multipass rendering and hierarchical depth culling, rather than the reality of the hardware actually getting "dumber" and more programmable at the pixel level instead), but it still runs surprisingly well, even if only 2-3x as fast as it did on my 1.1GHz Athlon with a Radeon 9700. Also, there are quite a few major rendering errors (especially for shadows) because I was making use of mathematical properties guaranteed by OpenGL's invariance rules which have since been relaxed. And, the massive "walkthrough" environment with dozens of dynamic shadow-casting lights still runs terribly slow (though at least now it's only 5 seconds/frame instead of 20).

Anyway, the purpose of this experiment wasn't for nostalgia so much as because I need to get back in the mindset for graphics programming (yay!) and I've gotten a bit rusty (boo!). Fortunately, just perusing the codebase has reminded me of a lot of stuff and the environment I'll be programming for is basically a subset of OpenGL (yay!). I was hoping I could just start out by porting Solace but now that I see how laughably terrible it is I'll probably just write something simple from the ground up.

I'm thinking I should finally release the Solace code, just for the hell of it, though I doubt it'll actually be useful for anyone. There are many much better renderers out there, and this wouldn't be a very good learning tool unless someone really wants to learn how I was approaching visibility determination and shader design from 1999-2002. (Well, I guess the dynamic spatial partitioning engine could still be useful for someone, although they'd probably be better served by just consulting my master's thesis, which has the code for just that part as an appendix, and anyway it has some retarded explicit-refcount garbage collection crap in it which could be trivially replaced by shared_ptr/weak_ptr.)

I think the most disappointing thing is just how shadows turned out; basically, I thought that on-card stencil operations would get really fast (via clever hierarchical z-buffering and so on) and would make stencil-based shadow volumes make a lot of sense. Instead, hardware has moved in the direction of better supporting shadow maps, which I still think are inferior (they only support shadows within a restricted frustum, they suffer from terrible precision problems, and they have some very ugly artifacting unless you use perspective-correct shadow maps, which nobody does as far as I've seen). Actually most games seem to use an even worse hack, where they just do traditional single-pass lighting and then draw in the shadows afterwards using a sort of inverted shadow map from a single infinite source (which just looks dumb unless you're very careful about certain things, which nobody is).