Hi, the builds are on builder.blender.org but the Windows builds are from 5. Dez., Linux and OSX are up to date.
If you use Windows you have to wait until the build bot for Windows is working again.
Cheers, mib
I started testing master with MLS and have one quick remark, that parallel tree building (which I saw is planned) is a must in complex scenes. Right now in both viewport and F12 renders building light tree can take a lot of time.
ED: My bad, I omitted that tested scene also have a lot of instances, so poor light tree building might be related to that too.
1 Like
Tested Light Tree + Path Guiding and compared with GPU. Last branch from november.
It interesting that my relatively slow cpu(i7 11800h) with PG and LT by level of noise close to gpu (3080) without LT, but it seems lighting result is different .
GPU, no LT, 10min:
GPU, with LT, 10min:
CPU, no PG,no LT, 10min:
CPU, with PG, no LT, 10min:
CPU, with PG and LT, 10min:
For everyone who wants to test scene itself, here is a link:
https://drive.google.com/drive/folders/1w4seYIO-RNvn5URmKVx-5I81KSBLSVbS?usp=share_link
Itâs free scene from behance, i just slightly adapted for Blender. Original:
13 Likes
If you are a Windows user, then it will not be possible to provide up to date feedback until the buildbot builds again, the issues that cause noticeable differences have been fixed. Unless it builds tonight, then we have to sit out on this thread and watch the Linux and Mac. users provide feedback.
1 Like
Some shaders look different between the CPU and GPU versions? e.g. the âframesâ around the mirrors. Maybe that caused the lighting result difference, but that seems independent from LT or PG.
Also: windows build bot working again it seems
Overlapping geometry causes issues like these, but can differ a little bit between different BVH structures (And the CPU and GPU use a different BVH structure by default).
See: â T96475 Overlapping geometry shows black faces on Cycles Blender 3.1 (Ray Tracing Precision)
3 Likes
Wanted to test the âLight Treeâ function and put together a small scene. The scene was lit using only mesh lights and HDRI.
3 bounces, 100 samples, Light Tree OFF:
3 bounces, 100 samples, Light Tree ON:
12 Likes
Iâve noticed a âstrangeâ LT behavior. When I have only mesh lights - it works âas expectedâ. But when I have light entities (point lights, area lights, etc.) in the scene - enabling LT is kind of adding noise. This is an old scene but at least you can see what I mean. You can see that certain areas that were relatively clean without LT became quite noisy with the LT enabled. Maybe this has something to do with distribution of samples?
3 bounces, 100 samples, Light Tree OFF:
3 bounces, 100 samples, Light Tree ON:
UPDATE: Looks like this is a scene specific issue because I couldnât reproduce it in other scenes.
UPDATE 2: I was finally able to reproduce it to an extent. In both cases enabling LT added visible noise.
The scene below is a simplification of a problem that I found in a production scene. There are 3 lights in this scene: mesh light (size 30km), area light (size 0,5m) and Nishita Sky. Area light is located inside a volume.
Without Light Tree all lights contribute to the scene, and the cone from area light is visible in volume:
With Light Tree enabled:
Here is a .blend file (disguised as txt, because this site does not support importing .blend files)
MLS_TEST_2.blend.txt (138.9 KB)
@JohnDow Without access to the scene, it can be hard for use to figure out whatâs causing the issue. Are you able to share the scene?
I can reproduce your issue. From my understanding this is caused by the mesh lights being assigned really high importance (due to itâs size), resulting in the light tree directing samples towards the mesh lights even though they have basically no contribution to the scene due to their distance from the scene.
You can tell Cycles to not include the mesh lights in the light tree with this setting, but it may be worth while for someone on the Cycles team to look into it and see if thereâs a bug.
Edit: The issue also appears to be related to the number of triangles on the mesh light. As the number of triangles increase (through things like subdivision), more samples get directed towards the mesh light up to a certain point. This can be observed when recreating the scene with a simple plane mesh light rather than a âplanet ringâ and using a subdivsion surface modifier on it.
However, I can only reproduce this issue in scenes with large meshes. When working with smaller meshes this âchange of importance based on triangle countâ is barely noticeable.
Video Demonstrating issue
3 Likes
Could be interesting to add some kind of âweightâ or âimportanceâ in the light settings?
I mean, you could want to avoid removing the mesh lights from the light tree for some reason, but donât want the sytems to deliver too much performance to it, maybe a percentage or a 0-1 solution could work.
With that all the lights weight 1, like it is right now it you include everythingm, but if you define one light to 0.5 it will be 50% less âimportantâ but it will still be properly sampled, this could mitigate the mesh light problem by allowing the user to lower the importance of such lights.
@Alaska thank you for investigating. Removing the mesh light from the light tree indeed improved the noise a lot. Thou in production scene this light have some ambient contribution to the scene, so Iâll probably need to hack it with some invisible, smaller light dome.
This scene is very similar to the previous one. The difference are:
- removed giant mesh light
- added little mesh light instances
- added smaller volume
- higher Sky emission
Issues I found with this scene:
- Massive slowdown (over 5min on my machine) when constructing a light tree before rendering starts. This is caused by instancing mesh lights. For confirmation I also tested instancing light objects and they seem to not cause any problems.
- Increased noise when rendered with light tree.
Light tree disabled
preprocessing time: 2 sec
rendering time: 2 min
Light tree enabled
preprocessing time: 5 min 29 sec
rendering time: 2 min
MLS_TEST_4.blend.txt (244.6 KB)
1 Like
@Alaska I canât upload that scene, but Iâm putting together a new one where Iâll try to reproduce the issue. If it works, then Iâll upload it.
[Deleted] Looks like the issue was resolved.
Lilâ request related to MLS: now that we can tackle dozens and dozens of lights in a scene, can we have array modifier on light? Pleeease?
1 Like
Please check after a21d948fd7ec, there was indeed a bug.
1 Like
This explanation gets a bit technical, but itâs not simply because the mesh lights get larger weights due to the size: in the light tree the importance is also scaled by the squared inverse distance, so mesh lights that lie far away shouldnât have very large importance. I tested that scene, indeed whenever the area light gets weighted against another node in the light tree, the area light almost always outweighs the other.
The problem arises when that area light gets grouped with other mesh lights and forms a large node. In that case, we have (yet) no knowledge of where exactly inside that node the area light lies, so the distance measure is inaccurate. This also explains why subdivision worsens the problem (as @Alaska mentioned): the more triangles there are, the deeper the light tree is, so we traverse both children of any light tree node with maybe equal probability a few times, until we finally find the exact position of that area light and give it 99% weight, but the weight would already be too low (for example 0.5^5*1 â 0.03).
In your specific scene, ideally we would like to separate the area light from all other mesh lights, but it is difficult because we group the light sources into axis-aligned boxs, and that area light kind of lies somewhere between the others. Iâve been mostly working on how to traverse the light tree better, and I think how to build the light tree could also be improved. The original paper just gives an equation for that without explaining why. But improving that would involve much intellectual effort.
Without the light tree, we have 0.5 probability sampling all the mesh lights, and 0.5 probability sampling all other lights (if any), which isnât a good strategy in most cases, but works surprisingly well in your specific scene. Light tree wonât outperform in every single case, so my suggestion would be to choose whichever method works better, or as @Alaska said, set Emission Sampling as None for large light sources, because when the light source is large, the probability that it gets indirectly sampled is also large. Itâs the small lights that need direct sampling more.
4 Likes
The massive slow down is caused by the large number of triangle lights in your scene (Roughly 83 million triangle lights). It doesnât matter if they are instanced or not (although instanced mesh lights will probably be slower to construct a light tree from).
It takes a long time to process because thatâs a lot of lights and the construction of the light tree is single threaded at the moment. The plan is to hopefully speed up tree building with multi-threading in the future, but at the time this is a limitation that people will need to deal with.
Also, just in case things arenât clear. The number of triangles a mesh light has is the number of lights represented in the light tree. So a cube with 12 triangles, is 12 lights in the light tree.
Your scene contains roughly 16,000 tubes with roughly 5,000 triangles each. (If I understand correctly, mesh lights that emit out of their front and back are actually represented as two lights in the light tree, but thatâs not super important.)
This scene contains a really complex light tree due to the large number of lights. As such, traversing down the tree to pick a light can be really slow, which will reduce the number of samples taken in a given time frame and can increase the noise.
There is also the possibility of some other factors affecting the noise. For example, you are using a shader on the mesh lights that change the alpha/brightness based on co-ordinates on the tubes. This may not be properly representing in the light tree and some mesh lights with low brightness/alpha may end up being over sampled and increasing the noise. (Note: Textures and complex shader node setups are not properly taken into account when constructing the light tree and this is another thing that is being investigated to see how it can be improved.)
1 Like
Instantiate the mesh light twice for front and back side was an earlier idea, but I found out that lights at the same position wonât be separated into different nodes, so that doesnât make sense. Currently a mesh light that emits both sides are still considered a single light, just with a different axis and larger spread.
I guess the next most important thing is parallel tree building, instanced subtree is also important but the implementation doesnât sound very straightforward. Although I wonât have time working on these problems for now.
4 Likes