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

Brecht Van Lommel brechtvanlommel at gmail.com
Tue Jun 26 19:35:50 CEST 2018


Thanks for the detailed reply.

I think the importance metric for distant lights could also depend on the
orientation? Distant lights shining on the backside of the surface would
ideally be ignored or given low sampling probability by the light tree
traversal.

I forgot that the orientation bounds during traversal also take into
account position though. I guess we could store a separate orientation for
regular and distance lights, but that's getting more complicated and memory
intensive. And indeed the candidate split in tree building would need to be
done differently as well.

Keeping the distant and background lights separate from the other lights
for now seems like a good plan.


On Mon, Jun 25, 2018 at 7:02 PM Erik Englesson <erikenglesson at gmail.com>
wrote:

> 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
>>
>>
> --
> 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/20180626/53cbf470/attachment-0001.html>


More information about the Soc-2018-dev mailing list