Clarification of rtAcceleration properties

Gaming and Visualization Technologies Visualization OptiX
1

I had a couple of questions after reading the docs for rtAccelerationSetProperty():

  1. “Refit is only effective if there is an initial BVH already in place, and the underlying geometry has undergone relatively modest deformation.” – this implies I should only call rtAccelerationSetProperty(acc, “refit”, “1”) AFTER having built the bvh for the first time. Is that the case? Or does OptiX know to do a build internally first before refitting on subsequent launches?

  2. “vertex_buffer_name”: Available in: Trbvh, Sbvh The name of the buffer variable holding triangle vertex data. Each vertex consists of 3 floats. The default is “vertex_buffer”. – This seems to imply that if my vertex buffer is in a variable called “vertex_buffer” then OptiX will find it and apply this optimization automatically. Is that the case? Or do I still need to call rtAccelerationSetProperty(acc, “vertex_buffer_name”, “vertex_buffer”) to tell OptiX to look for it?

2

Good questions.

  1. You can set the refit property before you do any builds. OptiX will automatically do a real build the first time and then refit after subsequent calls to accel->markDirty(). You can prove this yourself by messing with the optixMeshViewer SDK sample. The usage report (which is the “-r 2” option for that sample) will print acceleration update times. If you mark the acceleration dirty right before every launch, you should see a different in update times for a refit vs rebuild, although for a mesh this small the difference is not that large.

  2. Yes, if your buffer is named “vertex_buffer” then OptiX will automatically do a triangle build. You can prove this by putting a printf in the aabb program for your triangles. When OptiX applies the optimization it does not call your aabb program, since it already knows you are providing triangles and can therefore compute aabbs internally. If you set the property to a name that doesn’t exist, then your aabb program will be called again and you will see the printfs.