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

[Erik Englesson]

Hi all,

*This week *I have tried to find and fix as many bugs as possible. I also
did a quick optimization and had a look at volumes.

*Bugs*

In last weeks email, I was discussing some discontinuities in the lighting
in one of my test scenes that used mesh lights. These were caused by a bug
coming from the PDF restructure I did a few weeks ago. Lukas helped me
pinpoint this bug. Thanks!

I also found and fixed an indexing issue in the background MIS calculations.

This work can be found in this commit
<https://developer.blender.org/rB00b90ede1b8cba0d47a4cdc7c6d48f49ed15d677>.

*Optimization*

I ran the code through a profiler(perf) and found that most of the time was
spent in cosine and arccosine functions. These functions are used heavily
in the importance calculations so I changed them to fast_cos() and
fast_acos() instead. I got a 1.4x speedup in the scene I was testing
without any visual difference.

After this optimization, I could not find any more low hanging fruit. I
also did not want to spend too much time optimizing at this point in time.
Now, most of the time was spent in the recursive tree traversal function.
This could potentially be due to the overhead of recursion and if so it
would be interesting to implement a stack traversal similar to what the
geometry BVH traversal is doing. I do not think recursion works well on the
GPU which is another reason to do this.

This change can be found here
<https://developer.blender.org/rB6045fc40f4cd1d89f326a2d937e07752f5e3ad7c>.

*Volumes*

I have not really considered volumes up till now. The paper proposes
another importance metric for volumes that I have not implemented yet. I
tried to use the current implementation of the paper for the volumes too
but ran into issues with MIS calculations. It was able to find lights that
the light tree would give zero probability of sampling which resulted in
fireflies. For now, I am disabling the light tree picking method if the
shading point is inside volume or on the volume boundary. Currently, I
check if a shading point is inside or on a volume boundary by looking at
the volume_bounce and volume_bounds_bounce counters to see if any of them
are non-zero. Is there a better way? This will be needed when the proper
volume importance metric is implemented too.

I also spent a lot of time trying to make sure the MIS calculations are
using the correct shading point and normal, i.e. from the vertex before the
light. This is actually really tricky in the current code, due to all the
possible code paths that call the MIS calculations. To do this properly for
all the code paths will take some time.


*Next week* I want to

   - Make sure volumes looks OK when rendering with the light tree
   - Continue fixing MIS calculations
   - Find and fix as many bugs as possible
   - Have a look at the paper to see how hard it would be to implement the
   volume importance metric and potentially implement it
   - Add more comments in the code

I would also like to compare renders and render times between my branch and
master *without* using the light tree. If my branch is slower then I might
look into optimizing it.

Ideally, I would like this branch to be merged into master/2.8. If there is
anything you can think of that is better to work on than what I have
mentioned above then please let me know. Is it possible to add this work as
an experimental feature?

Thanks,
Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180727/d79b4f83/attachment.html>