# Naive Path tracer produces much darker images than Explicit light sampling

So I just thought of comparing the results from a Naive Path tracer and one using Next Event Estimation aka Explicit Direct Light Sampling. However the results from the Naive PT are very dark.

Is this expected? The one with next event estimation produces brighter images like in my previous question which was related to MIS

I thought that a Naive PT would produce images with the same brightness but more noise and it would take longer to converge. The main reason for dark images I think is because I'm averaging the colors obtained from the previous run with the next run. On each run I shoot 1 sample per pixel.

This means if I take 20 samples (20 passes) and only 2 samples ($$S_1$$ and $$S_2$$) are useful (hit the light in the end) and 18 return 0 since they don't hit the light, I'd be doing,

$$\displaystyle{\frac{S_1 + S_2 + 0*18}{20}}$$

The brighter colors will surely get averaged out. Moreover they won't converge or in other words they won't get brighter since the number of useless samples surely outweigh the number of useful samples. However in every implementation I could find over the net, people averaged it simply like I did. So is that actually a problem or is it expected?

I stumbled upon this question which is pretty much the same thing OP is asking but in the end they find problem with the raytracer and not the path tracer. I don't understand.

If you guys are interested in the code, here is my kernel. The main functions to look for are shading() which contains the whole bouncing around portion. EvaluateBRDF simply evaluates the blinn phong model. The averaging out is done in the main kernel evaluatePixelRadiance in the end.

UPDATE:- So I corrected what Stefan pointed out and removed color clamping. I was using an 8bit depth default framebuffer and RBO of 32 bit floating points. So I guess the data gets clamped automatically when blitting to the default framebuffer. And it seems to have solved the issue. I'll update the results shortly.

I think this solved my MIS issue as well, will share results on MIS post soon. Here is the one for naive-PT, 5000 samples in around 10 seconds. And it seems I was not getting fireflies since i was clamping radiance as expected. Good to learn new things :)

## 1 Answer

It looks like you're clamping all your samples to 0-1 in line 215. Apply clamping only when displaying the image, not when accumulating samples.

• Ok I think i get what you are telling me. So basically the color obtained on any pass can be greater than 1. And this extra information is lost when i clamp. I don't think it'd make such a great deal as the main problem is still averagin with samples giving 0 color. But anyway, how are you supposed to handle that in a progressive PT? Jan 11, 2019 at 20:14
• In a progressive path tracer you'd still need to store the total value and number of samples so far per pixel, otherwise there is no way to calculate the average when you take new samples. You'd only clamp it for display purposes Jan 13, 2019 at 9:47
• I'll try storing the total color in the w coordinate since I'm using a float4 and pass a single variable for number of iterations to the kernel. Will post resutls shortly. Jan 13, 2019 at 10:05
• Ok i totally forgot it's three channels worth of information :s How the heck am I suppose to store 3 channel worth information. That's basically an extra image passed to the kernel just for storing un clamped values? Jan 13, 2019 at 10:13
• Many thanks for pointing it our bro. I was at it for days. Jan 13, 2019 at 13:58