Identifying index of build input/mesh upon intersection

For loading models with multiple meshes, I was using an array of buildinputs where each buildinput contains all triangles associated with one mesh.

I want to identify which mesh/buildinput the intersection occurs within the device code.

Is there any native support for this? The other solution I was thinking of is flattening the model into one mesh and then storing the boundary index of each mesh and perform a runtime comparison but that seems somewhat clunky.

Yes there are ways, you don’t need to flatten your meshes.

You can use the primitiveIndexOffset field of each build input, which will be similar to what you said - you will still need the boundary index of each mesh, and you can do a runtime comparison – or – if you have room in your indexing scheme and you know the maximum mesh size, you can encode the build input id into the high bits and your primitive id into the low bits. The resulting encoded primitive id has to fit in 32 bits. You recover the encoded primitive id using optixGetPrimitiveIndex()

There are alternatives, for what it’s worth. You could use instances, if it’s acceptable to put each mesh into a separate GAS. If your meshes don’t overlap a lot spatially, then this should be okay. Using instances, you can then use device functions like optixGetInstanceId() and optixGetInstanceIndex(). If your meshes have a lot of overlap, then it’s probably better to keep them in a single GAS with multiple build inputs.

You could also use unique SBT offsets for each mesh if you want different shader behavior for each build input. The shader you call can be the same code, while still giving you the ability to pass different data to the shaders for each mesh.


1 Like

Thank you for your quick response and that’s such a clever solution!

I am assuming the way to encode the information in the primitive index is by adding a unique primitiveIndexOffset to each buildInput which only affects the high n bits (if my meshes are limited to 2^n) and then extracting that device side?

Yep, exactly!