I have a plane with a simple diffuse material. I use an HDR light source from Greg Zaal.

The world setup is as simple as this:

light source

When I preview, the noise seems to increase with the number of samples. When I render, it is the same thing as every tile gets rendered. It starts out pretty noisy and then for each sample, some fireflies is added.

I would expect the fireflies to be many to begin with but be dimmed down when increasing the number of samples.

| improve this question | | | | |
  • $\begingroup$ I've actually been rendering a video to demonstrate this. It's a still image, but the first frame is 1 sample, second frame is 2 samples, etc. It will (naturally) take a LOOOONG time to finish rendering, but I think it'll be an interesting demonstration of what Cycles is doing. $\endgroup$ – Matt Nov 19 '15 at 16:51
  • $\begingroup$ Great @Matt! Can't wait to see the video. How many frames did you plan to render? $\endgroup$ – Carlo Nov 19 '15 at 18:23
  • $\begingroup$ Lol, the original still that I did had more than 3000 samples, which would be 3000 frames... but those 3000 samples took hours to complete, so that'd go from seconds per frame early on, to hours per frame very quickly ;-) I'll probably just let it run until I get tired of not seeing any progress ;-) ... 300 or so $\endgroup$ – Matt Nov 19 '15 at 21:31


The real answer is more complicated than this, but suffice to say, there's a statistical "hump" you have to get over. That is to say, there's a point at which all of the pixels have been sampled enough times that they are at least close to the right value. At that point, more samples will clear things up. Before you reach that "hump," Cycles is still finding all the things that might contribute to the color of each pixel. There will still be lots of pixels that are way off because their first few samples just so happened to be really bright, and it will take more samples to bring them back down to a realistic level.

Here's a bit more of an explanation. It's not very technical, but it is correct. I generally think it's easier to think about it this way than the technical way. You might not, but here goes...

It can be useful to think of Cycles as though it were taking a statistical average of what color each pixel ought to be. Cycles sends out a ray. That ray hits a very bright spot, so it makes that pixel very bright... but Cycles has no way of knowing that the very bright spot is right next to a much darker spot, until it sends out another ray that DOES hit that dark spot. So now it averages the bright pixel it had before with this new dark value and it gets a little closer to the correct color. Until Cycles has enough data to get a reasonably accurate average for most of the pixels, you'll have a bunch of "outliers."

It's a little like if you wanted to calculate the average population per city in the US, but you could only do it one city at a time. If you start your calculations with a city like Wheelock, TX, then your computed average is going to be 350 because that's how many people are in Wheelock. You have to get the populations of more and more cities before your computed average starts to look like the real average. It's the same with Cycles. It's averaging multiple samples per pixel. Some samples are super bright, and not very close to the real average for that pixel. So you're going to have a super bright (or dark) pixel until Cycles gets enough data to bring that pixel down closer to where it's really supposed to be.

There is also another contributing factor. You can (almost) always get brighter, but you can only get so dark. So, it's possible to have a dark pixel that's much darker than it should be (the opposite of a firefly), but the darkest it can possibly be is zero. On the other hand, if you've got a 100000 watt light source somewhere in your scene, it's possible for a sample to hit that source directly. and now you have a single pixel that's 100000 "brightnesses" or so. It will be much harder to average down that very bright pixel to a more correct brightness than to average up the 'zero' pixel. Even if the next sample is only a 1, when you average that with the 100000, you still have a pixel that's 50000 "brightnesses." This means that fireflies are easier to produce than "blackholes," but they're also more persistent than "blackholes." This is what Clamp Direct and Clamp Indirect are for. This is your way to tell Cycles "let's say that 100000 brightness pixel is only 100," so that it's much easier to average out. But it's really easy for that clamping to make things inaccurate, if you're too aggressive with it.

NOW, as for HDRIs, it's a simple matter of having a much larger dataset to sample. With a larger dataset, it's much more likely that any given sample will NOT be close to the correct average, resulting in more grain, rather than less.

Hope that helps!

EDIT: One very good solution to fireflies is actually to render the same image several times, but with a different "seed" value for each one. Then average these images (careful with the opacity math!) together in an image editor. When you save out the file, the 1000000 watt pixel will have to be 1, which is much easier to average with the corresponding pixel from another version of the image that maybe doesn't have that firefly because it sampled differently.

| improve this answer | | | | |
  • $\begingroup$ I see, thanks. I was hoping I was doing something wrong. $\endgroup$ – Gunslinger Nov 19 '15 at 17:03
  • $\begingroup$ Well, your HDRI setup isn't ideal, but it's not invalid. You might take a look at BlenderGuru's Pro-Lighting addon. You can get his demo for free, and it makes HDRI environments much better. You should also check out this article on why HDRIs sometimes don't look right: adaptivesamples.com/2015/11/09/hdri-mpumalanga-veld $\endgroup$ – Matt Nov 19 '15 at 17:10

Fireflies is just the name that we give to the bright, isolated, pixel that seems to create a color discontinuity with the pixel in the neigborhood.

It is said they are resulting

...from numerical instabilities in solving the rendering equation.

So, talking about the rendering algorithm

there is no guarantee that it would converge to the correct solution

Despite this, I think that in your case (and most of the times) the method is able to give a good solution, it's just a matter of iterations number.

Below you can see a few steps of the rendering process and an ending comparison with the result achievable by enabling Multiple Importance samples (see Commonly Ignored Features #1 from the author of the HDRI)

enter image description here

So "fireflies" from this point of view, can be considered as just the earliest stage of the rendering process, as they are when rendering caustics. We consider them bad because compared with other parts of the scene the area where they appears is always behind in terms of convergence.

Stop killing the wonderful fireflies! :)

| improve this answer | | | | |
  • $\begingroup$ Thanks. Turning on the Multiple importance sampling made the shadows much much sharper. So I turned it off again. :-) $\endgroup$ – Gunslinger Nov 19 '15 at 17:55
  • 1
    $\begingroup$ I think that most of Greg Zaal's efforts in his HDRI-making have been done in order to finally get those incredibly sharp shadows. :) Try to use his node setup and lower the amount of high values to the average. $\endgroup$ – Carlo Nov 19 '15 at 18:09
  • $\begingroup$ Hehe... thanks for the explanation and digging. :-) $\endgroup$ – Gunslinger Nov 19 '15 at 18:17

One way to reduce noice is to render with fewer samples, but many images with different seed. Of course, reflections (but not scene detail) are smoothed and details might be missed. We are still approaching "the hump".

Ten images manually combined, each rendered with 20 samples. 10x20 samples

One image rendered with 200 samples.

enter image description here

| improve this answer | | | | |

Your Answer

