Planet SoC

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:

A quick update from last week that I couldn’t find the time to finalize. I post it now as it discusses a couple of interesting issues. Btw, week numbering refers to the official GSoC timeframe. — UncleZeiv
The scene shown below — an ordinary Suzanne lit by 15000 colored lights — was sent by an early tester (thanks bullx) who found some noticeable artifacts when comparing the Lightcuts rendering to the plain one, despite following the instructions given in my previous post. It was indeed a bug that I finally found after a longish hunt. This is to say that early testing is indeed doable and welcome!

The Google Summer Of Code has officially started on Monday. I’ve been doing a fair amount of coding  since my last post and it is now possible to see something almost meaningful on my branch.
I finally managed to have all pieces of the puzzle in place. My initial attempt to hook the lightcuts algorithm to the renderer through a “lights iterator” interface turned out to be ill conceived: what I really needed was a callback mechanism to let Blender Internal evaluate the contribution of a single light. In the end this will require more changes to the render engine, but overall this technique remains pretty non-intrusive.

Focus on lowering algorithmic complexity and don’t perform other optimizations until their usefulness is demonstrated by thorough profiling: since I completely agree with this maxim, I feel obliged to explain why my latest lightcuts update seems to contradict it.
First of all, let’s recap: in order to select an optimal subset of the available lights per sample, a lightcuts implementation needs to maintain them organized into a binary tree. The leaves of this tree are the actual lights, while intermediate nodes represent clusters of lights. A cluster of lights is a sort of imaginary light whose position, intensity and orientation is somehow representative of all its children.