Feature Request: device side instance creation

[natevm]

At the moment, users can edit instance transforms in parallel with a compute shader. However, all instance references must be given on the host in series, because SBT construction is done on the host.

In particular, since each BLAS record has multiple geometry references, if the user were to dynamically set which BLAS record to assign to an instance in a compute shader, we would still need to download all these references back to the host and then count how many geometries an instance references for a given frame.

This limitation is unfortunate, because a user might for example want to swap out which BLAS is referenced in a TLAS on the device, eg for supporting dynamic level of detail.

This also ties our hands in other ways, for example, when using instance transforms for OBBs, that case requires that each geometry referenced by each instance get its own SBT record, associating which programs a particular instance’s geometry should call. Doing this in series on the CPU is very inefficient.

[natevm]

For the OBB case in particular, ideally, the geometry ID would not contribute to the SBT record index, since 1 million OBBs is a very reasonable count, but 1 million SBT records is not.

We might consider changes to the API to allow for a different sort of instance tree or geometry or some sort, where we force the ray stride on the device to be 0 (disabling geometry ID from indexing into the tree).

Then, the tree would look almost like a single level tree, with BLAS and TLAS all handled under one common geometry object thing… the TLAS would need to be what owns a single common hit group, and then the TLAS couldn’t support more than one geometry type (triangles, AABBs)…

This breaks current assumptions with the API though. I’m not sure how to do this elegantly.

[natevm]

Part of the issue here is that we’ve tightly coupled hit records to geometry. But there are cases where hit record should be per instance, not per geometry.

[natevm]

Kinda interesting, we currently assume with our BLAS that we have a tree containing solely triangular geometry, or a tree solely containing AABB geometry. We might be able to leverage this constraint somehow…

[natevm]

One thought, if we were to allow an instance acceleration structure to have its own single SBT record, then an issue there would be that some blas use AABBs while others use triangles. So we don’t know when building an RT pipeline whether to request a triangle record or an AABB record.

What we could do though is request both types preemptively, and then use an instance offset to select which one to use for a given BLAS