[Bf-cycles] Questions on Many Light Sampling

Brecht Van Lommel brechtvanlommel at pandora.be
Tue Mar 6 23:00:27 CET 2018

Hi André,

On Tue, Mar 6, 2018 at 10:07 PM, André Lourenço <alourenco.94 at hotmail.com>

> - What is the current estimation method for textured lights?
Textures don't affect importance sampling currently, except for the
background. There's various ways to deal with them:
a) Ignore the textures, assume a fixed value.
b) Take random samples on the light and average them to get an importance
c) Subdivide the light into smaller lights to importance sample the
texture, where you estimate the textured intensity for each part.
d) For mesh lights each triangle could be a separate light in the tree with
its own intensity estimate.

Either a) or b) would be already fine for GSoC.

> - When "Investigate balancing importance with background and portal
> lights" is proposed, "investigate" refers to performing benchmarking and
> implementing optimizations?
Currently we allocate a fixed % of samples to the background light, which
is not optimal. So the idea here would be to see if the background light
can somehow be part of the light tree or if the importance of the light
tree and background can somehow be balanced. The background is basically a
far away textured light so in principle it can fit in.

> - I would like to implement the Adaptive Splitting Heuristic (paper
> <https://sites.google.com/site/ckulla/home/many-lights>). It is ok to do
> it legally speaking? Since it might take priority from one other proposed
> topic, is it opportune or are there bigger priorities?
Most code in Cycles is based on such graphics papers, we don't have a
reason to think this specific paper would be a problem. The most important
thing for GSoC would be to implement the tree construction and traversal
from this paper that works with a single sample.

I would give adaptive splitting a high priority since without it this
method seems a lot less effective. But better handling of textures, mesh
lights, backgrounds or volumes would be ok too. Handling all of those cases
is too much for one GSoC project in any case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20180306/ec231d39/attachment.html>

More information about the Bf-cycles mailing list