[Bf-cycles] Distance Culling of Lamps?
marco.gzt at gmail.com
Wed Feb 4 17:31:46 CET 2015
Couldn't D832 be merged into master if we're in Bcon2? I'm currently
working on scenes with several lamps which could benefit.
Would this patch help "many light" scenes? Right now is the worst scenario
i encounter with Cycles.
As soon as i add 15+ lamps, rendertimes and noise go skyrocket, even if
they're set to 0-1 bounce and are same datablock.
I suppose it's high priority for Gooseberry too?
BTW has some experiment been made with this method by Cessen? ->
2015-02-04 8:56 GMT+01:00 Sergey Sharybin <sergey.vfx at gmail.com>:
> Don't really think distance-based culling for lamps is the way to go. Lamp
> might be really far away but contribute reasonable amount of light still.
> Also, for sub culling would not work at all :)
> What's more interesting IMO is ignoring light which does not contribute
> much energy. I had WIP patch in the patch tracker for that which needs some
> tweaks: currently it operates with PDF which is not totally correct, it
> should evaluate lamp energy (which is relatively cheap) and skip BSDF
> evaluation if energy is lower than a given threshold.
> That would give nice consistent optimization i think, which should also
> tend to be less flickery in animations.
> Link to the patch for those who're interested:
> On Wed, Feb 4, 2015 at 2:22 AM, Matthew Heimlich <matt.heimlich at gmail.com>
>> This is already done to a certain extent by cycles automatically.
>> On Feb 3, 2015 4:19 PM, "Zauber Paracelsus" <zauber at gridmail.org> wrote:
>>> Would it be possible, through a new lamp setting, to support
>>> distance-based culling of lamps? The basic idea is that lamps would not
>>> be sampled if they are far enough away from the area being sampled,
>>> thereby cutting down on rendering time.
>>> This can already be done to a degree by using nodes via the Ray Length
>>> output of the Light Path node, and I find that in complex scenes with
>>> numerous surfaces and several lamps over a large area, it can reduce
>>> rendering times by roughly half.
>>> However, there are two flaws with this approach:
>>> 1) Ray Length only measures the length of the current ray, meaning it
>>> could still be sampled despite being a greater distance away.
>>> 2) Ray Length is supplied after a bounce is calculated (I think),
>>> meaning it would not be fully sufficient to stop the lamp from being
>>> If distance culling for lamps is supported directly within blender,
>>> however, then it would perhaps unlock larger performance gains because
>>> it would stop the lamp from being sampled before any bounces are
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
> With best regards, Sergey Sharybin
> Bf-cycles mailing list
> Bf-cycles at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles