I confuse about when the rtPotentialIntersection(t) return true? Is t the any hit or must closest hit
Read the following chapter in the OptiX Programming Guide: 4.8.2 Reporting intersections
Starting page for all NVIDIA Raytracing relevant documentation:
I have read many times before I send this topic, following is the statement:
rtPotentialIntersection takes the intersection’s t-value as an argument. If the t-value could potentially be the closest intersection of the current traversal the function narrows the t-interval of the current ray accordingly and returns true.
It says that rtPotentialIntersection return true when the t is the closest hit point. but I usually only commit rtReportIntersection when rtPotentialIntersection return true. If it is true, the any-hit-func in the material program maybe never be invoke if the t is not the closet point.
The crucial part is that all that is done “potentially”, that’s why the function is named rtPotentialIntersection. The interval is not limited unconditionally, but depending on the outcome of a potential anyhit program invocation as explained a few lines further down in that chapter.
Let me highlight the important parts from that chapter:
rtPotentialIntersection takes the intersection’s t-value as an argument.
1.) If the t-value could potentially be the closest intersection of the current traversal the function narrows the t-interval of the current ray accordingly and returns true.
2.) If the t-value lies outside the t-interval the function returns false, whereupon the intersection program may trivially return.
3.) Should that any-hit program invalidate the intersection via the rtIgnoreIntersection function, then rtReportIntersection will return false. Otherwise, it will return true.
4.) If the any-hit program invokes rtIgnoreIntersection, any attributes computed will be reset to their previous values and the previous t-interval will be restored.
In other words:
If the t you calculated inside the intersection is smaller than the current t_max, it will potentially become the new t_max (the currently smallest closest hit distance found) and rtPotentialIntersection returns true, after which you calculate the attributes, so that they become available to the anyhit and closesthit program domains later on, and call rtReportIntersection(materialIndex).
At that point the anyhit program inside the material for that ray type at that index on the GeometryInstance is invoked if it exists, which then can still invalidate that potential intersection t value by calling rtIgnoreIntersection, like normally done for cutout opacity, which will then not keep the t from rtPotentialIntersection to limit the interval for further intersection checks in the interval limits [t_min, t_max] found so far.
“If it is true, the any-hit-func in the material program maybe never be invoke if the t is not the closet point.”
Correct, the anyhit program is not invoked at all when the intersection t value is not in the [t_min, t_max] interval at rtPotentialIntersection. The goal of the BVH traversal is normally to find the closest hit as quickly as possible. That’s the fastest when not actually having an anyhit program on a ray type.
Any other algorithm would need to work with rtIgnoreIntersection and rtTerminateRay to change that behaviour.
Only if the traversal has finished and no more intersections need to be calculated, which is also the case when rtTerminateRay is called in an anyhit program, the closest hit program is called with the smallest t_max found and the matching attributes at that intersection.
Mind that the intersections along a ray are not searched in the order along the ray direction, but depending on the BVH traversal order.
More about this here: https://raytracing-docs.nvidia.com/optix_6_0/guide_6_0/index.html#host#material
It is all very clearly. Thanks for your professional answer. The “potential” is really a word of art.