Confusion about camera ray pdf

Question

When I was studying a code base of path tracing implementation (done in GLSL), I notice the author returned a pdf of generated camera ray:

Ray rayGen(in vec2 uv, out float pdf) {
    // ...
    Ray ray;
    ray.origin = camPos;
    ray.direction = normalize(pinholePos - sensorPos);

    pdf = 1.0 / pow(dot(ray.direction, camForward), 3.0);

    return ray;
}

I understand the 1/cosine^3 of the pdf is from the conversion from differential area to differential solid angle by reading these parts of pbrt - 4.2.3 Integrals over Area and 16.1.1 Sampling Cameras.

But I am confused why the end computed radiance has to divide this pdf for this rather simple path tracing implementation (never seen this in many other implementations):

void main() {
    // ...
    float pdf;
    Ray ray = rayGen(uv, pdf);
    float cos_term = dot(camForward, ray.direction);

    // accumulate sampled color on accumTexture
    vec3 radiance = computeRadiance(ray) / pdf;

    color = texture(accumTexture, texCoord).xyz + radiance * cos_term;
    
    // ...
}

*Lastly I also do not understand above why the radiance that keeps adding into the final color (for progressive rendering, and later will divide sample count) has to multiply a cosine term.

Any insights on these will be appreciated!

Answer 1

I finally figured out where everything came from. More details at my blog post --> https://viclw17.github.io/2024/07/20/glsl-cornellbox-breakdown-p2#ray-generation-raygenfrag

So the generated camera ray has a pdf of 1/cosine_theta^3 that the computed radiance have to divide; then the same cosine term have to multiply the radiance to get the real unbiased result, which in total is equivalent to multiply cosine_theta^4.

Answer 2

A cosine between the cam-view-direction and the ray computes something like a specular area. A highlight. You can compare that with a kind of Phong shading. The more the ray is pointing "away" from the camera center, the lower this cosine gets. In the context of path tracing this would more be like a reflection of the surrounding objects being stronger visible in that area.

(pdf = path distribution factor, if I am not mistaken) In the second snippet as I understand it, might be a bug? Because you probably want to store the average radiance and not something scaled=multiplied by pdf. But the pdf was computed as 1/... in the first snippet, so the division would turn out to be a multiplication. Seems odd.

/* Second thought: Normally you would have a factor "alpha" with the cosine, which controls the size of that highlight area. With just the cosine, that factor would be always 1.... maybe the radiance (second snippet) is meant to be that factor, but it does not quite make sense, because radiance is a vector. */