No PDF cutoff for light samples with a zero BxDF probability about pbrt-v3

[mmp]

Hi, Brad--

I'm glad the book has been useful to you, and nice debugging there digging into this!

I think what is going on is related to pbrt's handling of shading normals (discussed here.) So a Lambertian BRDF for example always returns R/pi regardless of whether w_i and w_o are in the same hemisphere and reflection/transmission is selected in BSDF::f based on the geometric normal.

However, BSDF:Pdf doesn't do that and just evaluates the PDFs, which do return 0 (for example) for a Lambertian BRDF with w_i and w_o in different hemispheres.

So, I think those 0 PDF values are arising due to that. I think there may be an argument that it's all correct as written (but am not sure about that!). There is no chance of sampling those directions from BSDF sampling, yet the BSDF has a non-zero value. The light sample is still included, the MIS weight ends up being 1, and everything is ok 🤷 . Though I don't remember that as an intentional decision; my assumption looking at that code now (and presumably the assumption when it was written) was that f.IsBlack()==true <---> scatteringPdf==0, other than in rare floating-point edge cases.)

[BradleyMarie]

That explanation lines up with my own understanding of the behavior.

With the non-geometric nature of shading normals, the definition of correctness here is a bit pliable. In the limit case with an infinite number of samples for surfaces like this one the code as written will end up with a value somewhere between the value we’d get from just sampling the BRDF and just sampling the lights. If this in–between value has a useful interpretation, then I think it’s arguable that the value could be considered correct; however, my current feeling is that if a path returns light when it’s sampled by the light source then that same path should be samplable and light-yielding by the BxDF.

Another reason to consider treating the current behavior as incorrect is because the same issue repeats itself with indirect light paths. In this render I modified the Path integrator to ignore direct lighting on the first bounce, but to otherwise render the scene normally. Some of the same areas of darkness show up; however, in this case it feels more bug-like to me since if these areas also lack direct lighting then it means the final image can end up with dark spots in places where there geometrically should have been indirect lighting.

I also glanced over the pbrt-v4 code and it looks like this particular issue involving indirect light no longer exists since BSDF::Sample_f uses the pdf returned from BxDF::Sample_f. That said, I think there may be a different issue for diffuse reflective paths where the pbrt-v4 code can instead sample and return light from transmissive paths since it does not seem to contain the pbrt-v3 logic which re-evaluates if a path is reflective or transmissive after it is sampled.