We are evaluating Optix as a replacement for our multi-core raytracing engine and have notice a very disturbing tend in the software’s development. Staring with version 4.0, all of the C-API demos (samples1-6) have been removed from the distribution. Additionally, there are a number of errors in the documentation that make it unclear as to weather or not Optix is a C++ only API: a glaring example is on the front web page (https://developer.nvidia.com/optix) which lists
Programmable GPU-accelerated Ray-Tracing Pipeline Single-ray shader programming model using C++
I can tell you that C++ is a non-starter for us, and that the disturbing trend away from C support (e.g. not one single sample or demo in Optix 5.0 that demonstrates a pure C usage-case) makes potential adopters (us) very nervous about investing any more time or money into adapting to Optix if the development team is pushing for an API that emphases personal coding convenience/tastes and layers of dependencies over end-user flexibility and choice.
It seems clear that the original developers of Optix worked in C and I fear that a second-generation squad has seized control and started dismantling its foundations. Historically that indicates the founders have moved on and the project has entered into a slow decay and will eventually disappear (e.g. NVIDIA’s Gelato).
Can the Optix team reaffirm its support of the C API, and will it demonstrate that support by including a supported and maintained C-only demo in future release? Consider that the “flat-ness” and simplicity of the C language is also much more amenable to learning a new API and will lower the learning barrier to many new users.
If the answer to the above question is “no”, we will most-definitely pursue developing our own CUDA C ray-racing solution.
Case and Point:
On page 29 of the new (5.0.1) Programming Guide, section 3.5.3, the table entry description for “vertex_buffer_stride” makes mentions of “TriangleKdTree” and “Sbvh”, neither of which are listed under the “Available” column—the former (Kd Tree) has also been removed from the list of supported acceleration structures. Again, I had to go back to the (much more polished) 3.9.2 documentation to see that this method existed but has been dropped. In our experience on the GPU, Kd-Tree’s were the fastest acceleration method for path-tracing, but slow to build unless parallel-ized. We are assured (again back in the 3.9.2 documentation) that TriangleKdTree “…is rarely comparable to the SBVH in ray tracing performance”. While certainly possible, I find it disturbing again that we (the end-user) are no longer able to confirm this for ourselves, and the current Optix development team has decided “what is best” and removed our ability to experiment and draw our own conclusions. This is much like the post-4.0 team’s decision to shove C++ upon the developer, and again, a disturbing trend.