OptiX | End goal | GPU library

The short answer to the title question is: yes, hardware accelerated ray casting is available in CUDA & OptiX. The longer question has multiple interpretations, so I'll try to outline the different possibilities.

The different axes of your question that I'm seeing are: CUDA vs OptiX, pre-RTX GPUs vs RTX GPUs (e.g., Volta vs Ampere), min ray queries vs max ray queries, and possibly surface representations vs volume representations.

pre-RTX vs RTX GPUs:

To perhaps state the obvious, a K80 or a GV100 GPU can be used to accelerate ray casting compared to a CPU, due to the highly parallel nature of the GPU. However, these pre-RTX GPUs don't have any hardware that is specifically dedicated to ray casting. There are bits of somewhat special purpose hardware not dedicated to ray casting that you could probably leverage in various ways, so up to you to identify and design these kinds of hardware acceleration hacks.

The RTX GPUs starting with the Turing architecture do have specialized hardware dedicated to ray casting, so they accelerate ray queries even further than the acceleration you get from using just any GPU to parallelize the ray queries.

CUDA vs OptiX:

CUDA can be used for parallel ray tracing on any GPUs, but it does not currently (as I write this) support access to the specialized RTX hardware for ray tracing. When using CUDA, you would be responsible for writing all the code to build an acceleration structure (e.g. BVH) & traverse rays through the acceleration structure, and you would need to write the intersection and shading or hit-processing programs.

OptiX, Direct-X, and Vulkan all allow you to access the specialized ray-tracing hardware in RTX GPUs. By using these APIs, one can achieve higher speeds with lower power requirements, and they also require much less effort because the intersections and ray traversal through an acceleration structure are provided for you. These APIs also provide other commonly needed features for production-level ray casting, things like instancing, transforms, motion blur, as well as a single-threaded programming model for processing ray hits & misses.

Min vs Max ray queries:

OptiX has built-in functionality to return the surface intersection closest to the ray origin, i.e. a 'min query'. OptiX does not provide a similar single query for the furthest intersection (which is what I assume you mean by "max"). To find the maximum distance hit, or the closest hit to a second point on your ray, you would need to track through multiple hits and keep track of the hit that you want.

In CUDA you're on your own for detecting both min and max queries, so you can do whatever you want as long as you can write all the code.

Surfaces vs Volumes:

Your question mentioned a "3D volume", which has multiple meanings, so just to clarify things:

OptiX (+ DirectX + Vulkan) are APIs for ray tracing of surfaces, for example triangles meshes. The RTX specialty hardware is dedicated to accelerating ray tracing of surface based representations.

If your "3D volume" is referring to a volumetric representation such as voxel data or a tetrahedral mesh, then surface-based ray tracing might not be the fastest or most appropriate way to cast ray queries. In this case, you might want to use "ray marching" techniques in CUDA, or look at volumetric ray casting APIs for GPUs like NanoVDB.

As @talonmies notes, CUDA has two (official) host-side APIs: The "CUDA Runtime API" and the "CUDA Driver API"; you can read about the difference between them here.

You have mentioned files and CMake identifiers relating to the Runtime API: cuda_runtime.h, CUDA::cudart. But - "CUDA Contexts" are concepts of the Driver API, and cuCtxGetCurrent() etc. are driver API calls.

Specifically, an "undefined reference" is indeed a linker error. In your case, you need to link with the CUDA driver. As a library, on Linux systems, that's called libcuda.so. For that to happen, and for your executable named ERPT_Render_Engine, you need to add the command:

The execution fails when it tries to enable or access a dedicated graphics card/driver:

Implement a meta-function using template specialization that maps standard C++ types to OptiX types with the desired "rank":

Seems pretty simple, you need to move push_back so that it is inside your loop, not after your loop.

Something like this

In glTF, normals are stored per vertex. The normals for faces are typically calculated during rasterization (hardware) in most graphics pipelines, as a linear interpolation between vertex normals for that face.

For what it's worth, glTF does specify a counter-clockwise rotation in primitive.indices. However, materials in glTF are allowed to be double-sided, and the specification for Double Sided indicates that when viewing the back face of a surface, one must flip the normal before evaluating the lighting.

In practice, sometimes authoring tools produce polygon meshes that are inside-out, or even have thin-walled (non-manifold, or non-water-tight) geometry. In such cases it can be difficult to say what is "inside" vs. "outside" as they look the same, and the winding order may be arbitrary. (In Blender Edit Mode, click menu Mesh -> Normals -> Recalculate Outside to fix this).

For single-sided materials, the winding order should not be arbitrary, as the back sides are hidden from view. One would expect counter-clockwise winding order triangles when using those materials. In Blender, this can be done by selecting the "Eevee" engine, bringing up the material properties panel, and putting a checkmark on "Backface culling". Make sure this happens in the material settings, NOT in the viewport settings, otherwise the glTF exporter won't find it. Use "Material Preview" viewing mode to see the result.

If all my faces are flat/not curved, should I be able to use any of these without even having to compute anything?

Yes, if you have completely flat faces, I would expect the vertex normals within each face to be equal, such that linear interpolation would not produce any changes to the normal vector.

It's possible the two cubes share the same mesh. In the screenshot below, there are two Blender "objects", Left-Cube and Right-Cube. Both objects use the same Blender mesh, called Shared-Cube-Mesh.

The glTF exporter recognizes this pattern and mirrors it in the glTF file. There will be two glTF nodes, corresponding to the two Blender objects that use the mesh. But there will only be a single glTF mesh, with a single cube.

You can click the "number of users" button, shown below with a white arrow pointing to it, to make the second object use its own unique mesh. But be warned, this doubles the amount of mesh data being exported to glTF in this simple example. A complete copy of the mesh would be made in both Blender and the glTF binary payload.

After looking further at the error and the original instantiation of the context, it turns out that the optixWhitted example uses a wrapper class to handle the rtContext object. The two objects are different classes and in doing some digging around, I discovered that NVIDIA has included the ContextObj class as a convenience wrapper for the underlying rtContext. This ContextObj class has very similar functions to the rtContext and functions outlined in Chapter 3 of the OptiX 5.1 Programming Guide.

Looking through the ContextObj class, you will find analogous functions for setting the rtPrintf settings: OptiX ContextObj Wrapper Class.

Specifically you'll find these functions:

• setPrintEnabled(bool)
• setPrintBufferSize(uint)

Final Working Code

This is the final working code, that uses the ContextObj wrapper class already present and in use inside the optixWhitted tutorial.