2010
07.22

Since the last update there have been two significant improvements made to the deferred render manager. The first of these improvements is proper support for alpha blended (semi-transparent) objects. To accomplish this the render manager splits all registered render priorities into two types: deferred and forward. Any object with a deferred render priority will be drawing using deferred shading, while objects with a forward render priority will be drawn using forward shading. What the deferred render manager considers a forward or a deferred render priority is user configurable.

The second improvement to the deferred render manager is proper support for heavy portals. A heavy portal is any portal that requires the scene behind that portal to be rendered to an off-screen buffer. Two methods were considered for adding support for heavy portals. The first method was to reuse the GBuffer for each heavy portal and output the results to a unique off-screen buffer. The second method was to create a unique GBuffer for each heavy portal. The drawback of the first approach is that, due to hardware constraints, the off-screen buffers must match the resolution of the screen. In most circumstance this is a waste of memory since portals rarely fill the entire screen. However, this potential waste of memory is dwarfed by the memory overhead of having a unique GBuffer for each portal. As a result, I decided to use the first approach.

rm_unshadowed rm_deferred
rm_unshadowed rm_deferred

The above pictures show a scene with proper rendering of alpha blended objects. Namely the blue crystal and the fire particles are properly being blended with the rest of the scene. Note that they do not appear in the GBuffer since they are rendered after deferred shading is done. This scene also contains a heavy portal behind the blue crystal. Through this portal you can see a blue pillar and some alpha blended flames.

2010
07.11

The latest update to the deferred shading implementation is support for point lights, spotlights, and directional lights. Along with these standard light sources we have a fourth light source, unique to deferred shading, used for ambient lighting.

Traditionally ambient lighting is added to the result of the lighting equation when the geometry is initially rendered. However, with deferred shading we separate the geometry from the lighting and only output pixels that are directly affected by a light source. As a result, we have to be sure to account for ambient lighting on geometry that is not directly affected by a standard light source (this is particularly important if we want proper support for light mapping). To accomplish this we have a special lighting pass, implemented using the same methods as the other light sources, that outputs the ambient lighting term at each pixel.

rm_unshadowed rm_deferred
rm_unshadowed rm_deferred

In the above scene we have a point light, spotlight, and directional light emitting red, green, and blue light respectively. The next stage in development is to add support for semi-transparent objects. From a high-level, this will be done by rendering the semi-transparent objects using a traditional forward rendering after all deferred shading is completed.

2010
07.02

Over the last two weeks I have been focusing on improving the lighting implementation for the deferred shading render manager. That includes adding support for normal mapping, parallax mapping, and full Blinn-Phong shading. Below is a side-by-side comparison of the unshadowed and the deferred render managers.

rm_unshadowed rm_deferred
rm_unshadowed rm_deferred

I have also included a close up view that better highlights the use of parallax and normal mapping. The parallax effect is particularly noticeable along the edges of the bricks where they appear to ‘pop’ out of the wall. The application of normal mapping can be seen in the subtle changes to lighting across the surface. For instance, the spaces between bricks appear noticeably darker then the flat surface of the bricks.

Close up view of parallax mapping.

One point of interest in the screenshots from the deferred render manager is the row of four images along the bottom of the screenshot. These images are visual representations of the GBuffer used by the deferred shading method. From left to right we have the diffuse color, view-space normals, specular color, and post-projection depth information. This is all of the information needed to compute lighting information for an arbitrary number of light sources.

As of this writing, the deferred render manager only supports point light sources. However, full support for spot lights and directional lights is fast approaching. Once that happens I will begin work on adding support for ambient lighting (implemented as a special type of light source), semi-transparent objects, and portals.

2010
06.15

Google Summer of Code 2010
+
Crystal Space

In early May I began work on a Google Summer of Code 2010 project for the open source 3D engine Crystal Space. The goal of the project (outlined more formally here) is to bring deferred shading to the Crystal Space engine.

Deferred shading is a rasterization based rendering method that separates the rendering of geometry from the process of lighting that geometry. In the traditional approach to rasterization (commonly referred to as forward shading) the rendering and lighting of geometry are done in tandem. As a result, using forward shading tends to limit the number of light sources that can affect a single object. However, with deferred shading the cost of adding a light to a scene is independent of the number of objects in that scene. This allows for a significant increase in the number of lights that can be on-screen.

To facilitate the use deferred shading with Crystal Space I have created the deferred shading render manager (rm_deferred for short). Since the usage of rm_deferred is identical to all other render managers, one can easily switch to using deferred shading in any Crystal Space application by supplying the engine with an instance of the deferred render manager (or specifying it as a configuration option). Bellow is a side-by-side comparison of the deferred and the unshadowed render managers being used in the deferred shading demo application.

rm_unshadowed rm_deferred
rm_unshadowed rm_deferred

At the early stage in development the deferred render manager only supports point lights with diffuse Phong shading. I am currently working on adding support for spot lights, directional, light attenuation, and specular highlights.

2009
10.29

Good news everyone!

In July of this year I  joined the INSURGENCY: Modern Infantry Combat mod team and have been working on the latest update to the game.  I am happy to announce that after many month of work the update has been released through Steam.  This is a significant updated that adds new features and fixes a number of issues (outlined here).  Insurgency can be download through its Steam page (its free if you already have a Source Engine game).

Also checkout the new Insurgency project page for more information and screen shots.

2009
09.02

The final version of BrickOut |ReDuX| is complete and available here in both binary and source form.

BrickOut |ReDuX| is a fully featured breakout style game complete with seven unique levels and a persistent leaderboard. Implemented entirely in C++ with a focus on being operating system agnostic. BrickOut |ReDuX| is distributed as open source software under the zlib license.

2009
04.19

Huzzah!

I just received an acceptance letter from The U.  I will be starting the Masters program in Computer Sciene this Fall.