Small intense light clashing with big dim light

I have run into a problem during my rendering and created a very simple scene to illustrate it.

All is done using Blender 2.79 / Cycles / Filmic.

I have a tiny light with very high intensity (a bulb filament, colored yellow) and on the other side geometrically big light with very small intensity (dark window, colored blue). The lights are icospheres with emission nodes in their materials.

Problem: The rendering depends very much on the scale of the lights.

If the lights are the same size, the intensities are 10 000:1, the result is as expected:

However, when the right dim light is scaled this happens. Everything else, including the render settings is identical:

This happens, when render samples are increased 100 times (!):

What I think is happening:
Cycles is sampling light paths randomly, but gives precedence to the bigger light sources, even though their intensity is small. At first I thought that Cycles has no other option, as it doesn’t know the intensity in advance and has to calculate it using the Nodes AFTER it has found it and hit it with some light ray.

However, there is a difference if the big light has set an intensity of 0.000001 and 0. The first case results in the problematic scenario on image #2 (though the big light is now invisible and has no effect on the scene). But the second case is results in flawless scenario #1. This means, that Cycles knows IN ADVANCE that some light is not useful and can optimize it out.

So the question is:
Currently Cycles uses [Light geometric size] in its ratio calculations. It might be better to use [Light geometric size * intensity]. Is it possible to turn this on somewhere? Or file this as a half-bug? :slight_smile: Or use some other render setting I don’t know?

Here is the .BLEND file I am using.

It isn’t a bug. Cycles is a path tracer. Small light sources are difficult to find. Large light sources are easy to find.
The solution is to use sufficient samples to more accurately portray the lighting.

Thanks, but I think you are missing the point. The small light sources were very easy to find until I added large light source anywhere in the scene, I think it could even be 10 km away and completely dim - but after adding the rendering output start to suffer horribly.

The algorithm could be hugely improved in my case, if it took the light intensity into account when deciding to what light it should shoot the light-tracing ray. Currently, the light intensity is ignored, except for when it is absolute 0.

Sometimes when doing lots of tiny spotlights with larger fixtures in the room, I render out separate light passes and simply add them together in post. Self emitting materials should be either masked out, turned off in one of the passes, or turned off in both and rendered out separately. In some cases, especially if the light is small like insignificant screens or diodes, turning off multi importance sampling might help.

The issue stems from the fact that Cycles is seeing the big light as more important (so it gets the vast majority of samples).

There are ways out there that could improve on this situation significantly, but they are not found in Cycles at the moment. However, you can already uncheck the multiple importance sampling checkbox (which is supposed to help a bit with cases where there are larger, but less powerful lights).

branched path tracing might help.

Yes, you are right, this would work (or at least it should). I just wanted to avoid this solution to be able to see the effect quickly in preview without using the compositor.

Thanks, I wasn’t aware of this, however I cannot seem to make it working. But probably no need because:

Perfect!!! It was enough to just uncheck this checkbox for the big blue light material. Then everything works as I hoped. Many thanks!

Also remember that when using an emission shader on a mesh object, the amount of light it outputs increases with the size of the mesh, unlike lamp objects where the size control only affects the softness of the light.

Thanks, yes, I am aware of that, but this was just a simple scene create solely to illustrate this particular rendering behavior.