Processing intersections in order


I am using OptiX for a specific application where I need to process all intersections along a ray while modifying a payload on every hit. So far, I have been happily using (or perhaps misusing?) any-hit programs that are called for all intersections along a ray in an unspecified order. In the any-hit program, I modify the ray payload and at the end I call rtIgnoreIntersection to make sure OptiX will go find another hit along the same ray.

This works fine and I am happy about it. (This obviously works only because OptiX processes all intersections of a single ray in a single thread, otherwise there would be a race condition when modifying the payloads.)

However, now, I am doing something similar to CSG (constructive solid geometry) and for this purpose, I need to process all the intersections sorted in order, i.e., start with the lowest t and end with the furthest intersection. This is certainly possible with a closest-hit program and calling rtTrace again from the program with t+epsilon. Unfortunately, there is two problems with this approach: 1) the epsilon has to be small enough to catch a close neighboring intersection (e.g., in corners), but big enough not to hit the same intersection again, 2) this slows down OptiX because it has to cast new rays in the same direction instead of reusing the old one it has already computed.

Is there a mechanism that would work like any-hit program, but get called with already sorted intersections?

Thank you!

The answer is no, there is no automatic way to handle that in OptiX
You either need to gather all hits inside the anyhit program like before and then sort them in the raygeneration program or march along the ray direction in order using closesthit programs in an iterative fashion like a path tracer.

See some previous discussion about related topics. Basically read all my replies in these threads and all their links:
[url]distinguish objects when closest hit program occured - OptiX - NVIDIA Developer Forums

If you have coplanar faces which are not distinguishable by front/back facing side like in the last link of the above post, then you would need to implement some sort of instance ID plus primitive ID check which would allow to shoot a ray without epsilon offset and ignore the self-intersection. That’s obviously a little more expensive.
Since for CSG and coplanar faces you really need to find both hits in order which is not possible with a single ray using closest hit approach (you get only one hit and that might not be the volume you’re currently in), the anyhit gathering sounds more feasible.

Ways to identify geometry instances:
More robust self intersection avoidance idea: