I did some more testing with the updated Many Lights Sampling branch and found an issue.
With a spot light, area light (with low spread (Less than 70 degrees)), and a bright point light, Many Lights Sampling seems to have issues. The issue becomes more pronounced as the splitting threshold is decreased.
Here’s a .blend file:
Thanks for the report - there was an issue I was meaning to debug at lower splitting thresholds, and I’m hoping that this is related.
This should tentatively be fixed. The issue was that the adaptive splitting was starting to sample from nodes where both the left and right child had 0 total importance, and there were some issues related to dividing by 0.
The temporary fix is to just skip over the case where this happens, but we may want to address this earlier before we even split.
I’m sorry. I’ve been testing out Many Lights Sampling, and sometimes I come across “issues” and it can be hard for me to determine if it’s a bug/issue or just me not understanding the limitations of Many Lights Sampling in it’s current form. So if this “issue” isn’t actually an issue, then I do apologize.
I have created a scene. It consists of a really bright point light placed off to the left. And a really bright spot light and area light on the right (from testing, it can be two area lights (with a spread around 90 degrees or lower), or two spot lights, or a mix of both. And at least one needs to be really bright). When the splitting threshold is set really low (0.01 to 0.0 range), some “issues” occur.
Adjusting the brightness (either increasing or decresing the brightness), or position of the lights can resolve the issue.
Here is the .blend file:
Hi, thanks for the report. I’ve been checking this out, but I’m curious if this is actually related to an issue that’s fundamentally wrong with the light tree construction. It seems like that dark area is where the importance is still giving heavy importance to the area/spotlight, and since there’s no splitting, most of the samples are getting wasted.
I’ll test this further by building an older version (before splitting was added) to see if the issue persists. If this is indeed the case, I think the easiest solution would be to either fix the splitting threshold at the default value (0.85), or bound the minimum to a higher value.
I’ve tested an older build of the Many Lights Sampling branch from before the introduction of splitting and the issue wasn’t there.
This one is definitely a bug or current limitation.
With Many Lights Sampling On, in a scene with a bright spot light with a large radius and a average brightness point light, the point light ends up rendering brighter than expected within a certain area around the spot light. This issue persists even at high sample counts (thousands of samples per pixel)
Here is a .blend file:
Thanks for testing it out before me - I guess this is kind of reassuring in the sense that the construction isn’t inherently the issue. I’ll also try to check out the other issue when I get the chance.
This feedback falls in the category of “feature request”. Sorry if this isn’t what you’re looking for.
When Many Lights Sampling is enabled, the splitting threshold is used, and a low sample count is used, rings will appear in the render (shown in the image below).
A suggestion someone gave to me was “These rings should be feathered”. If I understand correctly, this can be done by adding some random variance per sample to the splitting threshold at line 219 of light_tree.h · rB
Feel free to add your own thoughts and tell me why this isn’t a good idea (assuming it’s not a good idea)
No worries, feature requests are also appreciated!
As for your suggestion, I also agree that the splitting thresholds need some adjustments (and I’ll continue working on the heuristics this week). However, my main concern with introducing random variance is that the splitting threshold would no longer be deterministic.
The deterministic behavior of the splitting threshold simplifies the probability calculation of selecting a given light. Generally, we need to be able to re-calculate this probability in order to choose a good weighting between indirect/direct light sampling (here’s a slightly more technical writeup). However, if randomness is introduced to this calculation, I’m not sure if it’ll be possible to calculate anymore. That said, I’ll try to give it some more thought.
To follow up on this, could I ask which specific commit you built on? I switched to one of the more recent commits before the splitting was introduced, but I’m encountering some issues still.
I retested with rB9a9873acc7c5 (the commit just before the introduction of splitting) and can confirm, the issue is still there.
Sorry for providing the incorrect information in my previous message.
No worries - I’ll have to talk to Brecht and Lukas about it a little more, but I suspect that fixing the splitting threshold to a constant value will resolve a lot of problems.
By the way, it seems like I’m unable to reproduce this issue on the latest commit. Perhaps I made some changes on the side that fixed it, or I’m understanding the issue incorrectly?
I have retested with the latest version of the Many Lights Sampling Branch. I can confirm, the issue has been resolved.
I also decided to investigate it, and it seems it was resolved with rBa7cd05d15028 (Cycles: use bit-trail for light tree pdf)
Thanks for testing it out! I guess that makes sense because the PDF calculations may have been incorrect previously.
Sorry for the relatively bad report on this issue.
In Cycles, a light’s “power” can be changed to a negative value. And I decided to test this with Many Light Sampling and noticed two issues:
Note: In the video below, the crash was “quick”. Most of the time it’s not this quick.
I just pushed a commit that should (tentatively) fix this issue. I say tentatively because I have a general idea of what should have caused this issue, and I could no longer replicate this issue after the change, but I’m not 100% certain that this fixed it completely.
From my understanding, the issue was that the negative energy was being used in the importance calculation, and thus the negative importance was messing things up. Thus, my solution was to take the absolute value of the energy in the importance calculation.
Edit: This issue was introduced with this commit rBa7cd05d15028
I found a bug.
The reflection of emmissive trianges in rough glossy surfaces isn’t working properly when Many Lights Sampling is On. It easiest to see at low roughnesses.
Here is a .blend file I used for testing:
This is a simple scene. I have a ground plane, fully metalic and a little bit rough. And an emissive plane. As you can see when Many Lights Sampling is On, the reflection of the plane renders incorrectly. Increasing the roughness hides the issue, and decreasing the roughness to 0 resolves the issue.
Many Lights Sampling Off:
Many Lights Sampling On:
This will propbably need to be discussed with Brecht or someone else on the Cycles team before considering.
In a presentation done by Sony Image Works on Many Lights Sampling (http://aconty.com/pdf/importance-sampling-lights-slides.pdf), they noted to get around issues with powerful and occluded lights being over sampled, they say:
“…we have a way to single out a particular light and exclude it from the heuristics and do traditional light loop”
Found on the last page of the PDF.
This could potentially be used with Many Lights Sampling in Cycles to work around problomatic lights (like textured lights) when using a low splitting threshold?
Although, I understand exposing certain options to the user just to work around an issue with the algorythm used is less than ideal.
