Darkwind Media Blog

A new version of Luster (version 0.12.1) has finally been released. This is an important release accompanied by a new release of the Luster Editor. This is leading up to the next big version of 0.13 (which has many many features).

One of the features in this version is anti-aliasing (a specific anti-aliasing technique called multi-sampling). This increases image quality by a large margin, but it does have some costs. Multi-sampling renders far more pixels than are eventually displayed (this depends on the anti-aliasing quality chosen). So, once again it is a trade-off. Here are some screenshots showing the difference in image quality.

The first image has no AA, the second has 2x, and the third has 4x AA.

After doing the deferred lighting system we hit a content stall. We’re waiting on artwork to put in. So, during this time I toyed with some other lighting systems. One of the goals I’ve liked striving for is more artist control over the look of the application. What this means is that once I’ve finished coding it, an artist can sit down by themselves and manipulate the look as they want. If lighting parameters are bound up in code somewhere this makes it really difficult. After the jump, I’ll show you what I came up with to help with this problem.

Read more

After a lot of experimentation I went back to the deferred renderer for Bombs. I tweaked it, contorted it, and beat it into submission until my framerates slowly started to climb. At some point I got into the acceptable range for my laptop (a range chosen completely arbitrarily and with no testing on other machines). I don’t want to give the impression that everything I said in my previous post is false, it isn’t. I had to make a lot of major sacrifices, but it looks as though this will be the lighting system that will go into Bombs.

The screenshots here actually show some backwards progress on art. We’ve removed the old towers and the sky. While I was working on lighting we were continuing to experiment on the art side. Hopefully some new assets will be ready soon. Note that while the lighting design is fairly complete the screenshots below do not necessarily reflect at all the final look or style of Bombs. The art will greatly affect how the game looks in the end. I hope to have more very very soon.

A few technical details: the scene below has 121 lights in it (which is quite a lot) and is running at around 100 FPS on my laptop with the decidedly unoptimized bloom turned on. Most of the lights in the scene are not really placed well, and are just there to stress the system. Again, art direction will make it look much better.

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