frequently lost in thought

Next week the Google Summer of Code 2008 will be conclusively over. I will sum up my thoughts on this wonderful experience in a future post, adding some suggestions for prospective applicants as well.

Here, instead, I would like to detail my plans for the future of this project.

Development — Development will continue, but necessarily at a slower pace. At the end of October I’ll be attending the Blender Conference where I would like to show a couple of new features. Apart from that, though, what this project needs now is some “boring” refinement.

Blender Internal features — I’ll have to go through all the Blender Internal features and for each of them ponder if it is possible to support it. Unfortunately the very nature of the algorithm makes it impossible to support all features (some of which are pure hacks) but what’s in and what’s left out must be clearly stated to users.

Workflow design — In my opinion if you want to use Lightcuts, especially if you want to obtain indirect lighting, you have to plan ahead a bit; I can’t see, in general, the same light rigs being successful in both Blender “vanilla” and Blender Lightcuts. Matt Ebb, and many others for that matter, would be happier to see Lightcuts as a less invasive tool. Of course mine is a statement while Matt’s is a desire, so it’s easy to agree with both. Anyway, however this “fight” ends, I need to figure out how to integrate Lightcuts in Blender from a UI point of view. In this particular area I would like to hear opinions from users.

Merging — Some people are afraid that a project living in its own branch is at a greater risk of dying; for sure it’s at a greater risk of going out of sync. While it’s true that this project is fairly isolated code-wise, and that development could continue also on trunk, I feel more free to experiment in my own branch. As my confidence with the Blender codebase increases, I could also attempt some bolder refactoring of some rendering engine internals — and that would be better tested in a branch.

My idea is to merge after the Blender Conference, while the aim for the entire project is to be released in Blender 2.50.

Ok, enough words. Here’s a Sponza test, provided by Melon on blenderartists:

A Sponza rendering lit by a single area light, with 5 bounces of indirect lighting

The entire thread is worth reading in my opinion.

Ps. — Next week I won’t be working on this project, but this is a planned break as I resume my duties so don’t think I’m running away!

This week I’ve been busy with something rather unexciting: speeding up the light tree creation time. You might remember that, initially, I just implemented a O(n²) method in order to have a working prototype quickly; now I lowered that to O(nlogn) following advice from Miroslav Mikšík.

It is now possible to have several tens of thousands point lights without incurring in terrible tree creation times. This is particularly important when indirect lighting is added to the mix.

A simple way to add indirect illumination to renderers is to place several small lights on surfaces hit by direct lighting. This principle is used by a family of algorithms called instant radiosity, originally developed by Alexander Keller. A lot of research has gone into reducing the number of resulting lights, in optimizing their placement in the scene (so that, for instance, lights not influencing the final rendering get trimmed), and in overcoming some of the shortcomings of the algorithm, since it tends to suffer in some corner cases.

The final part of my Summer of Code project is indeed about creating a toy implementation of instant radiosity, in order to show a potential “killer application” for Lightcuts in Blender. I think it’s also important to have it in order to have a clearer idea on how to integrate Lightcuts from a UI point of view.

Ideally it would be nice to have just a button to press, without having to rework all the lighting differently, but I’m afraid that the user must have some awareness of the strengths and weaknesses of the algorithm in order to take full advantage of it. More on this in a later post.

Here are some very preliminary results from my initial experiments with virtual point light placement.

Textured area light with indirect lighting - Tree creation time: 00:00.54 - Number of (point) lights: 5966 (0l + 0s + 5966o) - Average cut size: 155.22 - Shadow rays: 153.77 (2.58%)

Textured area light with direct lighting alone (despite the stamp) - Tree creation time: 00:00.26 - Number of (point) lights: 3102 (0l + 0s + 3102o) - Average cut size: 134.83 - Shadow rays: 132.35 (4.27%)

Test scene - with indirect lighting - Tree creation time: 00:02.00 - Number of (point) lights: 18091 (0l + 0s + 18091o) (4900d + 13191i) - Requested error rate: 0.018 - Average cut size: 587.30 - Shadow rays: 582.20 (3.22%)

Test scene - direct only - Tree creation time: 00:00.43 - Number of (point) lights: 4900 (0l + 0s + 4900o) - Requested error rate: 0.020 - Average cut size: 567.16 - Shadow rays: 562.23 (11.47%)

(Yes, I am aware of the banding problems; it’s one of the issues I have to address next week before the Gsoc is over.)