raytracing.github.io icon indicating copy to clipboard operation
raytracing.github.io copied to clipboard

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

Open Walther opened this issue 3 years ago • 4 comments

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: https://github.com/RayTracing/raytracing.github.io/blob/5c312de55e33fa97b0885b00ec86c908f7adba0b/src/TheRestOfYourLife/pdf.h#L58-L61 and https://github.com/RayTracing/raytracing.github.io/blob/5c312de55e33fa97b0885b00ec86c908f7adba0b/src/TheRestOfYourLife/main.cc#L56-L61

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?

Walther avatar Oct 21 '20 02:10 Walther

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.

LeFou-k avatar Dec 07 '20 14:12 LeFou-k

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!

FelixAntonelli avatar Mar 20 '23 20:03 FelixAntonelli

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 🥳

BenediktKrieger avatar Jan 28 '24 11:01 BenediktKrieger