Table of Contents Show
For those who don’t know the tool: MoonRay is the open-source production path tracer developed at DreamWorks Animation and now hosted by the Academy Software Foundation. It renders native RDL2 scenes, connects OpenUSD through the HdMoonRay Hydra delegate, reaches Houdini through Solaris and DCC plug-in setup, and uses Arras to separate, distribute and remotely host rendering processes. (ASWF)
MaterialX opens the ASWF era
This is the first MoonRay release under Academy Software Foundation stewardship. MoonRay became an ASWF-hosted project on 19 May 2026, and the public release history shows the previous code drop in April, followed by the new ASWF-era release in July. The Foundation now hosts the project’s maintenance and development, while DreamWorks Animation continues to provide support and dedicated engineering resources. The renderer has changed institutional homes, not rendering philosophies: it remains the production path tracer built at DreamWorks and used on the studio’s features since 2019.
The first headline under that new governance is support for MaterialX, itself an ASWF-hosted project. MaterialX defines an application-independent representation for material and look-development data, including shading networks, texture-processing graphs, assignments and extensible standard nodes. Bringing those graphs into MoonRay creates a route for more look-development logic to survive movement between DCCs, scene descriptions and renderers without requiring every studio to translate the same multiply node for the forty-seventh time.
Renderer support, not a new node editor
MoonRay’s implementation begins below the user-interface layer. The project has added infrastructure for the input and output types required by MaterialX and created a separate materialx_shaders repository containing MoonRay implementations of standard Map shaders. Source builders must enable them explicitly with -DBUILD_MATERIALX_SHADERS=ON in the CMake configuration. A successful MoonRay build without that option will therefore remain entirely successful and entirely free of the feature the pipeline expected.

This is a renderer capability, not an artist-facing change. MoonRay does not add a MaterialX authoring interface, document browser or node-layout tool. Artists interact with the graphs through the controls exposed by a host application or a studio integration. Pipeline developers must still register the shaders, translate the graph, provide files and parameters, and decide how unsupported nodes should fail. API-level support and a usable look-development interface are related, but they are not the same deliverable.
The current patch is the build production teams should evaluate because the first package omitted important HdMoonRay changes associated with the MaterialX work. The patch adds MaterialX Map shaders to the Hydra delegate and corrects attribute evaluation in ND_unifiednoise3d_float. That correction is small in line count but potentially large in a procedural network, where a wrongly evaluated attribute can propagate through every downstream operation with impeccable consistency.
HdMoonRay provides the delivery route

HdMoonRay translates Hydra scene data into MoonRay’s native RDL2 representation. It is a shared-library render delegate and does not provide a direct end-user interface. The host application decides how renderer settings, shader parameters and interactive controls appear. The distribution also includes hd_render for rendering USD scenes and hd_usd2rdl for converting USD data into RDL2.
The documented Houdini integration renders UsdPreviewSurface after the delegate has been configured. Access to MoonRay’s more advanced materials and maps requires the separate moonray_dcc_plugins repository and appropriate HOUDINI_PATH configuration. Once installed, MoonRay materials and maps appear in the Mat context, lights gain MoonRay-specific attributes, and render settings become available through a MoonRay tab. Geometry parameters such as mesh resolution can be authored through LOP wrangles.
The same documentation says that light filters and RenderVars are not yet available through that Houdini integration. That does not mean MoonRay lacks light filters or AOVs at renderer level. It means the documented host bridge does not yet expose those capabilities through that route. Compatibility with Hydra is likewise not certification for every Hydra-enabled DCC, host release or USD build. Each application supplies its own plug-in environment, UI and dependency stack, all of which retain their traditional right to disagree about shared libraries.
Lighting and stylisation gain controls
Outside MaterialX, the release adds texture support for DistantLights, toon-ramp control within the shadow zone and motion blur support for geometry implemented through RDL geometry DSOs. These are artist-visible rendering capabilities rather than infrastructure alone. Textured DistantLights give lighting teams another way to shape directional illumination, while the toon-ramp control extends the art direction available inside stylised shadow transitions. Procedural-geometry motion blur allows custom geometry implementations to participate more fully in temporal sampling.
Developer-facing tools also receive smaller additions. The --print_bsdf diagnostic output now includes each lobe’s label, making it easier to inspect the scattering components generated by a material. The rdla_gui, rdla_filter and rdla_wedge utilities receive general enhancements. These changes improve inspection and pipeline tooling, but they do not constitute a new shading algorithm or artist interface.

