Monthly Archive for June, 2008

Lightcuts: oriented lights

Published
by
UncleZeiv
on June 25, 2008
in Blender, Coding, GSoC 2008 and Graphics
. 1 Comment

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.

Indirect lighting

And the corresponding false colour image:

Indirect lighting scene (false colour)

The original test took almost an hour to render, at 400×300 OSA5. This one took ten minutes at 800×600. True, the images don’t look exactly the same, but that’s because I changed the falloff type of the virtual point lights to a more realistic inverse squared. Still, the speed improvement looks pretty good already!

Yes, I am perfectly aware that the shadow from the sun suffers from aliasing problems. This issue will be addressed somehow, so don’t worry about that.

Please note that the virtual point lights have been placed by a custom (and pretty hackish) Python script; generating them automatically is something that I definitely want to do in the future, but is not strictly speaking part of the current GSoC.

My plan in the near future is to complete the basic feature set in time for midterm evaluation — that is, adding support for specularity and for the other diffuse shaders available in Blender. This is holding back some other things I would like to do as soon as possible, such as releasing a couple of Blender scripts to render from environment maps and to do basic indirect lighting, and squashing the bug that is causing this video to flicker like crazy.

Lightcuts: directional lights

Published
by
UncleZeiv
on June 20, 2008
in Blender, Coding, GSoC 2008 and Graphics
. 5 Comments

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:

Eucalyptus Grove test

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:

Handpainted environment map test

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.

Lightcuts: week 2

Published
by
UncleZeiv
on June 15, 2008
in Blender, Coding, GSoC 2008 and Graphics
. 1 Comment

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.