On the rendering side, ray marching on the 200×200x200 volume shows the amplitude of the maximum speed vectors:

A demo, including source code, can be found at the author’s website:
http://users.skynet.be/fquake/

It seems to be loosely based on irradiance volumes, instant radiosity and photon mapping. Part of this clever approach was presented by Alex Evans back at Siggraph 2006, where he discussed fast lighting approximations using irradiance slices. Anton Kaplanyan, who developed this technique at Crytek, went even further by improving quality and tackling scalability issues.

Instant radiosity works by using virtual point lights to approximate global illumination. To get decent quality out of IR, hundreds (if not thousands) of virtual point lights need to be generated. Kaplanyan opted for reflective shadow maps, a GPU friendly way of generating VPLs. Due to high fillrate demands, however, even deferred lighting wasn’t fast enough for the huge number of VPLs required. This is where light propagation volumes (or radiance volumes) came in very handy.

VPL SH-based radiance info is injected into the radiance volumes using point based rendering. Light is then propagated in the volume using the computed outgoing radiance flux. During the lighting pass the volume textures can be sampled directly, anywhere in the scene, in order to generate the lighting contribution, at each point, from the SH coefficients. Check the paper for a detailed explanation of the process.

Normal mapped surfaces, and even glossy reflections, are supported. Cascaded volumes are used when dealing with larger scenes. To improve the quality for local, more high frequency details, this approach is combined with screen space global illumination.

The performance, even on consoles, is very good and fairly stable due to the nature of the technique. Quality should scale very well with memory/hardware.

All in all, a very fast, current-gen, console-friendly approach to diffuse GI for dynamic scenes.

That said, I am currently “on holiday”, arranging my move back to Portugal. My personal work is on hold; I’ll get back to it as soon as I have some stability.

Feel free to contact me if you’re interested in discussing business opportunities.

The first step was to build a framework to read and process scene information. I decided to go for FBX; turns out the sdk is a bit dodgy but functional. The next step was to build an acceleration structure and a raytracing core and this is what I’m working on right now. Here’s the first image with basic diffuse lighting and shadows from a point light:

It took around 3.8 seconds at 140K rays/second (including shading). I have my Centrino Duo mobile CPU down clocked to 1GHz because of overheating; this will force me to optimize the raytracing core before I can start investing time on something like path tracing. The next step is to replace the Octree with a KdTree or BVH with both mono and packed ray traversal. My goal is to achieve a minimum of 2 million rays/second per-core on the same scene.

A man-made floating city called the Ark, made up of hundreds of separate floating islands, is on the brink of all-out civil war. Originally built as an experimental self-sufficient and 100% “green” habitat, the reported rapid rise of the Earth’s oceans has forced the Ark to become a refuge for humanity. Crammed with the original Ark founders, their descendants, as well as tens of thousands of refugees, the Ark exists in total isolation from the rest of the world. With 25 years of social unrest, the inhabitants of the Ark have reached their breaking point. It’s up to you to decide the future of the Ark and the human race.

This game is currently under development in partnership with Bethesda Softworks.

Here’s a sneak peek showing off glossy materials:

From what I’ve gathered it seems to work by storing global lighting information at each point (vertex/texel), much like the Precomputed Radiance Transfer techniques currently used in games. These tend to focus on Spherical Harmonic encoding due to efficient representation of low frequency lighting; it’s possible that RC’s technique is similar but instead based on encoding of nonlinear wavelets or gaussians which have been shown to work well for all-frequency relighting.

What does this mean for games?
- The video above runs on a mid-range ATI 4850 at 20 frames per second which is VERY promising.
- Static geometry is also a limitation for light maps.
- The high offline rendering times already exist when developing games that rely on high-quality directional or SH-based lightmaps. However, a biased version of the offline renderer could help reduce the hardware costs and generate good enough results for most games.
- Local memory requirements are certainly much higher than lightmaps. However, more compact representations trading quality for memory footprint could be used. e.g. partial wavelet coefficients.
- Local memory on GPUs will eventually outpace or be merged with system ram. A virtual page-based approach could also be used to help keep most of the data in disk.

I believe this technique has potential for use in games in the near future. These could very well be the next generation light maps.

Flavien Brebion, aka Ysaneya, is the guy behind Infinity. He is also the guy behind the bold attempt at Instant Radiosity in the shots above. In his journal he talks about the technique and provides some statistics on its effectiveness when combined with deferred lighting. Follow this link to read all about it.

Compiling the class libraries, however, is a different kind of challenge. After installing cygwin and following all the steps in this tutorial, I get compiler errors for undefined symbols in a few libraries. Of course, if the mono daily-builds were operational I wouldnt have to compile them myself.

In the meantime I’ve just downloaded the Unity 2.5 trial to see what all the fuss is about. It uses Mono as a scripting platform, something I’m looking to achieve for my development framework.

The RenderMonkey project is available here; it includes media files created by João Sapiro Vaz aka johny.

I took the liberty to take some screenshots of the several steps required for the final composition. The only step I didn’t bother to implement was the translucent shadow maps which are used to simulate light transfer through thin regions such as ears. The RenderMonkey project is available here; it includes the media files created by johny.

The diffusion profiles:

The composition of diffuse, sum of diffusion profiles and specular:

Comparison of a basic shader (left) with the skin shader (right):

Final result in high resolution:

Note that the seams are back because I added support for shadow maps and that basically killed my initial workaround. This issue could be addressed through the use of a spherical parameterization.