[Soc-2018-dev] Weekly Report #06 - Many Light Sampling

[Brecht Van Lommel]

Great work!

For distant lights I'm not sure about the best solution, some brainstorming:

Building a separate light tree over distant lights should be possible by
leaving out the inverse square distance term and world space bounds? The
importance for the root node of the regular and distance light tree can
then be used to pick which one to sample.

Having both regular and distant lights in the same tree seems possible as
well, if each tree nodes stores a separate "regular energy" and "distant
energy". The world space bounds would only be used for regular lights, the
orientation bounds could be shared, and the importance for both types of
lights would be summed together. I'm not sure what would be most efficient,
a single unified tree or two separate ones.

In principle the background light can be in the same light tree as well,
though because it doesn't have a clear orientation there may be no benefit
compared to just handling it outside the light tree. I should be possible
to compare the total energy from the background light and the estimated
energy from the light tree root node for this.

You could also imagine splitting up the background importance map into e.g.
8x8 tiles, and then put those tiles as individual lights into the light
tree. That would give you  more unified sampling. Once the BSDF orientation
is taken into account for light tree traversal it starts to look a bit like
BSDF x environment map product importance sampling algorithms. Again I'm
not sure how big the benefit would be in practice, if we do this naively it
may well end up being worse in some cases due to extra traversal cost or
loss of sample stratification, and it's probably out of scope for GSoC
anyway.


On Fri, Jun 22, 2018 at 10:59 AM Erik Englesson <erikenglesson at gmail.com>
wrote:

> Hi all,
>
> Today is Midsummer <https://vimeo.com/39345149> in Sweden, so I will be
> off earlier than usual. Here is my report for this week:
>
> *This week*
>
>    - Light picking PDF
>    - Previously the probability to pick a certain lamp was 1/num_lamps
>       and the probability to pick an emissive triangle was
>       area_of_triangle/total_triangle_area, and if both lamps and emissive
>       triangles were in the scene then the probability is half of the one
>       mentioned.
>       - With the new light BVH, we pick lights with different
>       probabilities and the code has now been changed to reflect this. Now we
>       have separate functions for calculating the probability of picking a
>       certain light and the probability of picking a particular point on the
>       light. The combination of these two probabilities becomes the final PDF.
>       - For multiple importance sampling, we need to be able to calculate
>       the picking probability for any light(as was kindly pointed out by Stefan
>       Werner). I have now added code to do this. Given a light, it figures out
>       which leaf node in the light BVH the light belongs to. Then starting from
>       the root, the picking probability is calculated while traversing the light
>       BVH down to the particular leaf.
>       -  Support for distant lights
>       - From what I can see, distant lights are not handled in the paper.
>       In this first iteration of distant lights support, these types of lights
>       are treated as a special case. They are not being added to the light BVH as
>       other lights since it is not possible to calculate their importance(no
>       bounding box). Instead, with a certain probability, I pick a light from the
>       light BVH and otherwise I choose one of the distant lights randomly.
>       Currently, the probability to choose a light from the light BVH instead of
>       a distant light is 1.0 - 0.5 * num_distant_lights / num_lamps. This is
>       similar to the previous method where it was a 50-50 chance of picking a
>       lamp vs an emissive triangle and then just an equal chance for each lamp.
>
> The light picking work can be found in this commit
> <https://developer.blender.org/rB118731d7d415>, and the support for
> distant lights can be found in this commit
> <https://developer.blender.org/rB8b24cf8c83a1>.
>
> *Next week*
> I would like to have a look at the following:
>
>    - Add support for background lights
>    - Another iteration on distant lights
>       - Is there a better way to incorporate the distant lights instead
>       of treating them as a special case?
>       - If not, is there a better probability to pick between sampling
>       the light BVH vs distant lights?
>       - When picking between distant lights, could I do something better
>       than just randomly? The probability for picking a particular distant light
>       could be based on shading position, light direction, and energy?
>       - Start implementation of the splitting method
>
>
> I wish you all a great weekend.
>
> Thanks,
> Erik
>
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180624/df8c44e3/attachment.html>