Question about building acceleration structures with custom primitives

I can’t find an answer anywhere in the documentation to this question:
I am building an acceleration structure with custom primitives. I’ve create my Axis-aligned bounding box (AABB) buffer, and executed the build, and everything works.

My question is, once the Acceleration Structure is built, do I still need to leave the buffer of AABBs allocated, or can I free it? If the AS bakes the AABB info into it, then I imagine I can free the AABB buffer right after building, but I don’t know if this is okay to do, because the documentation doesn’t say whether the AS will still reference it during the launch.

edit: I should clarify I’m using Optix 7.4. Thanks!

The AABB input buffer is not required after the optixAccelBuild() call anymore.
The acceleration structure result is the OptixTraversableHandle outputHandle and the data inside the CUdeviceptr outputBuffer you allocated upfront with the outputSizeInBytes from the optixAccelComputeMemoryUsage() call.
Only these two objects need to stay alive as long as you’re using that acceleration structure for rendering. (And of course any data you require to implement your custom primitives, but that’s your responsibility to manage.)

Mind that all OptiX API entry point functions taking a CUDA stream argument are asynchronous. That includes optixAccelBuild.
Make sure the AABB input buffer is not deleted before the optixAccelBuild() has been finished.
This could, for example, happen if you’re using an arena allocator instead of CUDA malloc/free calls.
Add the necessary stream synchronization after the optixAccelBuild() call in that case.

1 Like

Thanks for the response!

Just to extend my question slightly, what about instance builds?

If I build a few custom primitive acceleration structures, and then combine them under a single AS using instance build inputs, do the original primitive acceleration structures still need to be kept around? Or does all the information end up in the single, final AS buffer?

Each OptixInstance references a child AS via its traversable handle and that means all these child AS must all be available for the optixTrace calls to work.
The IAS is not capturing the underlying data of the child AS. It’s only building an AABB over the child AS, which is rather quick.
This is unrelated to geometric primitive types because an instance can reference another instance, a motion transform, or a geometry AS traversable handle.

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