Deferred Rendering Woes
Since the last update on Bombs I’ve been working on the visuals. While the rest of the team is working on content, I have been creating the rendering engine that would power Bombs. Partly because I hadn’t made one yet, partly because I wanted to see how Luster handled it, and partly because I wanted to see the strengths of it, I chose to implement a deferred renderer.
If you already know what that is, go on and skip ahead. If not, I’ll give you a quick explanation. There are all sorts of techniques you can use when working with the graphics card to render in realtime. One of these techniques is called deferred rendering, which defers (or delays) the calculation of some aspect of the rendering. In my case (and most) the deferred calculations were those that combine the lighting properties and object surface properties to create the final image. Normally, when rendering a scene, the renderer will iterate over each object, then iterate over each light affecting that object, and accumulate the lighting before moving on to the next object. With the deferred system, all objects are processed, their surface properties stored, and then all lights are processed in a completely separate step. When the lights are processed, the stored surface properties of the objects are accessed and lighting equations run.
So, what’s the point? Why do this at all? Well if you’re observant you’ll notice an interesting property of the two renderers and that is the number of times we need to loop the renderer. With the traditional method (known as forward rendering) we must make numberOfObjects*numberOfLights passes over the scene. With the deferred renderer we need to make numberOfObjects+numerOfLights passes. This is a great aspect of the deferred renderer: it scales with the number of lights extremely well.
However, it isn’t all good. There are higher up-front performance costs with the deferred renderer, and usually much higher memory costs as well. These costs can make this style of renderer ill-suited for some applications. Indeed, it made the deferred renderer a poor choice for Bombs. The main culprit I believe was the high memory costs. My laptop video card just doesn’t have the large amount of video RAM necessary to make this technique worthwhile. Bombs was not meant to be a high-end game, but one that is quite accessible. While I can make the graphics scalable, that task would be more difficult with the deferred system. So, I’m going to have to shut down this experiment and build a more traditional forward rendering system for Bombs. I have a lot more experience with this type of renderer, so it won’t take two weeks to make like the deferred renderer did.
As a little gift, here are some shots of the deferred renderer in action. Try to ignore the sky, that was another experiment that’s unrelated to the renderer. I did not put any effort into properly blending the sky with the terrain so that’s why it looks a little “off.”
