Optix 7.2 Generating albedo map

Hi,I am still working on my Optix7.2 application on VS2019.
I copy a PathTracer project of Optix SDK Samples.
I want to generate the albedo map of the first patn tracing.
I referenced Optixdenoiser’s project of Optix6.5 Samples to generate albedo textures, but the textures generated are indeed black and white.
as the picture shows;

The code I copied is as follows:

static __forceinline__ __device__ float checkerboard3(float3 hit)

    hit += make_float3(0.001f);
    float checkerboard_width = 40.f;
    int3 c;
    c.x = abs((int)floorf((hit.x / checkerboard_width)));
    c.y = abs((int)floorf((hit.y / checkerboard_width)));
    c.z = abs((int)floorf((hit.z / checkerboard_width)));
    if ((c.x%2)^(c.y%2)^(c.z%2))
        return 1.0f;
    return 0.0f;

extern "C" __global__ void __closesthit__radiance()

    const uint3    launch_index = optixGetLaunchIndex();
    const unsigned int image_index = launch_index.y * params.width + launch_index.x;

    const float3 P    = optixGetWorldRayOrigin() + optixGetRayTmax()*ray_dir;
    params.is_First_hit[image_index] += 1;
    const float3 modulated_diffuse_color = rt_data->diffuse_color* (0.2f + 0.8f * checkerboard3(P));
    if (params.is_First_hit[image_index] == 1)
        params.albedo_buffer[image_index] = modulated_diffuse_color;

I also uploaded my .cu file
PathTracing.cu (13.5 KB)
I sincerely hope you can help me solve this problem.

What exactly is your issue? The image matches what you programmed.

Citing the OptiX Programming Guide:
“The optional, noise-free albedo image represents an approximation of the color of the surface of the object, independent of view direction and lighting conditions. In physical terms, the albedo is a single color value approximating the ratio of radiant exitance to the irradiance under uniform lighting. The albedo value can be approximated for simple materials by using the diffuse color of the first hit, or for layered materials, by using a weighted sum of the albedo values of the individual BRDFs. For some objects such as perfect mirrors or highly glossy materials, the quality of the denoising result might be improved by using the albedo value of a subsequent hit instead. The fourth channel of this buffer is ignored, but must have the same type and dimensions as the input buffer. Specifying albedo can dramatically improve denoising quality, especially for very noisy input images.”

Is that params.is_First_hit buffer used for anything else than tracking if you have written the albedo and normal buffers? Because if not, that is a waste of device memory and can be done with a local variable inside the ray generation program (or a flag on the per-ray data when you need that information inside the closest hit program).

The cleaner approach would be to store the albedo and normal of the current hit inside the closest hit program onto the per-ray payload for the first hit only and then write the result to the output buffers inside the ray generation program in one central place only.

The denoiser takes full range normals in the range [-1.0, 1.0]. Your commented out code setting the params.normal_buffer can only work for the visualization of the normal buffer and for that should better be done with scale and bias (N * 0.5f + 0.5f) to allow inspection of the whole range.

That the light is red is wrong. That should be white since that is emitting light. Means only using the diffuse color is not correct and the emission should be handled as well. Note that the emission is not limited and the albedo needs to be clamped to the valid color value range [0.0f, 1.0f] then.

Also there is a fully working OptiX 7 denoiser example rendering the noisy RGB, and optional albedo and normal buffers, which then used the OptiX HDR denoiser to look at.
That code shows how to generate the additional data here:
and writes those per-ray data fields in the correct range and coordinate space to the optional output buffers here: