Lightcuts: week 2

UncleZeiv's picture

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!
On the other hand, the reference 800×600 rendering using the traditional pipeline, according to the tester, took nothing less than 4 hours (it’s not displayed here). I have to admit, though, that this is not a fair comparison, since you can’t select “pure” single sampled shadows from the UI for the traditional pipeline — you are always forced to use the better quality, but slower, QMC code. [Note: I restored the possibility to select singled sampled lights from the UI in revision 15183.]
I don’t use that because in this context you don’t care if a single light is actually low quality or produces ugly hard shadows: on average the contribution from a single light will be fairly small and will be softened and corrected by the contribution from the other lights. Alas, this may not be the case if a small number of lights is significantly more intense than the average; that situation may require a special treatment.
Error comparison
Finally, I wanted to show an example of false color renderings, which are an invaluable tool to see at a glance how the algorithm is performing behind the scenes. Each color channel bears a different meaning — which is, by the way, liable to change frequently during development (it already has a couple of times).
Right now, the red channel is the most important and is proportional to the ratio between the number of evaluated lights and the maximum number allowed, that is, the maximum cut size. (If this figure is higher than the current number of lights, the latter is used).
As you can see from the picture, more lights get evaluated in darker regions: this may sound counterintuitive but is the direct result of using a relative error metric. The darker the region, the lower the absolute error allowed. This is particularly apparent in the second rendering, where a higher error threshold was selected.
The second picture gives also an idea of how image quality degrades by raising the allowed error.

Organization: Blender Foundation Original: Source