Book 3.10.1: Probability density functions could cause NaN's?

[Walther]

Sorry - I'm not 100% sure if this should be an issue, feel free to discard if considered not applicable!

[The following refers to cosine_pdf::value() — @hollasch]

Consider the following:

raytracing.github.io/src/TheRestOfYourLife/pdf.h

Lines 58 to 61 in 5c312de

	virtual double value(const vec3& direction) const override {
	auto cosine = dot(unit_vector(direction), uvw.w());
	return (cosine <= 0) ? 0 : cosine/pi;
	}

and

raytracing.github.io/src/TheRestOfYourLife/main.cc

Lines 56 to 61 in 5c312de

	auto pdf_val = p.value(scattered.direction());
	return emitted
	+ srec.attenuation * rec.mat_ptr->scattering_pdf(r, rec, scattered)
	* ray_color(scattered, background, world, lights, depth-1)
	/ pdf_val;

a cosine_pdf.value returning zero can result in a division by zero in the main loop, and cause a NaN.

When adding some debug prints to my own implementation, on a conditional of pdf_val == 0, I got plenty of those, and they were causing NaNs.

However, for some reason, adding the similar debug prints to the example scene in this repo, I was unable to reproduce it. Wonder if that is just due to some implementation bug on my part, random luck, or something else.

---

Should there be some additional logic somewhere? E.g.

• make sure the pdf's don't return zeroes?
• make sure that we don't divide by zero at the end of ray_color ?
  • return something else conditionally; what?
• other, what?

[LeFou-k]

I also have the same problem. In order to solve this, I add a EPSILON (like 0.0001 or so), so the pdf would be pdf + EPSILON but the output was bad. The spp100 output was worse than the one that had not been done importance sampling. I wonder if there's some better method to solve this.

[FelixAntonelli]

I have been following this book series for a uni project and as such have had to do some research into PDFs, in most places I have seen the Cosine Density function described as 1/(2pi)(1+cos(x)) but the book uses cos(x) / pi. Having done some testing it seems that using 1/(2pi)(1+cos(x)) removes all black pixels from my renders and im wondering if this is what is causing the issue? I plotted both versions on Desmos, the version used in the book (red) dips below zero at the extremities whereas the other version (blue) does not. Here's a render I did with the Cosine PDF from the book gyazo and another one I did with the other version gyazo, the black pixels in the center of the image are almost completely gone.

Maths is not my strong suit so there's a distinct possibility that I am way off here but i'd like to be corrected if so!

[BenediktKrieger]

thank you so much! I was searching for the reason my code was producing NaNs when mixing pdfs. Its quite surprising that if I render only with the lamber/cosine-pdf or the light-pdf I get no NaNs. Only when mixing the potentially very small pdf-values I get NaNs :) Book 3 is no running with Importance sampling at a whopping 1400fps 1spp 1080p with the cornell-box 🥳