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.

[samkottler]

Week 6:
This week was a step down from last week. On Monday my hard drive crashed so I had to spend all day restoring a backup so I didn’t actually get any work done. Then I started some preliminary short tests to make sure that GPU performance hadn’t regressed when no using the light tree. It seemed good to me, but I’m guessing there are some more rigorous tests for that somewhere. I also tested the light bulb tree scene from Acrivec, (with the volume removed since the light tree doesn’t support that yet). It definitely renders with less noise with the light tree and splitting enabled.
Finally, I continued looking for a bug that could be contributing to the render layers problem. I think I found something that could be contributing, but I’m not sure how to fix it and would apreciate it if anyone has any suggestions. Basically the SAOH only allows area light to be emitting from one side, which in general is not the case for emissive meshes. Because light tree sampling takes orientation into account, sometimes it samples mesh light too often or not often enough. The only way I can think of to get around this to to add each mesh light to the light tree twice with opposite normals, but I’m a little worried that this will cause performance to be lost.

Next week my plan is to continue investigating this mesh orientation problem and hopefully come up with a solution.

[samkottler]

Week 7:
This week I finally fixed the render_layer tests. The problem was not actually the orientation thing I mentioned last week. Instead the problem was the way that energy for lights was calculated incorrectly resulting in the tree being build incorrectly and the importance being calculated incorrectly. After fixing this calculation all tests pass with the light tree enabled with and without splitting. One note for a thing to fix in the future is that energy for mesh lights with non constant emittence still incorrect. This is a small problem though and is going to be difficult to fix so I decided to put it off for now.

After I fixed the energy calculation I started looking at adding volume support to the light tree code. This seems like it has two main things that will need to be done.

• Add the importance calculation for volume scatter points
  • The hardest part here will be getting all the necessary information to the right place
• Add splitting code for volumes
  • This will not be too difficult because it will be mostly copied from the splitting code for surfaces

Next week I plan on continuing working on adding support for volumes.

[samkottler]

Week 8:
This week I started working on implementing volume support for the light tree. I finished the importance calculation, but I still need to tweak when the two different importance measures are used. I also looked at the splitting code a little and discovered that it will be a little more difficult than I thought last week. This week I also tried testing to see whether the light tree actually causes there to be less noise with similar rendering times. However every scene that I tried actually ended up doing the opposite. I’m not sure if this is a problem with the algorithm or simply that I need more complicated scenes for the extra overhead of the light tree to cancel out.

Next week I am moving so I will only be working 3 days. Because of this, I will likely not work on volumes anymore and instead try testing the light tree with more complicated scenes.

[samkottler]

Week 9:
This week I was only able to work 3 days, so I didn’t get a lot done. I made a few small tweaks to the light tree volume code and tried to make a test scene that would test if the light tree is working. I have a simple scene that does this a little bit, but it still needs a little more work. This week I also started looking at adding splitting support for volumes. I’m still not quite sure how I’m going to do it, but I do have a few ideas.

Next week my plan is to continue looking at splitting for volumes and try a few things to see if they work.