still in love with underscores

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.

By misspelling awk during a search, I’ve come to know a very useful utility: ack. I wholeheartedly suggest to install it and use it as a drop in replacement for grep in most circumstances.

Basically, it’s a developer-friendly grep that, by default, ignores many annoying things that tend to get in the way nowadays, such as .svn folders. Other common options, such as recursiveness and “operate on all files in this directory” are assumed without the need of explicitly typing them. The output is structured, colored and highlighted in a meaningful and useful way — but it still plays well in a pipe, where it reverts to a more sober, grep-like output. It maintains a small (but extendable) database of filetypes, so that you can ask for specific categories of files to be included or not: for instance –noshell ignores .sh, .bash, .csh, .tcsh, .ksh, and .zsh files.

It’s also actively maintained.

It’s already an indispensable tool for me. Go grab it, you won’t regret it!