<div dir="ltr"><div>Thanks for the detailed reply.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Keeping the distant and background lights separate from the other lights for now seems like a good plan.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 25, 2018 at 7:02 PM Erik Englesson <<a href="mailto:erikenglesson@gmail.com">erikenglesson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hey!</div><div><br></div><div>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.<br></div><div><br></div><div>Thanks,</div><div>Erik<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 June 2018 at 20:29, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@gmail.com" target="_blank">brechtvanlommel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great work!<div><br></div></div></blockquote><div>Thanks! :D<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>For distant lights I'm not sure about the best solution, some brainstorming:</div><div><br></div><div>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.</div><div><br></div></div></blockquote><div>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. <br></div><div><br></div><div>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 <i>node bounding box</i> <i>centroid</i> to the shading point(see θ on <a href="https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxja3VsbGF8Z3g6NWM0NmU2YWVlNjE3ODk1Yw" target="_blank">slide 14</a>). 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?<br></div><div><br></div><div>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.</div><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.</div><div><br></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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. <br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.</div><div><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.</div><div><br></div></div></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div><div class="m_6191585988652955813m_2982645604057126000h5"><div dir="ltr">On Fri, Jun 22, 2018 at 10:59 AM Erik Englesson <<a href="mailto:erikenglesson@gmail.com" target="_blank">erikenglesson@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_6191585988652955813m_2982645604057126000h5"><div dir="ltr"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Today is <a href="https://vimeo.com/39345149" target="_blank">Midsummer</a> in Sweden, so I will be off earlier than usual. Here is my report for this week:</div><div><br></div><div><b><u>This week</u></b></div><div><u></u><b><u></u></b></div><ul><li>Light picking PDF<br></li><ul><li>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.</li><li>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.</li><li>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.<br></li></ul><li> Support for distant lights</li><ul><li>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.<br></li></ul></ul><div><div class="m_6191585988652955813m_2982645604057126000m_-5245768087200541808m_1026288461377806743gmail-m_3193824662990260296m_-7682682940882657453m_1345316775439720246gmail-adL">The light picking work can be found in this <a href="https://developer.blender.org/rB118731d7d415" target="_blank">commit</a>, and the support for distant lights can be found in this <a href="https://developer.blender.org/rB8b24cf8c83a1" target="_blank">commit</a>.<br></div><div class="m_6191585988652955813m_2982645604057126000m_-5245768087200541808m_1026288461377806743gmail-m_3193824662990260296m_-7682682940882657453m_1345316775439720246gmail-adL"><br></div></div></div><div><u><b>Next week</b></u></div><div>I would like to have a look at the following:<br><ul><li>Add support for background lights</li><li>Another iteration on distant lights</li><ul><li>Is there a better way to incorporate the distant lights instead of treating them as a special case?<br></li><li>If not, is there a better probability to pick between sampling the light BVH vs distant lights?</li><li>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?<br></li></ul><li>Start implementation of the splitting method<br></li></ul></div><div><u><b></b></u></div><div><u><b><br></b></u></div><div>I wish you all a great weekend.<br></div><div><b></b><u><b></b></u></div><div><u><b><br></b></u></div><div>Thanks,</div><div>Erik</div><br></div></div></div><span class="m_6191585988652955813m_2982645604057126000HOEnZb"><font color="#888888">
-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org" target="_blank">Soc-2018-dev@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/soc-2018-dev" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/soc-2018-dev</a><br>
</font></span></blockquote></div>
<br>-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org" target="_blank">Soc-2018-dev@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/soc-2018-dev" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/soc-2018-dev</a><br>
<br></blockquote></div><br></div></div>
-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org" target="_blank">Soc-2018-dev@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/soc-2018-dev" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/soc-2018-dev</a><br>
</blockquote></div>