VisRTX is an experimental, scientific visualization-focused implementation of the Khronos ANARI standard.
VisRTX is designed to track ongoing developments of the ANARI standard and provide usable extensions where possible. Prospective backend implementors of ANARI are encouraged to use VisRTX as a much more complete example of a GPU-accelerated, ray tracing based implementation of ANARI.
Note that the ANARI implementation of VisRTX is a complete rewrite from previous
versions. Please refer to the v0.1.6 release of VisRTX for the previous
implementation.
VisRTX is supported on both Linux and Windows.
Building VisRTX requires the following:
- CMake 3.17+
- C++17 compiler
- NVIDIA Driver 530+
- CUDA 12+
- ANARI-SDK
Building VisRTX is done through invoking CMake on the source directory from a stand alone build directory. This might look like
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=path/to/desired/install /path/to/visrtx/source
make
make installThe OptiX and ANARI-SDK dependencies can be found via placing their installation
locations on CMAKE_PREFIX_PATH, either as an environment variable or a CMake
variable.
The build will result in a single libanari_library_visrtx library that will
install to ${CMAKE_INSTALL_PREFIX}/lib, and is usable with any ANARI app if
either it is installed to the same location as the ANARI-SDK or
libanari_library_visrtx is placed on LD_LIBRARY_PATH respectively.
The following sections describes details of VisRTX's ANARI completeness, provided extensions, and known missing extensions to add in the future.
In addition to standard ANARI_KHR extensions, the following extensions are
also implemented in the visrtx device. Note that all extensions are subject to
change.
This extension indicates that applications can use pointers to CUDA device memory when created shared and captured arrays when using VisRTX. All the normal rules for shared and captured array data still apply.
This extension indicates that raw CUDA GPU buffers from frame objects can be mapped for applications which are already using CUDA. The following additional channels can be mapped:
"colorCUDA""depthCUDA"
GPU pointers returned by anariMapFrame() are device pointers intended to be
kept on the device. Applications which desire to copy data from the device back
to the host should instead map the ordinary color and depth channels.
The dataCentering parameter controls how spatial field data is interpreted relative to the grid structure.
This extension enables fine-grained control over whether data values represent quantities at grid vertices
(node-centered) or at the center of grid cells (cell-centered).
Supported Values:
"node": Data is centered at grid vertices (node-centered). Each data value corresponds to a grid point."cell": Data is centered at cell centers. Each data value corresponds to the center of a voxel/cell.
Note
The spatial extent of a StructuredRegular volume depends on the dataCentering parameter.
When set to "node", the extent is [origin, origin + (data.size - 1) × spacing].
When set to "cell", the extent is [origin, origin + data.size × spacing].
Allows clipping a spatial field to an application-defined box in object space.
Two optional parameters on structuredRegular and nanovdb fields define the
box; omitting either leaves the bound open.
Parameters:
roi(FLOAT32_BOX3): the restriction box to apply (default: unbounded).
The structuredRectilinear spatial field type provides efficient sampling of structured grids with
rectilinear (non-uniform) spacing. Unlike structuredRegular which assumes uniform spacing, this type
requires explicit 1D coordinate arrays for each axis.
Parameters:
data(ARRAY3D): The 3D voxel datacoordsX(ARRAY1D): X-axis coordinates (required)coordsY(ARRAY1D): Y-axis coordinates (required)coordsZ(ARRAY1D): Z-axis coordinates (required)filter: Filtering method (same as structuredRegular)dataCentering: Cell vs node centering (same as structuredRegular)
The axis coordinate arrays define the actual position of each voxel along that axis, enabling support for non-uniform grid spacing commonly found in scientific simulations.
The nanovdbRectilinear spatial field type extends NanoVDB support to rectilinear grids.
It supports all NanoVDB grid types (Fp4, Fp8, Fp16, FpN, Float) with rectilinear coordinate transforms.
Parameters:
gridData(ARRAY1D): Serialized NanoVDB grid datacoordsX(ARRAY1D): X-axis coordinates (required)coordsY(ARRAY1D): Y-axis coordinates (required)coordsZ(ARRAY1D): Z-axis coordinates (required)filter: Filtering methoddataCentering: Cell vs node centering
This type automatically detects the grid type from the NanoVDB metadata and routes to the appropriate sampler implementation.
The following section describes what additional parameters and properties can be used on various ANARI objects.
The device itself can take a single INT32 parameter "cudaDevice" to select
which CUDA GPU should be used for rendering. Once this value has been set and
the implementation has initialized CUDA for itself, then changing this to
another value will be ignored (a warning will tell you this if it happens). The
device will initialize CUDA for itself if any object gets created from the
device.
The following properties are available to query on ANARIFrame:
| Name | Type | Description |
|---|---|---|
| numSamples | INT32 | get the number of pixel samples currently accumulated |
| nextFrameReset | BOOL | query whether the next frame will reset accumulation |
The numSamples property is the lower bound of pixel samples taken when the
checkerboard renderer parameter (see below) is enabled because not every pixel
will have the same number of samples accumulated.
The nextFrameReset property can give the application feedback for when
accumulation is about to reset in the next frame. When the property is queried
and the current frame is complete, all committed objects since the last
rendering operation will be internally updated (may be expensive).
The following extensions are either partially or fully implemented by VisRTX:
KHR_ARRAY1D_REGIONKHR_CAMERA_DEPTH_OF_FIELDKHR_CAMERA_ORTHOGRAPHICKHR_CAMERA_PERSPECTIVEKHR_DEVICE_SYNCHRONIZATIONKHR_FRAME_ACCUMULATIONKHR_FRAME_CHANNEL_PRIMITIVE_IDKHR_FRAME_CHANNEL_OBJECT_IDKHR_FRAME_CHANNEL_INSTANCE_IDKHR_FRAME_COMPLETION_CALLBACKKHR_GEOMETRY_CONEKHR_GEOMETRY_CURVEKHR_GEOMETRY_CYLINDERKHR_GEOMETRY_QUADKHR_GEOMETRY_SPHEREKHR_GEOMETRY_TRIANGLEKHR_INSTANCE_TRANSFORMKHR_INSTANCE_TRANSFORM_ARRAYKHR_LIGHT_DIRECTIONALKHR_LIGHT_HDRIKHR_LIGHT_POINTKHR_LIGHT_SPOTKHR_MATERIAL_MATTEKHR_MATERIAL_PHYSICALLY_BASEDKHR_RENDERER_AMBIENT_LIGHTKHR_RENDERER_BACKGROUND_COLORKHR_RENDERER_BACKGROUND_IMAGEKHR_SAMPLER_IMAGE1DKHR_SAMPLER_IMAGE2DKHR_SAMPLER_IMAGE3DKHR_SAMPLER_PRIMITIVEKHR_SAMPLER_TRANSFORMKHR_SPATIAL_FIELD_NANOVDBKHR_SPATIAL_FIELD_STRUCTURED_REGULARKHR_VOLUME_TRANSFER_FUNCTION1DEXT_SAMPLER_COMPRESSED_IMAGE2DEXT_SAMPLER_COMPRESSED_FORMAT_BC123EXT_SAMPLER_COMPRESSED_FORMAT_BC45NV_ARRAY_CUDANV_FRAME_BUFFERS_CUDAVISRTX_TRIANGLE_BACK_FACE_CULLINGVISRTX_SPATIAL_FIELD_DATA_CENTERINGVISRTX_SPATIAL_FIELD_REGION_OF_INTERESTVISRTX_SPATIAL_FIELD_STRUCTURED_RECTILINEARVISRTX_SPATIAL_FIELD_NANOVDB_RECTILINEAR
For any found bugs in extensions that are implemented, please open an issue!