Scalar, vector and XPU remain different paths
MoonRay retains four execution modes: scalar, vector, XPU and Auto. Scalar mode processes one ray at a time across multiple CPU cores without batching work into SIMD lanes. Vector mode uses a wavefront path tracer that queues, sorts and batches rays and shading operations for cache coherence and SIMD processing. The vector renderer is designed to match scalar output, but it does not support physically correct overlapping dielectrics, variance buffers or deep output from volume rendering.
XPU is a hybrid implementation rather than a complete GPU port. On supported Linux systems, an NVIDIA CUDA and OptiX-capable GPU accelerates ray-scene intersection while the CPU continues to perform other rendering work. XPU inherits the vector renderer’s limitations and adds restrictions for round Bezier curves and geometry with more than two motion samples. It can fall back to CPU vector mode when GPU memory is insufficient or GPU initialisation fails.
Auto mode tries XPU, then vector, then scalar, falling back when the scene requires an unsupported feature. The documented priority is feature coverage over performance. That behaviour is useful for general-purpose deployment, but it also means a scene can take a different execution route from the one a supervisor expected. Farms should log the selected mode and fallback reason rather than assuming that an XPU request necessarily became an XPU render.
Existing outputs complete the production route
The release does not introduce a new image format, but MoonRay’s existing output stack remains relevant to the MaterialX and Hydra work. The renderer supports standard and deep OpenEXR, the coverage-mask-based OpenDCX extension, Cryptomatte, light path expression outputs, state AOVs and material AOVs. It also supports OpenVDB volumes, checkpoint and resume rendering, and display filters that can combine AOVs during interactive rendering.
As the first release under ASWF stewardship, this is a technically credible opening move. MaterialX enters at the map-processing layer, HdMoonRay carries it into Hydra workflows, and the renderer receives practical lighting, volume and stability fixes. The limits are equally clear: surface closures remain unfinished, host exposure varies, and published node coverage must be checked against each studio’s graphs. MoonRay has begun its ASWF phase with useful plumbing, which is exactly what open production software needs before anyone can enjoy the glamorous business of trusting it.
https://github.com/OpenMoonRay/openmoonray/releases/tag/v2026.29.0
https://github.com/OpenMoonRay/materialx_shaders
https://github.com/OpenMoonRay/openmoonray/releases/tag/v2026.29.0
Facts Box
| Product | MoonRay, an open-source production path tracer. (ASWF) |
| Developer and governance | Developed at DreamWorks Animation and now hosted by the Academy Software Foundation, with continuing DreamWorks engineering support. (ASWF) |
| Release status | First public release under ASWF stewardship; current patch is 2026.29.1. (GitHub) |
| MaterialX implementation | Work-in-progress Map shader execution with a separate shader repository; BSDF, EDF, VDF and SurfaceShader types are not included. (GitHub) |
| MaterialX build option | Requires -DBUILD_MATERIALX_SHADERS=ON during CMake configuration. (GitHub) |
| Host integration | HdMoonRay for Hydra hosts, with documented Houdini integration. (MoonRay Dokumentation) |
| Scene data | Native RDL2; OpenUSD through HdMoonRay, hd_render and hd_usd2rdl; OpenVDB volume input. (MoonRay Dokumentation) |
| Operating systems | Source builds for Linux and macOS; tested on Rocky Linux 9 and macOS Sonoma, with macOS 15.1 Sequoia also tested. (MoonRay Dokumentation) |
| Hardware | Multicore CPU; NVIDIA CUDA/OptiX-capable GPU for XPU on Linux; Apple M-series hardware required by the documented macOS build. (MoonRay Dokumentation) |
| Processing backends | Scalar CPU, SIMD wavefront vector CPU, hybrid XPU and Auto fallback modes. (MoonRay Dokumentation) |
| Outputs | OpenEXR and deep EXR, OpenDCX, Cryptomatte, LPE, state and material AOVs. (MoonRay) |
| Licence | Apache License 2.0, free and open source. (MoonRay Dokumentation) |
| Documentation | Official MoonRay documentation |
| Download | OpenMoonRay source repository, coordinated through the top-level repository and Git submodules. (MoonRay) |
| Website | openmoonray.org |