Curves in OptiX 7.4


I have two questions regarding to curves in OptiX 7.4.0.

  1. Is there a reference implementation to compute a normal and a tangent vector of a strand from the curve parameter for the newly-added Catmull-Rom curves?
    I know the code for linear segments, quadratic, cubic B-splines have been provided in OptiX SDK 7.4.0/SDK/cuda/curve.h, but I couldn’t find the one for Catmull-Rom.
    I want the one which is consistent with the build-in IS.
    I implemented this by myself but the reference implementation is still helpful.
  2. The release notes say:
    "OptixBuiltinISOptions now has a buildFlags parameter that should match the ones supplied to OptixAccelBuildOptions when building the AS containing the built-in primitives."
    Do we need to be sure all the flags including:
    “updatable or not”, “compactable or not”, “fast trace or fast build” matches in addition to the flag for random vertex access?


Hi @shocker.0x15!

Good questions. We do need to update the curve.h header file, thank you for the reminder. Here’s a preview of what we’ll probably add the curve.h header, a reference function you can add to the CubicBSplineSegment class to give it Catmull-Rom powers that you can check against your implementation:

  __device__ __forceinline__ void initializeFromCatrom(const float4* q) {
    p[0] =                   (q[1] *  1.0f)                                  ;
    p[1] =  (q[0] * -1.0f)                  + (q[2] *  1.0f)                 ;
    p[2] =  (q[0] *  0.5f) + (q[1] * -2.5f) + (q[2] *  2.5f) + (q[3] * -0.5f);
    p[3] =                   (q[1] * -1.0f)                  + (q[3] *  1.0f);

For your second question, our official position is that all the buildFlags need to match. This is in part because we provide specialized variants on the intersectors depending on the flags. It’s important to note that even if there are flags that don’t need to match today, that might change in the future.

As it stands, it definitely matters whether the fast-trace / fast-build settings match because those already give you different intersector specializations. Unofficially, I think you might be able to get away with ignoring the matching updatable / compactable flag requirement for now, with the caveat that I don’t know if those could become requirements soon. When you have exceptions enabled, the intersector will throw an exception if flags it cares about fail to match properly, so that’s one way to double-check. If you want to ignore the updatable/compactable flags then it might be a good idea to have a test somewhere that runs with exceptions enabled so you can catch it quickly if we start checking those flags.


Thank you for your quick response and reference code!
I compared my implementation and the reference, it seemed to match.
I understand regarding build flags as well.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.