This week I’ve been busy with something rather unexciting: speeding up the light tree creation time. You might remember that, initially, I just implemented a O(n²) method in order to have a working prototype quickly; now I lowered that to O(nlogn) following advice from Miroslav Mikšík.
It is now possible to have several tens of thousands point lights without incurring in terrible tree creation times. This is particularly important when indirect lighting is added to the mix.
A simple way to add indirect illumination to renderers is to place several small lights on surfaces hit by direct lighting. This principle is used by a family of algorithms called instant radiosity, originally developed by Alexander Keller. A lot of research has gone into reducing the number of resulting lights, in optimizing their placement in the scene (so that, for instance, lights not influencing the final rendering get trimmed), and in overcoming some of the shortcomings of the algorithm, since it tends to suffer in some corner cases.
The final part of my Summer of Code project is indeed about creating a toy implementation of instant radiosity, in order to show a potential “killer application” for Lightcuts in Blender. I think it’s also important to have it in order to have a clearer idea on how to integrate Lightcuts from a UI point of view.
Ideally it would be nice to have just a button to press, without having to rework all the lighting differently, but I’m afraid that the user must have some awareness of the strengths and weaknesses of the algorithm in order to take full advantage of it. More on this in a later post.
Here are some very preliminary results from my initial experiments with virtual point light placement.
Textured area light with indirect lighting - Tree creation time: 00:00.54 - Number of (point) lights: 5966 (0l + 0s + 5966o) - Average cut size: 155.22 - Shadow rays: 153.77 (2.58%)
Textured area light with direct lighting alone (despite the stamp) - Tree creation time: 00:00.26 - Number of (point) lights: 3102 (0l + 0s + 3102o) - Average cut size: 134.83 - Shadow rays: 132.35 (4.27%)
Test scene - with indirect lighting - Tree creation time: 00:02.00 - Number of (point) lights: 18091 (0l + 0s + 18091o) (4900d + 13191i) - Requested error rate: 0.018 - Average cut size: 587.30 - Shadow rays: 582.20 (3.22%)
Test scene - direct only - Tree creation time: 00:00.43 - Number of (point) lights: 4900 (0l + 0s + 4900o) - Requested error rate: 0.020 - Average cut size: 567.16 - Shadow rays: 562.23 (11.47%)
(Yes, I am aware of the banding problems; it’s one of the issues I have to address next week before the Gsoc is over.)
Color bleeding and indirect lighting are features that I most want to see in this project, I hope that you have time to do it. Will you continue working on lightcuts after Gsoc? Thanks for all your work since the very first minute you spend on it.
Speeding up this feature is something very exciting, don’t think it’s “unexciting”.
Thanks for what you’re doing.
These tests look so nice. This is one of the coolest features I’ve seen added in a while.
Is it possible that you will be able to add support for glowing materials (those with an”emit” value) so that they can give off light to surrounding objects like the textured area lights? This would be so useful to be able to do this without needing radiosity. I don’t know how hard it would be to do this, however. This would be one of the coolest features added to blender and it looks like Lightcuts has the power to finally bring this into blender.
Thank you for all of your hard work.
\m/
@Juan Carlos: I will continue after GSoC, don’t worry
@Michael and DreadKnight: thank you!
@Steve: that’s certainly possible; you can already do that, more or less, by using a copy of the mesh to dupliface an arealight. For sure an automated method would be better. I’ll add it to my TODO list
Agreeing with Steve, I too would enjoy an emit value feature without the dupliface setup needed… But…. Alas, whatever heads our(users of blender) way is wonderful.. Your work thus far is AMAZING, especially given the timeline you’ve been on thus far. Your efforts will echo throughout many new creations by many of us. Thank you UncleZeiv!!!!!!
Oh, and, I’m soooo thankfuly you’ll still be developing lightcuts after Gsoc. Thank you again
totally agreed with Steve and D – Your work is already very, very impressive, IMO it’s the most needed feature in Blender.
Is the number of light bounces limited somehow by the algorithm ( or Your implementation ) or not? What about refraction ( and caustics )?
Really very impressive work. Even the test renders are already quite beautiful despite the banding problem. Thank you so much for this great new feature!
Holy guacamole! That looks so awesome.
This is something I’ve been hoping for for
some time now. I’m really excited to finally
see this happening for Blender.
You guys rock!
For instant radiosity, you should look at Metropolis Instant Radiosity, this is a very powerful way of automatically generating the VPLs (virtual point lights), with many many very good properties, not the least of it being that by construction, all the VPLs bring the same amount of power to the image, meaning that it massively reduces the variance of the resulting estimator. But as all “instant radiosity” methods, it only optimally manages diffuse scenes.
http://www710.univ-lyon1.fr/~bsegovia/papers/mir.html
This is awesome. This is such a much needed feature set for blender its not even funny. Lighting is one of the most important things in 3D and your lighting system is super cool. Your project may eliminate the need to render in other rendering systems in order to get good results. I think the defining feature of Indigo is its lighting but it takes forever to get an image with good results for a scene of any size. I mean 1 week render times for a single frame is frustrating. So you are doing this lighting with render times of only 30 seconds, and 1 minute thats just crazy cool. Man thats fast. Thanks for continuing the project after GSOC. Yeah the Emit setup would certainly be a heavily desired feature. I am very excited about this project. Thank you for all of your hard work.
Cheers,
Nate Nesler
Truly amazing stuff. Thanks for your hard work.
very amazing
Thank you all for your support!
@tarlack: yes, I am aware of Metropolis Instant Radiosity and I have also read the paper; it looks like the definitive IR variant right now. It doesn’t seem trivial to implement though. I see it as a medium/long term target.
@MatrixNAN: well rendering times are not that low… My typical rendering time is 10 minutes, but with quad cores and optimized builds I think you can go well under 5. Future work, like adding “reconstruction cuts”, could also lower rendering times even further.
Wow, this is going to be a great feature for BI! Are those rendering times in the top right corner minutes or seconds?
I implemented MIR, if one day you want to implement it and have difficulties, do not hesitate to contact me, I would be glad to help you
It has quite a lot of theoretical prerequisites, but it truly worth it ! or you can also go on ompf.org, it is a raytracing oriented forum and you will have a very good support (the guy that made MIR uses this forum, as well as some other gurus !)
This is amazing, thank you lots for putting your time into developing such a neat feature. Along with this… the next best thing would be to have a built in exporter for Indigo
.
Best of luck
@Uncle Zeiv: Still 5 to 10 minutes is a huge improvement over 1 week. You can get renders done in about 2 hours if you only have 1 model in Indigo but the moment you move up to a good number of models in a scene that render time just goes through the roof. I am afraid I can not help out on the coding I am already coding a rigging system toolset for blender.
@Pash Indigo would have to become open source for that to happen and that is probably not going to happen so it will remain a plugin. Not to mention I suspect they use a totally different light system than what light cuts is doing so you would not gain but rather loose at render time in Indigo when it trys to process thousands of lights. Right now the render times are horrible for just handling about 4 or 5 lights. Like I said 1 week render times, with thousands of lights it might be a decade before it finishes rendering one frame of animation. Indigo gives great results but it takes forever to render.
Cheers,
Nate Nesler
Awesome job
Thanks for your great project (please keep it up)
Thank You! This is just amazing!
(for me it will greatly improve quality of baked shadow maps for game development).
Just incredible!!!
Great ! this would be awesome, but , is this a step to getting real GI ? or is it just a fix ?
thanx !
Hi,
is this being developed for Blender ?
There’s people talking about it…
http://blenderartists.org/forum/showthread.php?p=1309268
can you show a pic with the location for the lamps
location to see the indirect effect
this seems to be very promissing
is it going to be included in bledner 2.5?
keep up the good work
& happy blendering
Thanks
Very nice work!
It’s nice to hear that somebody actually read my paper.
Thanks and keep going…
@Rickyblender: there are talks of an overhaul of the rendering system right after Blender 2.50… I’ve not talked to anybody about that but lightcuts could be held back until then. Besides, I won’t be able to work on this project in the immediate future (but I’m still committed to continuing it).
@Miro: your paper was very helpful actually! Congratulations