Lightcuts: multiple representatives
I finally surrendered and added “multiple representatives” to my Lightcuts implementation. This essentially means that you have an option to select noise instead of banding.
When computing the contribution of a cluster, you need to select a representative point light, whose position will be used to compute visibility and whose color will be used to shade the pixel. The original Lightcuts paper selects this representative light at a global level. With multiple representatives you choose a different representative at each sample.
The current implementation required some code refactoring, so that I ended up being a bit cautious about correctness — read: a number of optimizations are still missing. A lot of testing is still required but, as always, I rely upon my friends at blenderartists who are doing a wonderful job stress testing the system and reporting their feedback.
In different news, the insane amount of bug fixing that has been going on at the end of the Apricot project, led many developers to plan a new release before diving headfirst into the enormous 2.50 undertaking. As far as I understand, Blender 2.48 will include not only bug fixes but also new features, including some of the amazing work my fellow soccers did this summer.
As for my project, while the code itself is in a fairly acceptable shape, it will take more time to merge. Unfortunately, even though the code is not invasive at all, the concept of lightcuts is not that easy to integrate cleanly in the current Blender workflow. And we all know that Ton would rather miss a feature than pollute the user experience with an alien concept; this error has been made in the past and now core developers are stricter on this — and I don’t blame them at all. I’m waiting for the Blender Conference to have some input or even some enlightening discussions with them about this delicate part of the work.