Implementing Projected Shadows in Leadwerks 3

Shadows in 3D games are important.  Not only do they look good, but they communicate information about the 3D geometry of the scene.  Leadwerks pioneered dynamic deferred lighting, with one of the first deferred renderers in the world on PC.  However, the reality of today's situation in computing hardware has to be considered when we are designing a platform for other people build commercial products on.

To support games that reach the widest audience possible, we launched Leadwerks 3 with a baseline renderer that runs across the board on all supported platforms.  The engine has been designed in a modular fashion so we can add on a new high-end deferred renderer later on, and Leadwerks games will get an instant graphics upgrade with no code changes.  I am looking forward to pushing graphics even further later on when I turn my attention to the OpenGL 3.2/4.0 renderer.

Projected Shadows

As for the baseline renderer, there are a few extra enhancements I'm finishing up that will make Leadwerks 3 games look good on a wide range of hardware.  In my last blog I talked about light vector maps, which store normal mapping information in a second lightmap.  We delivered the results to users last week, and are am working on projected shadows, a low-cost technique Source Engine uses to provide dynamic shadows on characters and other dynamic objects in the scene.

I started by just rendering an object and getting its rendered image to line up with the original object:



The next step was to color the shadow black and use alpha blending, to make it look like...a shadow!:



The hardest part of this process, which I am still working on, is the data management.  It's easy to set up a simple one-time effect like this, but making it scalable so your games keep running fast takes much more work.  We don't want to re-render shadows when they aren't visible on screen, and we only want to re-render them when the orientation of the shadow caster changes.  We can't simply loop through all shadow-casting objects in the scene, because that approach will slow down when more objects are added.  Instead we have to build the shadow system into the scene octree so that shadows only get updated when its absolutely needed.

Post-processing Effects

Thanks to our research for GDC 2013, we found that post-processing effects on mobile are completely doable.  Consequently, we're adding a few post-processing steps to finish out the baseline renderer before we move on to OpenGL 4.  Bloom and HDR iris adjustment are the two that make the biggest impact on visual quality, and will be approached first.  Refraction effects are easy to add, and this time we're going to make them easier for the end user to set up.  The end goal is for the baseline renderer to be on par with Valve's Source Engine, and have it run on mobile.

We think these features will provide a striking visual impact on a wide range of hardware, and provide a good fallback for systems that don't support full deferred rendering.  Next, we'll be moving on to terrain and a new deferred renderer based on OpenGL 3.2 / 4.0.