[Bf-cycles] Distance Culling of Lamps?

[Marco G]

I see, thanks.
Don't know if Cycles does already something similar, or it is something
equivalent to the light treshold patch but
this Open Source renderer has a paragraph about handling many lights, just
scroll down a bit after Tone Mapping paragraph:

http://noobody.org/is-report/other.html

Full engine source git: https://github.com/tunabrain/tungsten

MG


2015-02-04 21:58 GMT+01:00 Sergey Sharybin <sergey.vfx at gmail.com>:

> Well, i would like to switch it from pdf check to energy check first. Just
> need a bit of time for that.
>
> But be aware it also depends on the lamps setup. For example if they all
> are close to your object that patch wouldn't reduce any noise.
>
> I didn't look into that particular work in details, but looked into
> lightcuts. That would be interesting to play with at least and see how it
> goes.
>
> On Wed, Feb 4, 2015 at 9:31 PM, Marco G <marco.gzt at gmail.com> wrote:
>
>> 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? ->
>> http://lists.blender.org/pipermail/bf-cycles/2014-June/002021.html
>>
>> Regards,
>> MG
>>
>>
>> 2015-02-04 8:56 GMT+01:00 Sergey Sharybin <sergey.vfx at gmail.com>:
>>
>>> Hi,
>>>
>>> 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:
>>> https://developer.blender.org/D832
>>>
>>> On Wed, Feb 4, 2015 at 2:22 AM, Matthew Heimlich <
>>> matt.heimlich at gmail.com> wrote:
>>>
>>>> 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
>>>>> sampled.
>>>>>
>>>>> 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
>>>>> calculated.
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> With best regards, Sergey Sharybin
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> With best regards, Sergey Sharybin
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150205/15b3e49a/attachment.htm