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

Sun Jul 29 20:26:18 CEST 2018

Hi Brecht,

Great! I have only ever compiled for the CPU so I am not surprised the
branch is broken for CUDA / OpenCL. I would love some help with that.

I tried rendering the classroom scene too and that is where I noticed that
mesh lights are considered double-sided. I think the entire window is a
transparent mesh light with a normal pointing away from the room which
makes the sampling never pick it. Not sure if this is the main issue but it
is a problem. I will have a closer look at this scene tomorrow. How much
work do you think there would be to change mesh lights to be single-sided
by default?

I tried rendering the night version of the "Barcelona Pavillion" scene
yesterday and found out that it used instanced mesh lights. Instancing was
not handled correctly but has now been fixed for mesh lights. I tried using
instancing with lamps and that seemed to work without any extra work.
The normals of the instanced mesh lights were pointing in the "wrong"
direction(towards the ceiling) in this scene too which makes the light
picking not pick it. I also saw that there were some problems related to
the normals of the trees("tree_scatter_plane") which I think is just a
collection of textured cubes? I will have a look at this tomorrow too.

I have not tried the fishy cat scene but I will definitely have a look at
it. I will try as many scenes I can get my hands on to try to find as many
bugs as possible.

I have also noticed that branched path tracing and path tracing have
brightness differences. I think it is either related to the PDF restructure
I did or the MIS calculations. I will have to look into this.

Thanks for the feedback on the code. I have some ideas for the double issue
that I can try and I will change to linear_rgb_to_gray() instead. Thanks!

Best,
Erik

On 29 July 2018 at 19:02, Brecht Van Lommel <brechtvanlommel at gmail.com>
wrote:

> 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
>>>
>>
> --
> 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/082591fd/attachment.html>