Aurora: a real-time GPU path tracer built for the viewport, not the final frame

Aurora is built for iteration speed, not for finished frames

The first thing to understand about Aurora is what it is not. The README draws the line explicitly: Aurora is a real-time path tracing renderer that leverages GPU hardware ray tracing, and as a real-time renderer it is intended to support rapid design iteration in a real-time viewport, which differs from a final frame production renderer like Autodesk Arnold. Everything else follows from that positioning. Path tracing brings the global effects that a rasteriser cannot fake cheaply, including soft shadows, reflections, refractions and bounced light, and the interactive performance claim rests on hardware ray tracing in modern GPUs rather than on approximating those effects. The feature list also names what is still missing, with denoising through NVIDIA Real-Time Denoisers, support for alternative material models, and discrete light sources described as planned. If you are coming from a production renderer, read that list first. The scope is a viewport tool with a path tracing core, not the other way around.

HdAurora and Plasma are the two doors into the renderer

Aurora can be exercised in three ways, and the README lists them plainly. The first is the Plasma sample application, usable interactively or from the command line, which is a standalone application documented separately. The second is the HdAurora render delegate, a USD Hydra delegate that lets Aurora be driven from a USD Hydra based scene delegate such as Usdview or certain design applications. The third is the unit test suite, which uses Google Test and is split into Foundation, AuroraInternals and Aurora test directories. All three are built together with Aurora, and binaries land in the build output directory. The distinction between the delegate and the sample matters for adoption. If your pipeline already speaks OpenUSD Hydra, HdAurora lets you slot the renderer into an existing viewer rather than building an application around it. If it does not, Plasma is the only route in, and Plasma is a sample, meaning it is the least stable of the three surfaces to build on.

The Linux build fetches externals before CMake runs

The quick start is a build exercise, and the order of the steps matters. On Linux, which the README describes for Ubuntu 24.04, the prerequisites are GCC/G++ or Clang, CMake 3.29.3+, Python 3.11+, and the system libraries listed in the build documentation. The commands below install the external dependencies into an Externals directory, configure the project, compile it, and then run the sample against a scene.

python3 Scripts/installExternals.py Externals/linux/Release
cmake -S . -B Build
cmake --build Build
cd Build/bin/Release
./Plasma --output {OUTPUT_IMAGE_FILE.png} --scene {INPUT_SCENE_FILE.obj}

The first line is the part that trips people up. Aurora does not vendor its dependencies in the tree, it pulls them into a separate location and points CMake at them, and the same pattern appears on Windows and macOS with different paths and an extra build-target option on macOS. On Windows the equivalent sequence uses Visual Studio 2022 with a Visual Studio 17 2022 generator and an x64 architecture flag, and the macOS instructions use the Xcode generator. The repository layout matches this design: a Scripts directory holds the externals installer, a Libraries directory holds the code, Applications holds the sample applications, Tests holds the Google Test suites, and Doc holds the per topic documentation referenced from the README.

Hardware ray tracing is the floor, and compute based fallback is much slower

Aurora requires a GPU with hardware ray tracing support, either through DirectX Raytracing on Windows or through Hgi Ray Tracing on Windows, macOS and Linux. The README enumerates what qualifies. Native support covers NVIDIA GPUs with RTX in the brand name, including mobile parts, the Quadro RTX series, and the RTX A series, AMD GPUs on RDNA 2 including the RX 6000 and RX 7000 series and Radeon PRO parts, Intel GPUs with Xe architecture and DX12 support including the Intel Arc Pro A-series for workstations, and Apple silicon M1 and above. There is a second tier for NVIDIA GPUs with compute-based support, meaning Pascal architecture parts with at least 6 GB of RAM such as the GeForce 10 series or Quadro P series, and the README is blunt about the cost: these will perform substantially slower with GPU ray tracing due to the lack of native ray tracing support. Recent GPU drivers from NVIDIA, AMD or Intel are recommended, since ray tracing API support is being improved, and the driver version is arguably a more important variable than the GPU model itself.

