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

Erik Englesson erikenglesson at gmail.com
Mon Jun 25 19:01:21 CEST 2018 

Hey!

Thanks for the great input! I first thought the most "elegant" solution
would have all lights in the light tree, but now after having thought more
about it today, I am not so sure anymore. See my inlined comments. If I am
not missing something and the importance metric for distant lights will
only depend on energy, then I am not sure it is worth to put them in any
tree.

Thanks,
Erik

On 24 June 2018 at 20:29, Brecht Van Lommel <brechtvanlommel at gmail.com>
wrote:

> Great work!
>
> Thanks! :D

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.
>
> Interesting. If we want to put distant lights in a tree then we will have
to consider how this will affect the build and the traversal of the tree.

For the importance computations in the traversal, we would have to leave
out the square distance term and the parts related to world space bounds.
Unfortunately, the world space bounds are used in calculating the angle
between the node orientation bound axis and the vector from the *node
bounding box* *centroid* to the shading point(see θ on slide 14
<https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxja3VsbGF8Z3g6NWM0NmU2YWVlNjE3ODk1Yw>).
This angle is essential in the direction part of the importance
calculations. So, without these two parts(direction and distance) the
importance for distant lights would only depend on energy?

The tree building method heavly depends on world space bounds to partition
the lights in a node into two disjoint subsets. The building algorithm
works by generating a number of candidate splits, evaluate the cost of each
split and chose the one with the minimal cost. The cost calculation uses
the proposed Surface Area Orientation Heuristic(SAOH) which depends on the
area of the bounding box, but this part of the SAOH could easily just be
skipped. However, the candidate splits are generated entirely based on the
bounding box and a new method would have to be created. Say, based on
orientation and or energy, but not on bounding boxes.

Using the importance of the root node of the regular vs the distance light
tree might work well. We might need some kind of scaling factor since we
are comparing two different importance metrics though.


> 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.
>
>
Regarding the tree traversal, having a separate importance metric for
distant lights and regular lights and using the combination of them as the
final importance of the node should probably work. As mentioned above, the
importance for the distant lights would only be based on energy though?

The tree build is a bit trickier. It is probably still important to have as
small bounding boxes as possible for more accurate distance and direction
estimates in the tree traversal(regular importance calculation). Could we
just use the current splitting method and not let the distant lights affect
the bounding box of each node? The current way candidate splits are
generated is by splitting the bounding box into two subbounding boxes. A
regular light belongs to the subset of lights that are in the same
subbounding box, where a light belongs to a subbounding box if the centroid
of the light's bounding box is inside it. However, this does not work for
distant lights. Which subset should each of the distant lights belong to?
There are probably hacky ways to do this, e.g. randomly choose one of the
subsets or pick one such that the orientation bound of the subset changes
as little as possible before and after adding distant lights etc. Or, a new
way of generating candidate splits could be created.
Also, the SAOH depends on the area of the bounding box, which could easily
be fixed when having a separate tree, but now it becomes a bit more
complicated. Similar to the importance, two different costs could be
created, one for distant lights and one for regular lights and then these
would have to be combined somehow into a final cost.


> 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.
>
> I will first implement background lights as not being part of the tree and
choose between sampling a background light vs the light tree by looking at
their energy as you proposed above. The more advanced method would probably
work well. If there is time and we see that backgrounds are not sampled
properly then I will try the more advanced method.


>
> 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
>>
>
> --
> 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/20180625/7ac52c7c/attachment.html>

More information about the Soc-2018-dev mailing list