Planet SoC

Tomorrow I’ll head towards Amsterdam to attend my third Blender Conference in a row. This time, besides meeting the usual lot of cool people, I’m also going to talk about my work on lightcuts — and I hope to get some useful feedback as well.
Anyway: in the last couple of days I took the time to implement some minor stuff I had been postponing for a while.
First of all, support for baking is now in. Just bake with the “Enable Lightcuts” toggle pressed: it should work now. I have to admit that this did not go through much testing, so please report any strange behavior.
A second addition was compatibility with the SSS feature from Blender Internal. Previously, it used to crash outright. Now, it gives pretty good and smooth results:

I finally surrendered and added “multiple representatives” to my Lightcuts implementation. This essentially means that you have an option to select noise instead of banding.
When computing the contribution of a cluster, you need to select a representative point light, whose position will be used to compute visibility and whose color will be used to shade the pixel. The original Lightcuts paper selects this representative light at a global level. With multiple representatives you choose a different representative at each sample.

Next week the Google Summer of Code 2008 will be conclusively over. I will sum up my thoughts on this wonderful experience in a future post, adding some suggestions for prospective applicants as well.
Here, instead, I would like to detail my plans for the future of this project.
Development — Development will continue, but necessarily at a slower pace. At the end of October I’ll be attending the Blender Conference where I would like to show a couple of new features. Apart from that, though, what this project needs now is some “boring” refinement.

This week I have been busy completing the indirect lighting part of my project, but this turned out to be harder than expected. The problem was not particularly the algorithm itself, as I’m currently implementing a naive variant. As a reader pointed out, the state of the art in instant radiosity is currently Metropolis Instant Radiosity by Benjamin Segovia, but implementing that is not trivial and is left as future work.

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.

Textured area lights turned out hugely popular, so now it’s hard to live up to expectations I guess!
This week’s work was indeed far less exciting: I worked on supporting more material features, as so far only lambertian diffuse and phong specular where supported. Now, all diffuse shaders are supported.
Every single shader must be specifically supported as we need to be able to answer this question: what’s the maximum value that a specific pixel, shaded this way, may assume over a bounding box of point lights? You don’t really need the exact maximum value, so a ridiculously large number would always be a “viable” answer. On the other hand, you want the bounding value to be as tight as possible, because if the error turns out to be very low, you may decide to skip all the lights further down in the light tree, thus saving rendering time.

One of my favourite pictures from the original Lightcuts paper is an office scene lit exclusively by a tv screen. You can do that with textured area lights.
In Blender you can already link a texture to a light, but the outcome is a sort of texture projection, which is useful if you want to fake effects like light passing through a tree without actually computing the visibility: that comes of course very handy for cutting rendering time, to have artistic control on shadowing, etc.
What I mean here with textured area lights, on the other hand, is actually modulating the color and intensity of the light throughout its area. This way you can obtain the effect of lighting coming from tv screens, large windows with varying lighting conditions, and even area lights with custom shapes. Here are some examples.

Apologies for not having updated my blog recently. There’s quite a lot of stuff I have yet to blog about and I’ll surely do that in the near future. This week is halfway through the Summer of Code and it’s midterm evaluation time. Having been scolded for the lack of coolness of my rendering tests during the last developer meeting, I took the time to grab some better looking model and arrange more interesting tests. You can find my midterm report, together with said renderings, on Blender’s wiki. A warm thank you to the Kino3D guys who helped a lot in the process.

These days I’ve been working on adding support for oriented lights. It’s mostly there, even though there are a couple of missing details and the current code is obviously slower than it could be.
Still, like in my previous post, I can’t resist posting another revisited preliminary test, now rendered with actual lightcuts code.

And the corresponding false colour image:

I have just added support for directional lights on my branch. Using more than one “sun” light may sound weird, but that’s actually how you transform environment maps in a collection of point lights, as each pixel ideally represents an infinitely distant illumination source.
So I couldn’t resist going back to my preliminary tests, but this time running them with the actual code! Here’s Suzanne again under the Eucalyptus Grove light probe: