I made a post like this earlier and I thought I would do another one since a significant amount has changed with Many Lights Sampling.
Here’s a list of all limitations and quirks in Many Lights Sampling (and Emission Sampling) that I know of. I’ve also included some information people might find useful.
The Light Tree can't be enabled when using the HIP rendering backend
The HIP kernels fail to compile with the light tree, so it has been disabled while it’s being sorted out. The hope is that this will be fixed before the release of Blender 3.5.
Using the Light Tree will increase memory usage
When using the light tree, a light tree will be constructed and stored in memory, thus increasing your memory usage. The more lights you have, the more memory will be used.
Cycles scene initialization time is longer when using the Light Tree
When starting a render, a light tree needs to be constructed. This takes some processing and as a result the scene initialization times will be longer with the light tree.
Currently the light tree construction is single threaded, so it can be sped up with multi-threading, which is planned for the future.
Rendering with the Light Tree is slower than rendering without
When the light tree is enabled, you may notice that fixed sample count renders are slower. This is because each time a light is hit or picked during the rendering process, extra processing is done compared to rendering without the light tree, and so this slows down renders. But the hope is that the noise benefit of using the light tree will out weight the performance slow down.
Using instanced mesh lights doesn't lead to a benefit in memory consumption in the Light Tree
When using instancing, memory can be saved by reusing information. However, at this current point in time, the light tree doesn’t have native instancing support built in which means there’s no memory usage benefit in the light tree from using instancing.
I should note, instanced mesh lights will work with the light tree. It’s just the memory benefit that doesn’t “work”.
The hope is that support for instancing can be added in the future.
The Light Tree does not take into consideration occlusion
At the moment, the light tree builds a BVH for the lights in the scene. Each node in the BVH has a bunch of information in it, but it does not include occlusion information. And no geometry is included in the light BVH (other than mesh lights).
As a result of this, the Many Lights Sampling algorithm doesn’t know about any light occlusion by geometry and may accidentally over sampling certain lights occluded from a shading point.
This could be improved with a reinforcement learning system (similar to Path Guiding). But it’s currently not implemented and there are no immediate plans for this.
Image show casing issue
This is an extreme example. There is a point light on the right side of the wall. And a REALLY bright spot light on the left side of the wall. Due to the brightness of the spot light, Many Lights Sampling assigns a lot of samples to it. But this leads to a weird dark spot on the right with a lot of noise.
This is because the Many Lights Sampling system is picking the spot light a lot, even though the spot light is occluded by the wall. Because the Light Tree the Many Lights Sampling system is using doesn’t know that there’s a wall in the way.
When working with mesh lights, every triangle is a light
Every triangle in the scene that’s included in the light tree (by having a emission shader that’s bright enough to be considered a light) is a light in the light tree. I bring this up because it can be easy to forget the sheer number of mesh emitting lights you have in your scene because you might think each mesh is a light, but it is in fact every triangle. And this can impact the memory usage of the light tree and the initialization time of the light tree.
The Light Tree doesn't handle many complex node setups or textures in lights
The light tree uses approximations of lights during most of the process. And as such, many complex things like complex node setups or textured lights are ignored. This can result in a increase in noise as a light is treated as if it “casts light in a specific spot with a specific intensity”, when in fact it’s significantly different.
There are some ideas on how to improve this, but they’re currently not implemented.
Example of a textured light
In this example I have a normal white point light on the top and a bright teal point light below with a IES texture driving it’s output. You can see there’s a weird black spot around the teal lights emission point. This is because Many Lights Sampling is directing a lot of samples towards it because the light tree has it represented as a “full point light” rather than a point light with bits “turned off” with a texture.
The Light Tree doesn't work well with ray visibility
In Cycles you can adjust the “ray visibility” of objects. For example, you can make it so a light is visible to all materials other than diffuse materials.
The issue with this is that this property isn’t represented in the light tree which means certain lights with certain ray visibility option disabled will still be picked by the Many Lights Sampling algorithm and thus increase noise.
Example of issue
A scene with a diffuse surface and two lights. One light has the “visible to diffuse surfaces” setting disabled, but is still being selected by Many Lights Sampling and increasing noise.
Renders with the Light Tree might be a different brightness compared to without it
This is caused by the “clamping” setting in Cycles. It reduces the brightness of lights to avoid fireflies. But due to how it works, it ends up producing different results when you use a different light sampling strategy, and in the case of Many Lights Sampling that typically means there is an increase in brightness when using Many Lights Sampling with clamping compared to having Many Lights Sampling off with clamping.
You can find the setting for clamping here (setting it to 0 disables clamping):
The noise may suddenly change as you adjust light settings, position and rotation
As lights are changing in the scene, the light tree gets reconstructed to account for the changes. At a certain point, the changes you make might be large enough that it triggers the light tree construction system to construct a differently “shaped” light tree than what was previously being made. This will can change the noise in the scene.
Example video
Mesh lights below a certain brightness see a sudden increase in noise
Along with the Light Tree, a new “Emission Sampling” feature was added for mesh lights (usable with and without the Light Tree). It allows you to define whether or not the front and/or back side of the mesh should be sampled. Or even disable it entirely. By default it is set to “Auto” which will enable mesh light sampling for the front and back if the material is bright enough. Once the material is below a certain brightness, the emission sampling feature will act like the “None” option.
This can lead to an increase in noise as the mesh lights are no longer being sampled through “Next Event Estimation”.
The “Auto” features was added specifically to cull dim mesh lights from the light tree to reduce memory usage and initialization time in certain scenes.
The new Emission Sampling feature isn't working as you might expect
You may look at the description of the settings for “Emission Sampling” and read something like “None: Do not use this surface as a light for sampling”. And yet when you select this option, the light is still being sampled. Why is that?
What this setting does is decide whether or not the light should be used for Next Event Estimation sampling. If it’s set to none, then it won’t be used. However if the light is reached through some other method like forward path tracing, then it will still be sampled.
Using the light tree isn't guaranteed to reduce noise
The light tree is really useful for increasing the probability of samples going towards lights that are more beneficial for the current shading point. And this relies on there being a meaningful difference between the importance of different lights and nodes in the light tree. If there is no meaningful difference between the importances of different lights and nodes, then there’s no way for the light tree to help out. This case is rare, but it can happen.
Also, simple scenes, specifically scenes with coloured lights, can see a increase in noise when using the light tree.
Example of a simple scene that sees a increase in noise due to the light tree
This is a simple scene. One teal light and one red light. This was rendered at 4 samples per pixel.
The image on the left (light tree on) is noiser than the image on the right (light tree off)
Also, the light tree is only really useful for scenes with materials that scatter light. If the entire scene is made of perfect mirrors and perfect glass, where no scatter occurs, then there will be no benefit of using the light tree as the useful part of the light tree function will never get used.
There are also some other quirks I have shared above (ray visibility, textures, etc) that can negatively impact the noise when using the light tree.
In various situations the current Light Tree/Many Lights Samplings implementation is nosier than other versions from other renders, or even the Many Lights Sampling project from just a few months ago
Some adaptations have been made to the Many Lights Sampling system to fix issues with the implementation used in Cycles a few months ago. These adaptations have lead to a reduction in effectiveness of the light tree in some scenes and as a result increased noise.
