We were thrilled about the article, and have been absolutely swamped with emails and calls about it since then (hence the late post). We loved working the D&C on it as they were really nice and a fun group of people to work with. It seems we now have some expectations of us to fulfill.

I do not know who the original author is. It was uploaded here.

You can check out our company website at www.darkwindmedia.com or browse through our Luster website at www.luster3d.com. We can help you build state-of-the-art interactive applications or get you started with your own 3D system by licensing Luster to embed into your own applications.

Check out both sites. Luster itself is growing by leaps and bounds. Our mac porting is coming along nicely, with support for almost all of the Luster plugins. Browser support on Mac will follow that. We are now entering a closed beta phase. If you think Luster could help you, or you just want to know more, then contact us.

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.

First off, the models that appear in the images below are not ours. They were available online for free, but we will only be using them for demonstration purposes. They won’t appear in Bombs, or any other applications of ours. Thanks go to the original modelers.

Those screenshots show lighting that is based on 3 factors: The lighting condition (direction, distance, and color), the viewing angle, and the distance from the viewer. So, how is an artist given control over this? Using two textures, an artist can create a great many lighting effects. Here are the textures used to control the above images.

The top image shows the texture controlling the diffuse lighting, based on the direction to the light (x-axis) and the distance from the viewer (y-axis). The second texture lets artists define lighting effects that are view-dependent (rim lighting or shading, specularity, etc.) which depends on the direction of the viewer (x-axis) and distance from the viewer (y-axis).

Changing lighting behavior is fairly easy by modifying these textures. It isn’t instantly mastered. The textures do have a bit of a learning curve until you get a hang of how changes in the textures translate to changes in lighting behavior. However, it’s fairly obvious how these textures provide a lot of control for artists, and are easier to edit than parameters in code. Essentially each 2D texture is defining a function with two inputs, which output a result that is combined into the lighting equations. By changing the textures, an artist is actually changes the lighting equations themselves.

Here’s an example of two different textures.

You can see they are quite different. The top lighting texture has had all color removed and a more gentle slope introduced. This will give the objects a softer look. The bottom texture shows a rim darkening effect. Here are the results of using these textures.

We can achieve many varied looks using these two lighting textures (not to mention textures mapped to the object itself). The other benefit of this technique used with forward rendering (not deferred) is that each object can easily have its own custom lighting. Also, because the lighting equations are stored in textures, a simple texture fetch (tex2D) function computes view-independent and view-dependent lighting effects. The fewer instructions means we can handle more lights per pass than usual, meaning overall a scene will be able handle more lights with forward rendering than before (16, 32, maybe even 64 lights per object with modern cards that support Shader Model 3.0). With this, we may be able to achieve a many-light rendering system without the up-front cost of deferred rendering. This is still experimental and the deferred renderer is still in Bombs, but as the art content and style becomes more concrete we may move over to a system based around this shader. Stay tuned for more!

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.

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

Towers are now moved by selecting them and clicking on the environment to send them moving on their own (RTS-style select and move). The speed of the bomb and power of the towers has been adjusted and the number of towers per person as been lowered to 6. Also, the attractor towers have been completely removed as they were incredibly difficult to use effectively.

We’re in the process of tweaking the gameplay as well as creating content to replace our stand-in objects that you see in the screenshots below. The gameplay is developing quickly, so I’ll be able to update with more information soon. There some major elements still to be tested that we’re keeping under wraps.

And here’s a rough concept render of the finished force tower. We’re still working on it, so I’ll post a new screenshot soon.