|More Deferred Rendering
||[Aug. 25th, 2008|05:18 am]
Spectre Gruedorf Challenge Blog
After a weekend of deferred rendering programming, it's official. I'm not going back. I have drunk the Kool-Aid. The banding cleans up nicely when I have floating point texture formats for everything, and we now have... lighting. That works. My god, it's beautiful. |
Sort of an approximate lighting TODO list:
- spotlights + projective textures
- hook all the shadow mapping stuff back in
- get the depth buffer back when rendering the "post lighting" pass
- omnidirectional shadow maps
- scissor tests
- stencil tests
- work around driver bug on Mac OS X with GL_ARB_DRAW_BUFFERS
- fallback path. If we don't support floating point render targets then we have to actually do a separate pass to fill a larger depth buffer, because otherwise we only get 8 bits and that's Just Not Enough. Since you can't have different texture formats attached to an MRT, this means I have to do a depth pass seperately for everything into a 24 bit depth target. (Not a big deal; I have this code left over from shadow mapping anyway.) Then I just have to hack it so that we read shaders in the fallback case.
- Support placement of all this stuff in the editor. (Gnyargh.)
Most of this will have to wait until I work through the usual List of Tedious Shit that needs to be done. (This week: grouping, rotation by fixed angles of objects, and other goodies like that.)
The obligatory screenshot. Note that my colour choices could be a lot better, as could my light positions, and also that nothing in the engine actually has normal maps right now, although some support for them exists. Somewhere.
I think that one of the most important takeaways of the exercise is the following, which I think that anybody doing large programming jobs on small projects would be wise to remember. Deferred lighting works for a number of reasons, but the biggest advantage, for me, is that it gives me incredible bang for my buck. In about half of a weekend, we've gone from no lighting at all, to having directional and point lights that work correctly with everything that I've already written, in a clean and robust manner, that is also compatible with the stuff that I want to do moving forward.
I'm only one programmer, and I have a heck of a lot of other stuff to do. Getting the same effects with a traditional approach and having it work nicely with the terrain would mean a lot more special cases, a lot of tracking stuff through the engine, and generally being miserable for about three man-weeks of work. Now I have those three man-weeks back to do other stuff with. Losing MSAA and having to do some extra work to get transparent, lit objects working (which would have been a bloody nightmare anyhow in a multipass renderer) are not big losses when you think of everything that I'm getting. If I was part of a team of five graphics programmers, or, hell, even five programers in general, would I make the same trade-offs? Possibly not (although, again, Blizzard, Guerilla, and the STALKER guys all did)
But for me, and for anybody else who's just one man, it's great.
EDIT: The kick in the nuts turns out to be trying to get everything actually working with multiple render targets and/or floating point buffers. While my video card at home supports everything, it is actually new. On my minimum spec testbed (my laptop, which has a Radeon 9700) we:
- can't use floating point textures without being banished to some kind of hell-pit
- can't, apparently, use MRTs for some things (namely the texture blend operations for the terrain; the blending is triggering some kind of completely abnormal fallback to software)
Mind you, this is just a new round of the usual multi-vendor OpenGL Compatibility bullshit game. So this isn't anything new, really, it just means that this is the first time I've actively gotten the engine to the point where it really does become an issue.