Vulkan is validated mostly on NVIDIA, so AMD and Intel paths are thinner

One of the more candid notes in the README concerns the graphics API. Vulkan is primarily validated on NVIDIA GPUs, and software Vulkan paths such as lavapipe can still be useful for Linux build and smoke-test coverage, but they are much slower than GPU-backed runs. That sentence tells you two things about the project. Continuous integration on software Vulkan is how the build stays covered on machines without a discrete GPU, and the resulting test signal is weaker than a run on real hardware. It also means that if you are on AMD or Intel hardware, the path exercised most often by maintainers is not the path you will run. The officially supported operating systems are Windows 11, macOS 15.5 and Ubuntu 24.04, and while the README allows that Windows 10, other macOS versions and other Linux distributions may work, it does not guarantee them. This is a young project with a young compatibility matrix, and the difference between supported and merely plausible matters when you are deciding whether to depend on it.

Materials come from MaterialX, and geometry is triangles with instancing

The shading side is narrower than in a general renderer, and it is built on external standards rather than proprietary ones. The README lists Autodesk Standard Surface materials defined with MaterialX documents, which can represent a wide variety of real-world materials with physically based shading, and it adds that independent layers of materials are supported, usable to implement decals. Environment lighting uses a wrap-around lat-long image, which is a simple and predictable way to light a scene. Geometry is triangle based with object instancing, so heavy repetition is handled by instancing rather than by unique mesh data. Against that, the material model is a single well specified one rather than a set of interchangeable models, and there are no discrete light sources yet, so a scene lit only by geometry and an environment map is the shape of what renders well today. Denoising is in the same category, planned rather than present, which means noisy regions stay noisy in the viewport.

Aurora against a final frame renderer and against the Hydra delegates you already use

The alternative is not really a competing project so much as a different choice of renderer for the same job. Against a production renderer such as Autodesk Arnold, which the README names as the final frame counterpoint, the difference in approach is the goal: a final frame renderer spends unbounded time on one image, so it can afford offline sampling, light transports, and denoising, while Aurora spends its budget on the frame you are looking at right now. The viewport is the product. The second alternative is architectural rather than competitive. If you already run a USD Hydra scene delegate, HdAurora is one more delegate you can register, competing with whatever delegate is currently producing your frames, and the comparison then comes down to interactive path traced fidelity against whatever your current delegate does. Neither comparison is settled by the README, and that is the honest position: the project documents what it does, what it plans, and what its hardware floor is, and leaves the judgement to the pipeline it enters.

Apache-2.0 licensing and a release line that trails the source tree

Everything in the repository is fully open source under the Apache license, and the README welcomes feature requests and code contributions. The Apache-2.0 terms are permissive, with the usual requirement that notices accompany redistributed copies, and for a renderer intended to sit inside a larger toolchain that is usually the licence you want. Two practical caveats sit next to the licence. First, the software and the documentation are described as a work in progress under active development, so interfaces can still move. Second, the release history and the source tree are not in step. The listed releases are v25.08-beta from 2025-08-08, v24.08 from 2024-07-31 and a v24.08 macOS beta from the same day, while the last push to the repository was on 2026-09-16. The repository is not archived, so the work has not stopped, but a released binary and the current main branch should not be assumed to be the same thing. If you pin a version for a production pipeline, pin the release you tested rather than tracking main, and expect the beta in that history to have changed more than the release before it.

Editorial conclusion

Adopt Aurora when you need physically based path traced feedback inside a design viewport and your hardware has native ray tracing, and skip it when you need a finished final frame or discrete light sources, since the README lists both as planned work rather than shipped features. Verify first that your GPU and driver pair appear in the supported list, that your platform matches the officially supported set of Windows 11, macOS 15.5 and Ubuntu 24.04, and that your toolchain meets the stated compiler, CMake and Python versions before starting the build.

Frequently asked questions

Official sources

1. Autodesk/Aurora on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases