still in love with underscores

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.

By the way, as a SoCer I got to visit Google’s London office today. I was glad to have my Blender t-shirt handy for the circumstance. During the tour I’m pretty sure I saw a couple of guys editing a video using Blender on an enormous screen. Overall the visit was very inspiring and, you know, a free lunch is always welcome!

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:

Please note that the AO image is there just to give a very rough feeling of how the two could compare — of course energy should be matched more carefully and parameters could be tuned better. Comparison with approximate AO would be useful as well.

Here’s another test using a hand-painted environment map:

In both tests the average cut size (the number of lights actually evaluated per pixel) is pretty low — see how dark the false color images appear. On the other hand the shadowing doesn’t look entirely convincing; still, it looks like a good starting point to me!

All images were rendered at OSA 5.

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.

Right now the technique supports omnidirectional lights (“Lamps” in Blender parlance), Lambert shading, only diffuse. Through the UI it’s possible to change the maximum allowed error and the cut size — that is, the maximum number of lights taken into account per sample.

Early tests show that the lightcuts version consistently outperforms the traditional rendering pipeline, even for fairly small amounts of lights. Results are not always correct though, especially when complex occlusions are present.

Let me clarify that although I am already receiving useful feedback from testers, there is a long list of limitations you have to be aware of before playing with my test builds. Here is a minimal and possibly incomplete checklist:

• raytracing and shadowing must be enabled! This is not a current limitation: Lightcuts doesn’t make sense otherwise
• all materials should be only diffuse, employing the Lambertian model (current limitation): disable specularity and/or set it to black
• any other feature is not supported yet; in particular, ensure that the Bias toggle is turned off, or results could differ significantly
• all lamps should be omnidirectional (“Lamp”), with Inverse Square falloff, and ray shadowing active
• please ignore QMC settings: I am really using the old “single sample” lamps, not accessible from the UI anymore; fiddling with the settings could lead to inconsisten settings and eventually to crashes
• it goes without saying: disable AO, SSS, whatever feature doesn’t look like a “plain” feature

I’ve also added a new render layer called “False Color“. It’s a visual debugging tool that shows per-pixel color-coded information. Right now, the red channel shows the ratio between used lights and maximum cut size: when it’s dark, it means that the algorithm took advantage of its metrics to aggressively save calculations; somewhat unintuitively, the most expensive parts to compute are the dark areas (in the actual picture, not in the false color one): having a relative error criterion means requiring a very accurate calculation precisely where the signal is weak, and that’s when the “max cut” limit is hit.

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!