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

[Brecht Van Lommel]

I started looking at the code in more detail but did not have time to get
far yet. Only two comments so far:
* The use of doubles is problematic for GPU performance, we'll need to find
an alternative solution for that.
* Instead of rgb_to_luminance(), shader_manager->linear_rgb_to_gray()
should be used to take into account rendering color space.


On Sun, Jul 29, 2018 at 6:56 PM Brecht Van Lommel <brechtvanlommel at gmail.com>
wrote:

> Hi,
>
> Definitely, I want to have this available as an experimental feature as
> soon as possible in master. The main thing we have to ensure is that no
> existing functionality is broken and there is no significant (GPU)
> performance regression when not using the feature. CUDA / OpenCL seem to be
> broken in the branch currently, I can help fixing that.
>
> Besides volumes, it would be good to do some testing to more complex files
> to find bugs. That's the most important thing at this point I think,
> stabilizing for the common cases.
>
> For example in the classroom scene the result is significantly more noisy
> and a bit darker. It has distant, area, point and mesh lights, so not the
> easiest case. In the fishy cat scene it hangs when building the light
> distribution.
> https://www.blender.org/download/demo-files/
>
> Also for example this file gives different results with branched path
> tracing and splitting than regular path tracing. Maybe these are the MIS
> calculations you are referring to.
>
> https://developer.blender.org/diffusion/BL/browse/trunk/lib/tests/render/ctests/light/multiple_area_lights.blend
>
> Regards,
> Brecht.
>
>
> On Fri, Jul 27, 2018 at 8:31 PM Erik Englesson <erikenglesson at gmail.com>
> wrote:
>
>> 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
>>
>>
>>
>> --
>> 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/20180729/3b479dc3/attachment-0001.html>