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.
The paper ha been published at Pacific Graphic. You can find the authors version of it on my research page:
http://www.icare3d.org/research-cat/publications/interactive-indirect-illumination-using-voxel-cone-tracing.html
[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.
Indirect lighting (global illumination):
High quality video: http://artis.imag.fr/Membres/Cyril.Crassin/GIVoxels/Siggraph11_GI1.mov
Ambient occlusion:
High quality video: http://artis.imag.fr/Membres/Cyril.Crassin/GIVoxels/Siggraph11_AO1.mov
June 24, 2011 at 3:21 PM
The crazy hand is a bit scary!
But results are great, nice work.
June 24, 2011 at 3:43 PM
Looks good!
What kind of hardware are you getting 25-70fps on?
(also, why fps and not ms as a metric?)
June 24, 2011 at 4:39 PM
Thanks :-) The framerate has been measured on a GTX 580.
About FPS vs ms, that's just because it measures the whole frametime, but you are free to do the inversion ;-p
June 24, 2011 at 6:29 PM
This is very neat!
June 24, 2011 at 9:04 PM
Looks promising. Congrats. Keep up the good work Cyril!
June 24, 2011 at 9:14 PM
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.
June 25, 2011 at 12:03 AM
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.
June 25, 2011 at 7:20 AM
Ah ça claque ! J'ai hâte de pouvoir lire l'article.
June 25, 2011 at 4:52 PM
Sounds like an interesting technique Cyril. I'm excited to learn more!
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.
June 27, 2011 at 5:57 AM
And the same is true with ms... "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.
fps, ms, whatever... give me mpix/s for a reference picture.
Anyways... this work kick booties left and right!
Congratulation Cyril on this great accomplishment.
June 27, 2011 at 10:56 AM
(Attention il y a une typo pour Vancouver)
Nice work !
Do you know at what time is scheduled your Paris presentation tonight?
June 27, 2011 at 11:29 AM
Merci pour la typo :-)
My presentation at Siggraph Paris is scheduled at 10h15 pm. Euh... who are you ? ;-)
June 27, 2011 at 6:32 PM
Juste magnifique O_O. La France va bien être représentée au Siggraph avec ça :D !!!
Avez-vous l'intention d'intégrer cette technique dans un moteur de jeu ? Ça serait magnifique de pouvoir en profiter !
Bonne Continuation :)
June 28, 2011 at 8:30 AM
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.
June 28, 2011 at 10:35 AM
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..
June 28, 2011 at 11:34 PM
Great stuff!
Do you have any experiences of tracing the AO towards infinity in order to use it to do occluded skylighting? Most of the AO examples seem to be local.
June 29, 2011 at 3:20 PM
@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 :-)
June 29, 2011 at 3:24 PM
@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.
July 2, 2011 at 8:06 AM
Does this support multiple dynamic lights?
August 5, 2011 at 3:18 AM
August 5, 2011 at 8:09 AM
Looks really nice, great work!
I agree the hand is a bit unnerving :)
August 5, 2011 at 10:53 PM
Hello Cyril,
Very impressive work, congratulations!
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.
August 30, 2011 at 11:38 AM
demo ?
:)
June 15, 2012 at 12:20 PM
Nice work!
I heard a variation of this technique is used in Unreal Engine 4
June 15, 2012 at 6:05 PM
Right :) http://blog.icare3d.org/2012/06/unreal-engine-4-demo-with-real-time-gi.html