still in love with underscores

My first week as a SoCer is coming to an end. I’ve been added to a couple of SoC-related mailing lists; those gave me the opportunity to really feel the international breadth of this program.

I’ve also had some exchanges with my mentor, Kent Mein. In particular, he reminded me that I should take care of external testers, should there be any. He’s right. In practice this means that maybe I should not delegate the light conversion/generation step to an external script, which would prove cumbersome to use for other people, and code that in C straight away instead. Originally I planned to do that later on as it is conceptually very simple but potentially longish to code; additionally, I would like to experiment a bit on different ways to do that, and Python would be way more flexible in this. We’ll see.

My own branch was created as well, and I finally have commit rights for Blender! Isn’t that cool? Far less cool was the horrendous breakage of Subclipse after a dry run of an svn merge command. There was no way to recover from it, and I had to disable Subclipse altogether. I don’t mind using svn from the command line, but this provided yet some more ground to question Eclipse CDT as a development environment. More on this in a future post.

Meanwhile, I started writing some code to test if my high-level design is viable. My hope is that the lightcuts project should eventually have only two entry points:

1. an initialization routine, that generates point lights and builds the three required trees out of them (one for omni lights, one for directional lights, one for oriented lights)
2. a “gimme the lights” routine that returns a different set of point lights per pixel/sample

Until now, I successfully created a fake step 1 that for each light in the scene creates another one, with random color and 1 unit displacement. This is a test image I kind of like:

Only the white lights were present in the scene.

Step 2 is a different story. Right now, the light list is iterated directly at various points in the code. My original plan was to add a lightcuts_get_light_list() API before each iteration, but on second thought, that’s not a good idea: I would have to allocate an actual list for each pixel/sample only to retain compatibility with existing code. The only other solution I can think of right now is to provide a sort of “iterator interface” to the lights list, along the lines of a get_next_light() method. In this case we trade an allocation overhead for a call overhead, so it could be worth to look for an other alternative.

This weekend I’ve been performing some preliminary experiments to get a feeling for what could be delivered by a lightcuts implementation in Blender.

In brief, the lightcuts algorithm is just a way to render insane amounts of point lights quickly, by adaptively selecting a different subset of the available lights at each pixel according to perceptual metrics. This means that it’s possible to have a grasp of how results would look like without actually implementing it, if you are willing to bear with huge rendering times.

The first bunch of tests concerned environment lighting. It required converting light probes into collections of point lights: to do this, I wrote a quick Python script that performs a Hammersley sampling of a light probe and places a new directional light at each sample position, with matching color and intensity (I was lucky that Blender.Image.getPixelHDR recently landed on svn), and 1-sample “ray shadow” mode set.

As a result, you should get something very similar to an AO pass with sky texture. Actually, it should be exactly the same calculation (bar any “distance” tweaks), but instead of sampling the environment using a different jitter table per pixel, you use the same sampling scheme over the whole scene. That of course defeats the very purpose of jittering, which is trading banding for noise, but please remember that lightcuts is designed to deal with very large collections of lights.

So far, I admit it’s no big deal. For sure, with actual lights you can also support specularity, as in the pictures; and AO shows a bit of the bias problem. But anyway, as far as environment lighting is concerned, even after a successful implementation is completed, the best you can get is still pretty similar to what you already have.

Things get more interesting if we add indirect lighting to the mix. Lightcuts is claimed to interact well with Instant Radiosity schemes: that is, you place a large number of small lights where the primary light hits the scene in order to simulate the first bounce of indirect lighting. To accomplish this, I preliminary rendered some color coded maps from the light’s point of view: positions, normals, and color. (By the way, this caused me some headaches because of the linear blending texture saturating at 0 and 1, which is a pity in the float buffer era).

Afterwards, I wrote another script that, given those textures as input, places a number of 180° spot lights into the scene, with color and intensity matching the hitting surfaces’ color and orientation with respect to light.

In these test scenes the effect of indirect lighting is a bit exaggerated to see it better, but you get the idea. It is important to stress that Instant Radiosity is an approximate technique with its own shortcomings that would need to be properly addressed in a serious implementation. Still, it looks promising to me.

Significant savings on render times should be obtained when you employ all those lighting sources together: environment lighting, area lights and indirect lighting. This is because lightcuts ultimately just deals with a collection of point lights, without caring about their original purpose. My hope is that this would enable artists to set up complex lighting configurations with several area lights without worrying too much of rendering times.

As a closing note: top blenderheads, like @ndy, are known to use lots of lights in their renderings; nonetheless, I guess even them would be shocked to see something like this:

Of course, in an actual implementation, end users wouldn’t be able to see all these individual lights in 3d view… fortunately!