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.

Quick comparison of original algorithm vs. multiple representatives option; the latter is currently significantly slower but a number of optimizations are still missing

Quick comparison of original algorithm vs. multiple representatives option; the latter is currently significantly slower but a number of optimizations are still missing

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.

  1. Nice! Banding was something I noticed in previous lightcuts renders.

    I don’t understand how exactly this feature breaks the workflow, but I suppose there are good reasons to not rush the integration.

  2. wow that is great, I have no idea how this works but its definatly better to deal with noice than banding

    • CenF
    • October 8th, 2008

    About the flicker on animation, just a crazy idea from a user who doesn’t know about the technical aspects:

    Would it have good results if, instead of calculating the lights tree for each frame, it was calculated every, for instance, 5 frames and then interpolate between each tree to give a smoother transition?

  3. @CenF: I’m not sure it would have good results, but the point is that interpolating the trees wouldn’t be trivial as far as I can see. In “reconstruction cuts”, different cuts from the same tree are interpolated in image space during a single frame, and that’s already non trivial. I think coding a superior instant radiosity solution (e.g. a more stable one) would be a better time investment.

    • blenderificus
    • October 9th, 2008

    very nice work on the new method, MUCH better result on the banding than the original, thank you for your continued contribution

    • CenF
    • October 9th, 2008

    Thanks UncleZeiv for answering. It was just an idea that I didn’t want to keep to my self. Thanks for everything you are doing.

  1. No trackbacks yet.