[Bf-cycles] Efficient sampling of many lights

Nathan Vegdahl cessen at cessen.com
Thu Jun 26 18:11:00 CEST 2014


> Is there any downside about such approach?

It's not well-tested, for one.  So I doubt I know all of its drawbacks
yet.  And it still needs more research, IMO.

Specifically:
- I've only tried it with grey lambert surfaces.  Dunno how it would
impact glossy surface rendering, SSS, volume rendering, etc.
- Research is needed to see how it behaves with e.g. spot lights and
other lights or light emitting surfaces with strong directionality.

Also, for the technique to work each light (or light emitting object,
if you take them into account) needs to have its total emission energy
estimated.  I don't think that's too onerous a requirement, but it
might be tricky if you want to include e.g. an object or volume with a
complex emission shader in the technique.

--Nathan


On Wed, Jun 25, 2014 at 12:55 PM, Marco G <digitalbath86 at hotmail.com> wrote:
> I've seen this back in that forum and tought looked great indeed.
> Is there any downside about such approach? Because from what i can see it
> would be great to have.
>
> Many times in my scenes branched PT isn't beneficial, but with simple PT +
> many lights it gets impossible when dealing with tens of lamps.
> So if standard path tracing could be optimized for many lights scenarios
> with this technique, i really wish someone has the ability to add it
>
> I'd love to hear Cycles devs opinion.
> Regards
>
>
>> Date: Mon, 23 Jun 2014 16:34:16 -0700
>> From: cessen at cessen.com
>> To: bf-cycles at blender.org
>> Subject: [Bf-cycles] Efficient sampling of many lights
>
>>
>> I had mentioned this to Brecht a while back, but since he won't be
>> working on Cycles anymore I thought I'd drop a general note here.
>>
>> Currently Cycles either uniformly randomly chooses a single light to
>> sample for each ray hit, or it samples all lights for each ray hit.
>> The former significantly increases noise as you add more lights to a
>> scene, and the latter significantly slows down rendering as you
>> approach large numbers of lights. As far as I know, this is a problem
>> common to all path tracers.
>>
>> In the process of writing my own toy renderer, I came up with a method
>> that significantly improves on this problem and can efficiently sample
>> among many light sources. I outline the technique in this post on
>> ompf2, which includes some example before/after renders:
>> http://ompf2.com/viewtopic.php?f=3&t=1938
>>
>> The technique is not thoroughly tested, as my renderer only supports
>> limited light and material types. And it surely needs more design and
>> development work. But it seems to work well, and especially for
>> scenes with hundreds of lights or more it provides an enormous
>> benefit.
>>
>> I don't currently have any plans for developing on Cycles, but I'm
>> noting the technique here just in case anyone is interested in
>> attempting to implement it in Cycles.
>>
>> --Nathan
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>


More information about the Bf-cycles mailing list