More indirect lighting stuff

This week I have been busy completing the indirect lighting part of my project, but this turned out to be harder than expected. The problem was not particularly the algorithm itself, as I’m currently implementing a naive variant. As a reader pointed out, the state of the art in instant radiosity is currently Metropolis Instant Radiosity by Benjamin Segovia, but implementing that is not trivial and is left as future work.

I actually had a hard time figuring out how to read surface colors, which is something I need to color indirect lights and obtain color bleeding in the end. In the end I came up with some very hackish code that for sure wouldn’t be accepted in trunk. On the other hand I can’t see a cleaner way to do that without some changes in the existing Blender codebase. I have to talk to some other developer and see what’s the best thing to do.

Anyway, right now I have the ability to generate 1st and 2nd bounce indirect lighting from area lights, taking colours into account. I was able to obtain a rendering like this one:

"Unfinished Match" with indirect lighting

"Unfinished Match" with indirect lighting - Tree creation time: 00:04.64 - Lights: 19968 (0l + 0s + 19968o) (10000d + 9968i) - Error rate: 0.020 Max cut: 1000 - Average cut size: 362.88 - Shadow rays: 345.63 (1.73%)

The interesting thing is that this model was previously lit by a very complex lighting setup in order to fake indirect lighting. This rendering was obtained by placing a single area light behind the window.

Here are some more tests:

Color bleeding test

Here there's an area light near the wall, turned upwards at 45°.

Hangar test

Hangar test - Here I exaggerated indirect lighting through post-process.

  • Trackback are closed
  • Comments (11)
    • Juan Carlos
    • August 17th, 2008

    This is the stuff that really turn me on, better than pron haha. I hope that implementation of metropolis instant radiosity comes along in the next few months and with good render times (let me dream on it :) in order I could rely in Blender internal renderer and all of its features (baking, nodes etc) instead using and fighting (especially in animations with jumping photons) with a external photon mapping renderer in my workflow.

    • Sienio
    • August 17th, 2008

    Wow! It is possible to create mesh lights with lighcuts? Anyway Great Job! Finally there are simple GI in BI :P

    • tuqueque
    • August 17th, 2008

    Whoa!… i really didn’t expected multiple bounces implementation!… i thought it was going to be just 1st bounce GI for now and later multiple bounces would come.

    Thanks for your work! really!… this is one of the major features Blender users have been waiting for…

    One thing, is sort of a question/feature request… will it be a way for the user to EXCLUDE OBJECTS from GI calculations?… in very complex scenes with hundreds of objects that would be really necessary… I propose a simple UI control where you could set an object (or multiple objects at the same time) to generate GI or receive GI (or both).

    Again, thanks for your hard work!

  1. OMFG! Can’t wait to use this one!

    I really need GI at work (professional 3d modeler) for interior scenes with furniture xD

    Keep up the good work mate!

  2. @Sienio: meshlights is the single most requested feature… I’ll add it soon, don’t worry ;)

    @tuqueque: interesting feedback, thank you. Excluding objects would be possible but not trivial, I have to think about it. Anyway keep in mind that this is an approximated technique, rendering times shouldn’t be particularly affected by scene complexity.

    @Juan Carlos and DreadKnight: thanks!

    • melon
    • August 19th, 2008

    I wonder how render time comparison would look with Lightcuts and other renderers (like mental ray, yafaray) with indirect light support? Did you menage to do some test of that kind?

    By the way: excellent work – it is really important to have sort of GI in Blender.

    • tarlack
    • August 20th, 2008

    in fact, I’m wondering…generating tens of thousands lights by MIR could take quite a long time, but you would maybe have a stability that could make it possible to use it for animation (MIR being a bidirectional algorithm, it takes the point of view into account to place the lights, and thus when something change you have to regenerate the lights)…here, the goal would be to have the same apparent lighting for two different renderings of the same scene, which is not the case with a low number of lights…I think I will have a look at lightcuts later !

  3. One area light!! WOW!
    Keep up the good work!

    • freeqstyler
    • August 29th, 2008

    Well, I’m really impressed! At least we have GI in Internal ;) But render crashes when SSS is turned on, would you fix that? Anyway, great job, UncleZeiv!

  4. Your work is fabulous.
    When I saw your test with color bands and an area light turned upwards at 45°, one thing pointed in my head, in real world this light wouldn’t be powerful enough to have a second bounce. Maybe I missed or don’t understand something, (I’m not a big pro, furthermore, like you can see English is not my native language), but I feel the one bounce render more realistic than with two.
    Great work anyway.

  5. @Michael: in these initial tests the impact of indirect lighting was exaggerated; moreover, I’m perfectly aware that my implementation of “instant radiosity” does not produce accurate results, but my main interest was in showing what can be achieved using Lightcuts.

    Thank you all for showing your interest in this project!

Comment are closed.