Thank you for all the details! Right, writing a curve intersector is a bit more than IS for a sphere or a triangle. The topic is interesting for itself to me, so I have done some more tests. In the end, all the speed differences are not that extreme, on the level of 20-30%, plus there are other factors like artifacts, so the conclusion for my case is probably to keep both, bezier and b-splines options, and let users choose.
My bezier code also has the limitation of intersecting only with the front face. It makes writing transparency and sub-surface effects so complicated that I just gave up for now. Having back face supported would be so great… :)
Usually, I need to support long strands with multiple control points. If the curvature is too high then the Phantom intersector for the Bezier curve produces artifacts, like indicated in the first image. Splitting helps, and also increases the speed (second image).
B-splines from OptiX do not show artifacts for the same control points, in both cases, but curve object is slightly different (smaller) and the fps comparison is not exactly 1:1.
Previously I tried with the OPTIX_BUILD_FLAG_PREFER_FAST_TRACE flag, now I also checked what happens with the OPTIX_BUILD_FLAG_PREFER_FAST_BUILD flag - interesting, fast build can also be a faster trace… again, differences are small but persistent. I tried on a curve with 400 points (too few for the Phantom intersector) and with 800 points. Below are images with linear segments to show how points are distributed.
And the fps are below, note that OPTIX_BUILD_FLAG_PREFER_FAST_BUILD results with faster trace in case of dense points:
fast trace fast build
lin: 1.30 1.25
quad: 0.80 0.75
cube: 0.66 0.63
n=800 (dense enough to avoid artifacts with Bezier)
fast trace fast build
lin: 1.19 1.32
quad: 0.70 0.80
cube: 0.59 0.67
As I mentioned - approximation/interpolation, artifacts or clean render, slightly faster/slower - to me it is great to have both at hand, Phantom Beziers and b-splines. The bigger issue are difficulties with the back face intersection… (maybe that is not so common problem if curves are used for tiny hair-like objects in most applications).
Large ptx size is not problematic for me. I gues it is a result of inlining code from curve.h in several CH programs I have. I’ll try reducing the math to minimum needed to get normals.
In case I can share my IS program for Beziers, but I simply followed the Phantom paper. Code producing images above is a simple python script, I can share that as well if you’d like to repeat the experiment.
Thanks again for all the explanations!