When the distribution of radiance is extremely narrow, the pdf value will be extremely large.

[Superlee506]

When the distribution of radiance is extremely narrow, the pdf value will be extremely large.

[Tom94]

Hi Chao, glad this codebase is useful to you!

The behavior you're describing is indeed what happens. I believe it is correct. Think, for example, of a point light at position p viewed from a shading location x. The incident radiance at x due to p is a Dirac-delta peak from direction (p-x).normalized(), which is precisely what the situation you are describing converges to.

The reason that the shaded color does not approach zero is that as the same power gets concentrated into a narrower cone of angles, the radiance increases proportionally. Hence, dividing by an ever increasing PDF results in a fixed ratio corresponding to the received power. (Or, rather, an approximately fixed ratio. This is what the PPG algorithms tries to achieve. :))

[Superlee506]

@Tom94 Thanks for your reply.
But I still confused about this. If a point light in the scene, the power is constant. So when the sampled ray hit the point, the radiance is LightColor * cos / pdf. The result is approximately zero when the pdf is extremely large.
Maybe I miss something. Thanks again.

[Tom94]

LightColor * cos / pdf. The result is approximately zero when the pdf is extremely large. Maybe I miss something.

Ah, this is a subtle one. The trouble is that floating point numbers are not good at representing different kinds of infinities (Dirac-deltas, specifically), so point lights are typically implemented in units of power rather than radiance. For the above equation to work, LightColor and pdf both have their Dirac-deltas implicitly divided out (abusing notation), so pdf does not actually refer to a probability density function (as PPG learns it), but rather to a probability mass function.

To make this more intuitive: think of a spherical area light that you keep making smaller while leaving the total emitted power the same. The emitted radiance on the surface of the sphere has to approach infinity such that the ever-shrinking surface can keep emitting the same total amount of power.

Rendering software is often unintuitive by mixing units like that... if you're sampling a point light or a discrete BRDF, renderers such as Mitsuba put probability masses into the same variables that typically hold probability densities. And likewise, the returned BSDF values or light colors may have different units. This makes sense from the point of efficiency, but can be very confusing. This is, by the way, the reason why the PPG code has several special cases for situations where discrete rather than continuous BSDF samples are taken.

(Also: this ties in with your observation about ever increasing PDF values in the quadtree. The quadtree can never learn actually infinite PDFs -- it can only approach them -- so it is useless on perfectly specular surfaces or under purely directional or point illumination. It can only learn continuous PDFs. Not discrete ones as would be otherwise required.)

[Superlee506]

@Tom94 Thanks a lot, Tom.
I make use of PPG in light map baking(all the materials are diffuse), and place an emissive cube in the scene( not use NEE), I find PPG can't improve the quality of indirect light a lot.
For simplify, I don't adopt the spatial subdivision and every texel has it's own Dtree. Even when I increase the building app per texel(200 at the first iteration ), the Dtree don't converge to the direction of emissive cube accurately.

For testing tree, I just generate rays towards the center of cube during the building steps. When sampling tree, I can get the accurate direction but extremely large pdf as described above. This test indicate the correction of my implement.

In light map baking, the distance between texts is large due to the resolution of light map and the distribution of radiance isn't narrow enough (smooth), and so is this method still helpful for baking?