Hi everyone, this thread is going to be used for my GSoC project’s weekly progress report. I’m going to try to keep these posts as higher-level summaries, but I’m also planning to write longer, more technical posts on my personal website. Feel free to check it out - constructive criticism is appreciated!
If you have any feedback (questions, concerns, bugs, etc), please post it to this thread and I will try to respond as soon as I can!
Hi Jeffrey.
Awesome to see this feature implementation getting love again.
Will there be a branch for this project any soon? And I’d like to know if this implementation will speed up render times in scenes with multiple lights through volume objects( volume illumination)
Hi Roggii, thanks for reaching out! I’m pushing to a branch called soc-2022-many-lights-sampling which you can also see here. I’m also going to be periodically updating this diff (likely every week or major update or so).
As for your second question, support for volumes is definitely on the to-do list. Right now, this is the sequence that I’ll be trying to follow:
This is relatively high-level and definitely subject to change, but this feels like a somewhat natural order for me.
Hi, I try to build your branch but it stop with:
Building CXX object intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/device/cpu/kernel.cpp.o
In Datei, eingebunden von /home/user/blender-git/blender/intern/cycles/kernel/../kernel/integrator/shade_surface.h:17,
von /home/user/blender-git/blender/intern/cycles/kernel/../kernel/device/cpu/kernel_arch_impl.h:32,
von /home/user/blender-git/blender/intern/cycles/kernel/device/cpu/kernel.cpp:48:
/home/user/blender-git/blender/intern/cycles/kernel/../kernel/light/light_tree.h: In Funktion »bool ccl::light_tree_sample(KernelGlobals, const RNGState*, float, float, float, float3, float3, int, uint32_t, LightSample*, float*) [mit bool in_volume_segment = false]«:
/home/user/blender-git/blender/intern/cycles/kernel/../kernel/light/light_tree.h:192:1: Fehler: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Werror=return-type]
192 | }
| ^
/home/user/blender-git/blender/intern/cycles/kernel/../kernel/light/light_tree.h: In Funktion »float ccl::light_tree_emitter_importance(KernelGlobals, float3, float3, int)«:
/home/user/blender-git/blender/intern/cycles/kernel/../kernel/light/light_tree.h:93:1: Fehler: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Werror=return-type]
93 | }
| ^
Translation:
Error: control flow reached end of non-void function [-Werror=return-type]
192 | }
Is it to early to build for now?
Cheers, mib
EDIT: gcc (SUSE Linux) 12.1.0
Hi, yes - right now, I’ve only been building on MSVC with just warnings on. Thank you for pointing that out though - I’ll try to build with warnings as errors, and let you know when it compiles for me.
Closing this thread to limit this to the weekly reports. @Jebbly Feel free to open a second thread for feedback if you like.
This week, I completed an initial CPU implementation of the light tree with support for point lights, spot lights, and area lights. I’ve also written a longer and more technical post if anyone is interested. The scenes I tested consisted of a single cube, no background light, and some light sources scattered around. Here’s an example with 1 point light, 1 spot light, and 1 area light - 8192 samples:
Overall, my implementation’s renders seem to converge towards the original implementation’s renders given enough samples. However, as you can see in the above image, there is definitely a lot more work that needs to be done in terms of adjusting heuristics to reduce noise. Optimizations are also going to take place once the algorithm is deemed stable enough.
I’d like to complete the following for next week:
This week, I added initial support for emissive triangles, distant lights, and background lights. Unfortunately, due to the fact that we ended up changing the sampling strategy, I wasn’t able to test this as thoroughly as I would’ve liked. Given that there haven’t been many tests for either triangles or background lights, I may have to revert some of the changes I made to test each feature individually.
I also started reading up on light sampling from volumes, but I haven’t made too much progress on that end yet. This is also going to be continued, but the other features take priority.
I’d like to complete the following for next week:
This week, I cleaned up some of my work and performed a bit more testing with emissive triangles and distant lights. Here’s a more technical post about how all the different light types were implemented. Again, the tests I did were mostly simple scenes, like this one with 2 emissive triangles:
I’d like to complete the following for next week:
This week, I updated the multiple importance sampling calculations to account for the light tree sampling distribution. Here’s a slightly more technical post summarizing what I did. Other than that, I also made some improvements and corrections to the importance heuristic. I mainly tested with the following scene, which contains 1 sun light, 1 spot light, 2 emissive triangles, 1 point light, and 1 area light:
Unfortunately, since I spent a lot of time debugging the MIS PDF calculations and the importance heuristics, I was unable to attend to the list of bugs mentioned in the feedback thread. This is going to be my first task for next week.
I’d like to complete the following for next week:
Since this report also marks some degree of support for most light sources (outside of participating media), please feel free to start sharing scenes for testing, benchmarking, etc. in the feedback thread! I’ll try to check them out when I get the chance.
This week, I mainly worked on refining the importance heuristic calculations and light tree construction. As I mentioned in the feedback thread, some of these changes are not yet pushed because I would like to merge properly with the master branch first. This should be completed within a few days.
At this point, aside from visibility issues (which are inherent to the algorithm/paper so a separate solution may be incorporated), I’m relatively content with the implementation for now. Of course, there are a lot of optimizations that still need to be made, but I’d like to begin working on sampling in volumes.
I’d like to complete the following for next week:
I expect the work for volumes to take 2 or more weeks, but if anyone has any simple scenes with volumetrics, please share them in the feedback thread!
Unfortunately this week, I wasn’t able to make much progress on the volume side of things. I realized that I still need a better understanding of how volume rendering works with MIS before I can confidently implement proper support. In the meantime, I mostly spent this week debugging the issues mentioned in the feedback thread, which included:
There are also a few other issues mentioned, which I would like to further discuss with Brecht and Lukas. In this case, I will likely be dedicating next week to resolving these issues. I apologize for the delays in volume support, and I’ll try to make sure I have sufficient background knowledge to implement support properly by next week.
I’d like to complete the following for next week:
This week, I talked with Brecht about the issues that were mentioned in the feedback thread. The proposed solution was to implement our own version of adaptive splitting, which I’ve begun working on. My current implementation uses a stack to keep track of the splitting, and weighted reservoir sampling to handle the stream of candidate samples.
Right now, the “weighting” is just sampling the candidates uniformly, so I don’t expect it to work well on some of the scenes that have been previously tested. However, even this initial solution seems promising for some issues from the feedback thread. These two renders were rendered at 16 samples:
There’s still noticeable noise but I suspect that it will be much better once we use proper weighting for the candidates. The idea, for now, is to potentially take an actual light sample to perform the weighting. I’d also like to see if visibility can be included.
Overall, Brecht and I also discussed that a stable and refined implementation of surface sampling should take priority. As such, I’ll likely dedicate the remaining weeks of GSoC towards stabilizing and optimizing this new technique. The volume support may have to come later, e.g. over the winter.
I’d like to complete the following for next week:
Since this new algorithm did require some restructuring of the code, I suspect that a few things will be breaking in the near future. For those testing things out, please continue to let me know of any issues in the feedback thread! The reports are helping a lot in terms of debugging, etc.
This week, I worked on implementing the light sample for the weighted reservoir sampling. I also implemented a separate computation to address issues with the spotlight sampling. These solutions seem to have helped certain test cases, but a few new bugs have been reported in the feedback thread.
I’m volunteering at SIGGRAPH so I probably won’t be able to work much this week, but I’ll try to check out the reported bugs when I have the time. If anyone else is attending, feel free to reach out!
This week, I was volunteering at SIGGRAPH and didn’t get much done on this end. However, I did meet up with some NVIDIA folks to discuss some methods of computing better MIS weights. I also talked to some developers at the Blender exhibit!
I’d like to complete the following for next week:
This week, I modified the PDF calculations used in the multiple importance sampling. As mentioned in the previous weekly post, this uses a bit-trail to keep track of the leaf node’s location and also accounts for the adaptive splitting. This change seems to have resolved some of the issues that were mentioned in the feedback thread.
I also addressed the other issues mentioned in the feedback thread. There are a few issues remaining, but I believe the solution will be to fix the splitting threshold at some constant value.
Since I’m returning to my university this week, I’ll probably be working on less technical stuff and more documentation. I’d like to complete the following by next week:
Other than this, I’ll probably be working on documenting things (e.g. one last technical write-up about the adaptive splitting, adding to-dos, etc).
This week, I cleaned up some of the comments in the code and added future to-dos to this task. I’ve also begun collecting scenes that work and don’t work with the current implementation.
Since this is the final week, I’ll primarily be working on writing up the final report. I’ll also spend some more time documenting future tasks so that it’ll be easier for me / other contributors to pick up again (it’ll likely be in the winter for me). Furthermore, I’d also like to test a few scenes that are more complex, just to see how they compare as of right now. If anyone has any scenes they’d like to test, feel free to send them in the feedback thread!
This week, I wrote up my final report and did some final debugging + documentation. I also tested out some scenes - one of the good results is NVIDIA’s attic scene.
At 2 minutes, the original implementation renders the following:
On the other hand, the many lights sampling algorithm renders the following:
There’s already noticeably less noise in this render (my final report also has a render after 30 minutes, where the MLS implementation also generally produces less noise). That said, it seems like the Bistro scene has some more work to do now that splitting has been introduced. However, keep in mind that there should be lots of room for optimizations!
As GSoC comes to a close (and I resume classes), I don’t expect to be able to do much work for a while. I hope I’ve provided enough documentation for other contributors to pick it up, which I also plan to do over the winter.
In general, I’m very grateful to everyone who has shown interest and supported this project. The Blender developer community went above and beyond my expectations, and the continued support really helped me out. Thank you all - I hope I can return the favor someday!
