During testing I found a bug (or a feature that’s not currently implemented). With many lights sampling enabled, translucent materials do not render properly.
Moving the light around can result in the transulcent shader partially rendering with Many Lights Sampling on, but it’s still not right.
I also assume that you know that volumetrics currently don’t render properly with Many Lights Sampling enabled. If you don’t, you will discover it as you work on implementing Many Lights Sampling for volumes in the coming weeks.
May I also ask a question. What is the expected performance impacts of Many Lights Sampling? This is what I can think of, am I missing something?
-
Constructing the light tree will increase the initiallization time of a given scene.
-
Traversing the light tree/figuring out which light to sample will increase the cost of each sample.
-
Ray splitting (which currently isn’t implemented?) will increase the cost per sample depending on the scene.
I’m sorry if this has already been documented somewhere, is 2 (Traversing the light tree) an expensive operation? I have a scene where lighting comes almost entirely from multiple mesh lights. And I’ve noticed that with Many Lights Sampling on, the “time per sample” increases drastically. And I don’t know if something like this is expected or not, hence why I am asking the question.
Time per sample - Many Lights Sampling Off: 0.643138 seconds
Time per sample - Many Lights Sampling On: 6.392621 seconds
Scene light statistics:
light.cpp:1237] Total 2 lights.
light.cpp:248] Background MIS has been disabled.
light.cpp:1216] Number of lights sent to the device: 1
light.cpp:1218] Number of lights without contribution: 1
light.cpp:390] Total 1153 of light distribution primitives.
Here is the .blend file if you wanted to take a look at it: