Are intersections still hardware accelerated if we define a custom intersection program in Optix?

Question

I've stumbled into Optix samples that define their own intersection programs to define how primitives intersect (or don't) with a ray, and others (mostly those only dealing with triangle meshes) that don't.

Maybe I haven't really figured out exactly what is hardware accelerated when we write programs using Optix, but I would've guessed that checking the intersection is the costly (and thus hardware accelerated) part. So why are we allowed to write our own software intersection programs? Maybe I'm not really understanding how the hardware acceleration of raytracing works?

Answer 1

Raytracing cores can generally do two hardware accelerated things:

1. Test an intersection between a triangle and a ray.

2. Traverse a BVH (Basically to test an intersection between bounding boxes and a ray).

When things are raytraced we don't typically loop through every triangle and test each one. Instead the triangles are placed into a BVH (https://en.wikipedia.org/wiki/Bounding_volume_hierarchy) which is a set of boxes which partition the triangles. We first test the ray against this BVH as it allows us to quickly ignore large sets triangles.

Eg, if you have a box with a million triangles inside and the ray doesn't intersect the box you know it won't intersect any of the triangles either using only one test.

If you want to intersect something which isn't a triangle, for example a curve (for hair) or a sphere, you can write your own non-hardware accelerated program which will still benifit from traversing the BVH but will call your intersection program to test individual primitives.