Migration OptiX form 3.0.0 to 3.8.0 - Change of behavior of transparent materials

Gaming and Visualization Technologies Visualization OptiX
1

Hello,
if user looks throw 2 layers of the transparent material, material will be bright green
and not transparent in OptiX (version 3.8.0) application now.
The same application on OptiX version 3.0.0 shows transparent materials properly.
In function closest_hit_radiance() the function rtTrace() will be called 3 times (includes phongShade():
…
rtTrace(top_object, ref_ray, new_prd);//refraction ray
…
rtTrace(top_shadower, shadow_ray, shadow_prd);//shadow ray
…
rtTrace(top_object, refl_ray, new_prd);//reflection ray
…

If any of these calls will be deleted, the transparent materials will be not green any more and not transparent.
Possible, my functions closest_hit_radiance() or/and phongShade() are not right, but at OptiX version 3.0.0 the application works properly.
Why the behavior of different OptiX versions can not be the same? Is it possible?

2

Sounds like a stack overflow exception due to recursion with an exception program using a color to indicate that an exception was raised.
If that’s the case increase your OptiX stack size until this doesn’t happen anymore while trying to keep your stack size as small as needed.

You can also print out what the exception code was with an exception program like this:

rtDeclareVariable(uint2, launchIndex, rtLaunchIndex, );

RT_PROGRAM void exception()
{
#if USE_DEBUG_EXCEPTIONS
  const unsigned int code = rtGetExceptionCode();
  rtPrintf("Exception code 0x%X at (%d, %d)\n", code, launchIndex.x, launchIndex.y);
#endif
}

And somewhere in your OptiX context initializing code enable exceptions and printing for debugging only:

#if USE_DEBUG_EXCEPTIONS
    // Disable this by default for performance!!!
    // Otherwise the stitched PTX code will have lots of exception handling inside. 
    m_context->setExceptionEnabled(RT_EXCEPTION_ALL, true);
    m_context->setPrintEnabled(true);
    //m_context->setPrintLaunchIndex(256, 256);
#endif
3

Thank you very much, Detlef,
it is really an exception.
Endless output of strings: “Exception code 0x3FE at (589, 39)” and so on…

I try to make stack very big with m_context->setStackSize().
Already 1Mb! But it not helps.

4

Well, because 0x3FE is RT_EXCEPTION_INVALID_RAY and not RT_EXCEPTION_STACK_OVERFLOW which is 0x3FC.

Please read in the OptiX API Reference document about what values rtGetExceptionCode returns.
Look at rtPrintExceptionDetails as well.

You’ll find the RTexception enum values inside the optix_declarations.h.
The same enums are used to enable individual exceptions with rtContextSetExceptionEnabled.

A stack size of 1 MB is outrageously big. Mind that this is per GPU thread and would eat up gigabytes of your VRAM with that size. The OptiX stack size should normally be only a few thousand bytes.

To figure out the proper stack size, start debugging by only enabling the stack overflow exception, then set the stack size to a small size which does not trigger a stack overflow exception. After that enable all other exceptions and fix any other ones which occur.

To find your invalid rays, check all your ray origin and direction components for not-a-number and infinite values using the functions bool isnan(float) and bool isinf(float) during debugging and fix them.
You might also check if your tmin and tmax values are valid floating point values and 0.0f <= tmin && tmin <= tmax.

5

Thank you very much, Detlef,
i will follow your advice monday.