I am happy to present you a new approach to compute indirect illumination and ambient occlusion in real-time using a pre-filtered geometry representation stored inside a sparse voxel octree, as well as a new approximate voxel-based cone-tracing. The sparse voxel octree is used as a proxy for occlusion information and indirect illumination, it supports dynamic objects and environments thanks to a new very fast voxelization algorithm that updates the octree structure and pre-filter geometry and lighting information.

This work has been done in collaboration with Miguel Sainz and Simon Green from NVIDIA, as well as Fabrice Neyret from CNRS and Elmar Eisemann from ParisTech.

[Update 30/06/2011]: Benoit Rogez wrote a very good article about our approach on 3DVF (in French) : here[Update 10/06/2012]: More details on the algorithm and the fast voxelization and octree construction can be found in my GTC 2012 presentation.

FPS and ms do NOT have a reciprocal relationship. FPS is a "full frame" measure, which is a useless measure. When we use ms, we are measuring only the rendering portion of the frame, which is the only relevant measure for including in real-world applications, and for comparisons with other approaches.

Also, sorry to keep focusing on the ms/FPS thing, but it's a frequent (and simple) problem that we can easily correct as a community. Always use ms. Never FPS. Let's say your technique has an option that improves visual quality, but you say it comes at a cost of 4 FPS. That information is useless. Was your application 9 FPS with the option off, and then 5 FPS with it on? Or 804 FPS off, 800 FPS on? If it's the former, the option is relatively very expensive, and if it's the latter, the option is relatively very cheap. Simplify our lives and give us ms =).

Our goal should be to the make the performance characteristics of our algorithms as easy as possible for others to understand and compare to other algorithms.

The results in that video are truly amazing. I was awed by the quality of the indirect shadows, and then I saw the indirect specular. Looking forward to finding out more at Siggraph, and seeing what optimized versions people come up with once it has been published for a while =)

"In my case, the code is ONLY doing rendering stuff ;-) So a full frame measure is actually representative of the performance of the rendering algorithm."

Surely there is some rendering overhead not related to your algorithm, right? You want to say how long your algorithm takes, not how long the direct lighting / shadowing takes, or how long it takes to clear the color and depth buffers each frame, etc. When you use ms and measure just the work of your algorithm, it allows people to know this and to know how much it would cost in their application as well.

"I increased render time by 10ms with this option" if the render time was 900ms before, 10ms is not bad.. but if the render time was 16ms its a huge cost."

Not quite - either way it took the same amount of time, which is what we want to measure in. In Brandon's example with a 4 fps difference, this delta represents a different amount of time depending on whether the base was 9 or 800. A drastically different amount of time.

There's another thing I'm wondering about, how scalable is this algorithm? For instance, if the voxels are bigger, does that speed up the rendering a lot, or only a little? Perhaps with voxels twice the size, the quality of the lighting would still be 'good enough', but take a lot less time..

@talden First thank you for your feedback :-)I never said that giving ms was not useful. Of course in a paper I will always detail the time taken by each step of the whole algorithm, and in this case it only makes sense to give ms. Here the goal was only to give an idea of the overall performances and everything measured is part of the algorithm (clearing the framebuffer is negligible in comparison to the rest of the frame). So don't worries these timings will be in the paper that is to come :-)

@LogicalError Larger cones, and so bigger voxels, does speedup the algorithm a lot. However, an important part of the time is also taken by the dynamic update of the structure. Also here, lower resolution voxels speedup the voxelization process.About scalability, the speed is highly dependent on the number of cones you trace, and so of the screen resolution. Here I am only using a 512^2 rendering resolution.

I'm not experienced at all with voxels but if I understand well, you have implemented what J. Carmack sometimes refers to "hybrid rendering", that-is-to-say you compute lighting by using a voxel octree but keep using traditional hardware rasterization (then polygons) to render objects, am I right?

If so, this approach proves here to be great as it combines some strengths of both techniques, I mean fast rendering in combination with a quite realistic lighting model. The same results could obviously be achieved using other techniques, at a (much) higher price though.This is a for sure a very good fit for relatively small scenes where most objects remain static. However I just wonder how it would behave in other situations:

- voxel rendering has the great benefit of requiring only those voxels to be streamed in large-scale / open-world environments. But with this hybrid approach, both geometry and textures PLUS voxels need to be loaded then, which would require more stream bandwidth, more memory budget and CPU time required than the other techniques. Nothing prohibitive when looking at end-user computers or next-gen consoles, but it's a drawback anyways :)

- how much does cost the octree's update for a single animated model like the hand? would it still be running at an interactive framerate if there were ten of them? Since the voxel octree only manages lighting, maybe there's the possibility to turn off its update for distant animated objects. This would make this technique even more interesting, but I don't know if it's possible and how noticeable this would be.