GSoC 2020: Production Ready Light Tree - Weekly Reports

[samkottler]

This week:

My main focus this week was to merge master into the gsoc-2018-many-light-sampling branch. There were only a few places where there were difficult conflicts, but I managed to get it compiling and running on Wednesday. Then my focus became rendering tests and reading through the code from the 2018 project to make sure everything is merged correctly and still working. This is a little challenging because the project from GSoC 2018 wasn’t complete. I have found a few places where I needed to update the 2018 code, but I think there are still more:

• Using the light tree seems to give a result that matches a ground truth reference with less noise in some places, but more in others.
• Disabling the light tree seems to work as expected for distant lights, but not for mesh lights.

I’ve mostly been using the classroom demo scene to test since it has multiple light sources, however, I think I will need to make my own test scene at some point specifically to check that the light tree is reducing noise when there are many lights.

Next week:
Next week I will continue reading through the 2018 project and looking for bugs introduced by the merge.

[StefanW]

The classroom test scene is not the best test scene for this in my opinion. The ceiling lamps have shadow casting disabled, which breaks MIS correctness. (They’ll block rays generated via BSDF sampling, but let rays generated via ligth sampling pass.)

If you like, you can take a look at my branch of the light sampling code: I did not update it to the latest master as you did, but I did few style/performance improvements and I believe I added support for volumes (been a while since I touched this code).

[edit]
I’m stupid, I forgot to add the link to my branch:

skwerner/blender

[samkottler]

Thanks! This will be useful once I finish fixing all my merge bugs.

[Josephbburg]

didn’t @GlebAlexandrov make a scene with a ridiculous number of lights for one his Light Book chapters a while ago? You should reach out and see if you can get him to contribute a test scene

I don’t know if Gleb checks this forum very often, though!

[Pipeliner]

ask him on twitter or via mail

[samkottler]

Week 2:
This week I was trying to fix the bugs I introduced in the merge, and using this as an opportunity to get more familiar with the cycles integration code. There is still one bug when not using the light tree that I have so far been unable to find, which can be seen in the area light and sphere light render tests.

The fireflies that can be seen in this image only appear when using an area or sphere light, outside of the boundary of a volume, when using MIS. Interestingly, the same problem doesn’t seem occur when using a spot or mesh light. From what I understand, there should only be a few places this bug can be happening, but I can’t seem to get rid of it.

Next week I plan on taking a break from looking for this bug to start to test and debug when the light tree is enabled. Hopefully fixing any bugs there will either also fix the bug above, or give me some insight that might help me solve that bug.

[michal1000w]

I’ve got a night scene with 97 point lights which is for now unusable in Cycles due to tons of noise!

Here is a test render made in eevee:
2|690x287

If this is something you are interested in I can provide a blend file.

Have a nice day

[samkottler]

Week 3
Today I continued bug fixing. I discovered that the fireflies that I mentioned last week was due to faulty logic from the 2018 project and not due to something introduced when I merged. See this commit. With the light tree disabled the branch now passes all but one cycles render test.

This week I also started debugging the tests with the light tree enabled. For some of the tests that fail, I think that it is simply because the noise is different (not better or worse) so I’ve been ignoring those tests for now. However, there are some tests with significantly more noise, which from my understanding of the light tree algorithm shouldn’t happen. For example, look at the floor in the pointiness mesh test:

Next week I plan on continuing to investigate these failing tests and hopefully fix them. At the beginning of GSoC Brecht mentioned a tentative goal of getting the light tree code as an experimental feature added to the master branch in the next week or two, and passing these tests is the major thing standing in the way.

[samkottler]

Week 4
This week was not as productive as I would have liked because I kept going in circles. After a little more investigation on the pointiness mesh test I mentioned last week, I discovered that the the extra noise on the ground does go away with more samples and it does appear to converge correctly, so I decided to go after more important bugs instead. I spent the rest of the week trying to fix the render_layer tests, which were definitely failing (not just noise, converged to incorrect answer). Finally today, I discovered one problem was that light tree importance was being calculated incorrectly. See this commit for details. The shadow and direct diffuse render layers are still failing, but the problem now seems to be that it is including the contribution of mesh lights as opposed to only the main area light. I don’t know if this is actually a problem, and I’m curious to know why those wouldn’t be counted normally.

Since this is the last failing test that I’m positive is actually wrong, next week I will move on to testing the light tree with splitting enabled. From what I’ve seen this week, there will be fewer problems there than with splitting disabled.

Bonus: I made these this week. The sphere is a mesh light with 2000 faces. The rendering times were identical.

[Acrivec]

If you wish to have a bit more complicated scene (a nightmare for path tracing to be exact) I can send you .blend of this scene:

[samkottler]

That would be great if you could send me the .blend for this scene.

[Acrivec]

I’ve finished converting to Cycles, can you send me a PM? I do not have privileges for sending private messages.

[mib2berlin]

Hi, I am testing your work from time to time and I have noticed the branch is not updated often. Latest commit was 19.06.2020 if I looked correctly.
With my latest build GPU render does not work at all, for example, but make no sense to report with such an outdated build.

Cheers, mib

[samkottler]

The last commit was Friday. Still a few days old, but not quite as old as the one you’re using. The reason it’s not updated all that often is that I’m bug-fixing 2-year-old code that I’m still not super familiar with.
I’m aware of the GPU problems and have actually been working on that the last few days, but again it’s slow because I’m still a little unfamiliar with the code. My hope is to have the GPU rendering at least building and running by the end of the week.

[mib2berlin]

Thanks for the fast reply, I was looking in SmartGit, git log shows the correct last commit. It was not meant as critics, was only curious.
I will update next time you commit and test further.

Thank you for the work on this, mib

[samkottler]

Week 5:
Finally a week that actually felt productive. First I decoupled light tree splitting from the branched path integrator. I’m not sure why these were tied together in the first place, but changing it didn’t seem to have any adverse effects so kept it. For anyone who doesn’t know, there is a user defined threshold that determines how many times the light tree sampling splits. More splitting is slower but generally means less noise, so it’s useful for it to be accessible in the regular path integrator. Second this week I fixed a problem with motion blur when using the light tree. See this commit for more info. Finally, I got CUDA acceleration at least working. See this commit. The problem was that the old light tree code had recursion in two functions. I made both into loops instead and now the CUDA code works. The light_tree_pdf function was easy to turn into a loop but accum_light_tree_contribution can probably be done better than what I did. I just wanted to get something that works at all.

Next week I’m going to take another look at the render passes bug I mentioned last week. I think this is the last thing that needs fixed before the light tree code is merged into master. I will also take another look at the accum_light_tree_contribution loop and see if I can improve it at all.