[Bf-cycles] Varying number of samples per pixel

[Brecht Van Lommel]

Storing the number of samples is usually not needed, and often impractical
to combine with other sampling decisions taken along the path.

It's difficult to tell without implementation details, what is the exact
reason samples must be discarded? Transporting rays to another surface
sounds pretty similar to BSDF scattering, where we use importance sampling
and divide the throughput by the probability density function (pdf).
Basically rather than counting the number of valid samples, we increase the
weight of the valid samples to compensate for the invalid ones.

On Fri, Jun 23, 2017 at 6:59 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:

> Hey,
>
> the easiest approach is: store the number of samples per pixel in an
> image, divide the final image by the samples image.
> I would avoid discarding samples as you will waste compute power, just
> find a way to reduce samples from the start (it needs a redesign to change
> how the kernel works), Lukas Stockner may have more idea about this as he
> tried to do an adaptive sampler before I guess.
>
> cheers,
> Mohamed Sakr
>
> On Fri, Jun 23, 2017 at 1:51 PM, Escot Lucas <lucas.escot at ens-lyon.fr>
> wrote:
>
>> Hello everyone,
>>
>> I originally asked the following question on the #blendercoders IRC but
>> was advised to send it here.
>>
>> *Context*: I am currently working on a modified version of Cycles, in
>> which the user have control over how light paths behave: they are able to
>> transport/move rays hitting a specific surface to another one.
>>
>> Such a modification implies that during the path tracing process, *some
>> paths/samples must be discarded* (to do that I simply don't add their
>> contribution to the final image, in kernel_path.h/kernel_path_trace()).
>>
>> It means some pixels are downsampled since some of their samples might be
>> discarded, however Cycles still divides for each pixel the total
>> contribution by *the total number of samples* which is assumed to be
>> constant over the entire image.
>>
>> Hence my question: is there a simple way to make this last operation
>> (averaging pixel samples) rely on a local number of samples, for each
>> pixel, rather than a constant amount of samples for the entire image?
>>
>> I hope this is the right place to ask such a question, and that some of
>> you will have an answer.
>>
>> Regards.
>> --
>>
>> Lucas Escot
>> L3 Informatique Fondamentale
>> ENS de Lyon
>> Telephone: 06 88 62 63 86
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20170623/c8a905ed/attachment.htm