Optix7Course ex09_shadowRays why does adding a constant red to __closesthit__radiance prd only affect some pixels?

So, I’ve reproed a weird problem using the ex09_shadowRays example. My actual application and problem are much more complicated, but I’ve distilled the actual crux of the failure down to this repro case.

At the very bottom, after all color, shadow and shading has been computer, I add a constant red amount

\optix7course\example09_shadowRays\devicePrograms.cu Line 166:
prd = ((.1f + (.2f + .8f*lightVisibility) * cosDN) * diffuseColor) + vec3f(0.5, 0.0, 0.0);

The expected outcome is that all pixels in the scene acquire an ambient red light. But they don’t. It appears that only pixels that wouldn’t exceed (1.0, 1.0, 1.0) are affected. Any pixels that would exceed the 1.0 ceiling do not change to the red tint.


How is this even possible? Can anyone explain to me the fundamentals of what the heck I’m missing here?

This is a Surface Book 2 15" with the 1060 GPU and Game Ready Driver 441.08. The Studio driver wasn’t new enough to support OptiX 7.

Have a look into how the color buffer is written in __raygen__renderFrame()
Most likely because the output is saturated uchar4 RGBA and not full HDR with tonemapping.

You are correct.

I couldn’t figure out how to insert a clamp() template into the code here, so I just inlined the functionality.

Starting at Line 329:

const int r = int(255.99f*((pixelColorPRD.x < 0.0f) ? 0.0f : (1.0f < pixelColorPRD.x) ? 1.0f : pixelColorPRD.x));
const int g = int(255.99f*((pixelColorPRD.y < 0.0f) ? 0.0f : (1.0f < pixelColorPRD.y) ? 1.0f : pixelColorPRD.y));
const int b = int(255.99f*((pixelColorPRD.z < 0.0f) ? 0.0f : (1.0f < pixelColorPRD.z) ? 1.0f : pixelColorPRD.z));

That seems to have fixed it. I can’t quite reconcile why it was behaving like it was, but I can sort of see.

Thanks for the insight!