Hi guys, this is my first post here but we have been using Optix for years now and we love it. After a long break we started migrating a lot of our old code base from Optix 5.1 to 7.2 and we’ve noticed it’s insanely painful due to all the changes in the host and device API, but that’s okay. We’ve noticed not only speed improvements but also better results. I’m sorry for the long introduction but I wanted to give it some context, hehe!
Now my question is, we need to use rtPotentialIntersection() (internally called rt_potential_intersection) but it seems it’s gone and we need it for calculating shading normals and other sort of stuff in an intersection program, is there any alternative to this function with the latest Optix SDK?
Thanks a lot in advance for you help!
Hey I’m glad to hear the upgrade is bringing improvements!
For intersection programs in OptiX 7, you can report additional intersection attributes, like normals, to the function
optixReportIntersection(). You’ll notice there are up to 8 generic 32-bit parameters you can pass, in addition to the
hitKind parameters. Then in your hit programs, you can use the
optixGetAttribute_n() functions where n is 0 through 7, to access the attributes that were written in the intersection program.
In an OptiX 7 intersection program, when you want to declare a ray miss, you can simply return from the intersection program without calling
optixReportIntersection(). So, there is no need to have any replacement for the older
Make sure to return early on a miss before doing additional work to compute your attributes, since work done to compute attributes is wasted on misses. It’s also common (and sometimes more efficient) to let that work bleed over to the hit program instead, even if it seems like there is some redundant calculation. The hit programs are typically called far less often than intersection programs, so doing a little extra work to compute normals in the hit program might be overall better than doing the work during intersection. The hit programs always need the attributes, where the intersection programs don’t always need to compute them, so doing the work in the hit shader can improve divergence as well.
Here are a few pointers to some relevant sections in the Programming Guide:
Because the different intersection programs can return different intersection attributes, e.g. the built-in triangle intersection routine returns two for the barycentric beta and gamma values and the curves report only one, and custom intersection programs can report up to eight, it’s still possible to use the same hit programs for different geometric primitives by setting the hit kind appropriately.
This describes the possible encoding for custom intersection hit kinds: https://raytracing-docs.nvidia.com/optix7/api/html/group__optix__device__api.html#gaea539824cff7f2f8c3109ce061eb6ffe
The following functions are just convenient specializations over optixGetHitKind():
Inside the hit programs, the deferred surface attribute calculations for the different numbers and meaning of the reported intersection attributes can then be distinguished with the hit kind and respective cases dynamically.
Note that when porting from OptiX 5 code, that had no built-in support for triangle primitives. That was added with OptiX 6 and refined with OptiX 7. Means there is no need for a custom intersection program for triangles anymore. This is also the only way to make use of the hardware ray-triangle intersection inside RTX boards!
This sentence in the OptiX 7 Programming Guide is not accurate enough:
Although the type of the attributes is exclusively integer data, it is expected that users will wrap one or more of these data types into more readable data structures using __int_as_float and __float_as_int, or other data types where necessary.
Both ray payload and intersection attribute registers are declared as unsigned integers and the proper functions to reinterpret them are __uint_as_float and __float_as_uint and the like for other types.