[7.0] Any-hit for processing all non-opaque geometries inbetween?

Gaming and Visualization Technologies Visualization OptiX
1

Hello together,
for our physics-based simulation engine I am trying to find the best possible way to process intersections with non-opaque geometries.
So far I tried to work mainly with the CH routine as for the opaque geometries, though like this we have to deal with the same challenges.

Situation:
We are trying to follow a ray from the inside of a (closed) geometry and we are using opaque materials to collect information on the ray’s path. Once the ray hits a solid material it gets reflected.

To prevent a large amount of self-intersections and misses from happening, I implemented the adaptive offset routine from the ray tracing gems collection, which reduced the amount significantly. Introducing non-opaque geometries, giving an offset to deal with self-intersection results in more misses (rays get translated out of the closed geometry at triangle connection points). Removing the offset after a non-opaque hit and only offsetting if a self-intersection is registered afterwards reduced the amount of misses, but it’s still somewhat larger than without non-opaque parts (1e-5 opposed to 1e-7).

The idea would be, to use the same ray with an AH routine, this way we could theoretically take note of opaque and non-opaque hits, which are too close together.
If I understand the AH routine correctly though, we could save transparent hits occuring for a specific t_max in an extra buffer (not PRD, as this is too small) and use optixIgnoreIntersection() to move on. Once we register a hit with an opaque geomtry, we would have to call optixTerminateRay() or do nothing. The first would not guarantee, that all non-opaque geometries upto the opaque hit point get evaluated. Doing nothing for an opaque geometry would mean that we have to memorise the potential closest intersection for ourselves (at least the t_max) to properly decide for the final CH call, which non-opaque facets are actually inbetween and which are not.

I have not yet measured the performance decline, that is correlated with enabling and using the AH routine. So I first want to make sure, that the proposed solution makes somewhat sense and whether there are other solutions, which I should consider first or not.

Best regards,
Pascal

2

Hi Pascal,

Your experiment makes sense, and I think it’s worth trying in order to see what the performance difference is, and whether it solves the issue of needing an offset threshold.

One question, do you have partial transparency, or are your non-opaque surfaces always 100% transparent? If you need to somehow shade or do something non-trivial with all the transparent hits, then yes you might keep a buffer of them separately from the payload. If you just want the closest opaque hit, then you could alternatively store only the minimum t_max and primitive ID in your payload, the AH shader can compute the minimum as it goes and discard whichever t value is larger along with the associated primitive ID. You probably would like to gather barycentrics for the minimum hit as well, so unless I’m misunderstanding or forgetting something I imagine you might be able to get away with a total of 4 payload values for this whole scheme (or maybe 5 if you are using instances).

–
David.