Triangle Splitting

Does Optix have in built triangle splitting? I’m running into an issue where very large triangles mixed with very small ones cause lag, and we were wondering if this is because it disrupts the BVH construction. Would this be the case? Or is there already triangle splitting built into the BVH construction?

Hi @atm008,

When does this lag happen, e.g., during BVH build, or during render, and how long it is?

There are scenarios where some triangle splitting happens, in order to optimize trace performance. You can test your hypothesis using either OPTIX_BUILD_FLAG_PREFER_FAST_BUILD and/or OPTIX_GEOMETRY_FLAG_REQUIRE_SINGLE_ANYHIT_CALL. Either of those should prevent any splitting from happening, I believe.

Let me know how that experiment goes; I’d be a bit surprised if splitting causes noticeable delays, but if it does it would be nice to understand the situation.


David.

Please also provide some absolute coordinates for what you consider large and small triangles and maybe what these represent.

Generally, when asking about OptiX issues, please provide the system configuration as well:
OS version, installed GPU(s), VRAM amount, display driver version, OptiX major.minor.micro version, CUDA toolkit version used to generate the module inputs, host compiler version.

Hi @dhart
The lag happens during the render. Give me a bit to try to isolate the secondary effects of large primitives.
Building the GAS takes 0.005 seconds and rendering takes 3.71 seconds.

Driver Version: 545.29.06
CUDA Version: 12.3
OptiX Version: 7.6
GPU: GTX 3090

Okay, that sounds interesting. Even if some triangle splitting does occur, as far as I know, it should only help improve render times. The tradeoff cost for any triangle splitting is slightly increased BVH build times. That is, when using PREFER_FAST_BUILD, splitting is disabled (among other things) in order to prioritize the BVH build time over render time. When using PREFER_FAST_TRACE, the render time is prioritized, and some things are done during BVH build that might make the BVH build take a little longer but generally result in faster rendering. Given that your render time to build time ratio is around 1,000 in this case, it makes the most sense to use PREFER_FAST_TRACE, which will allow splitting if the BVH builder deems it necessary. When splitting happens, it is quite bounded in nature, some long & skinny triangles might be split once in order to improve the bounding box, but it is not recursively subdividing large triangles or anything like that. You can measure the compacted BVH buffer memory difference when using the FAST_BUILD and FAST_TRACE flags, and that will give you a good sense.

One thing that might be happening with very large triangles is you might be getting bad bounding box overlap problems. For that, pre-splitting large triangles recursively until all your triangles are approximately the same size might be a good solution to improve the render performance.


David.

Hi @dhart
Yeah it was something else. I found the bug. Thanks for the information, knowing about how OptiX decides to split triangles was helpful.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.