MoonRay’s First ASWF Release Adds MaterialX

MoonRay’s first ASWF release adds MaterialX map graphs, HdMoonRay integration and production-focused lighting, volume and stability work.
A thin, nearly complete dark gray circular ring on a black background, with a small opening at the right edge. The minimalist graphic feels like a loading or progress icon, centered with plenty of empty space around it.

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.

https://openmoonray.org/images/about_layerableminerals.png

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

https://openmoonray.org/images/about_pathtracing.png

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.

https://openmoonray.org/images/about_lightpath.png

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

ProductMoonRay, an open-source production path tracer. (ASWF)
Developer and governanceDeveloped at DreamWorks Animation and now hosted by the Academy Software Foundation, with continuing DreamWorks engineering support. (ASWF)
Release statusFirst public release under ASWF stewardship; current patch is 2026.29.1. (GitHub)
MaterialX implementationWork-in-progress Map shader execution with a separate shader repository; BSDF, EDF, VDF and SurfaceShader types are not included. (GitHub)
MaterialX build optionRequires -DBUILD_MATERIALX_SHADERS=ON during CMake configuration. (GitHub)
Host integrationHdMoonRay for Hydra hosts, with documented Houdini integration. (MoonRay Dokumentation)
Scene dataNative RDL2; OpenUSD through HdMoonRay, hd_render and hd_usd2rdl; OpenVDB volume input. (MoonRay Dokumentation)
Operating systemsSource builds for Linux and macOS; tested on Rocky Linux 9 and macOS Sonoma, with macOS 15.1 Sequoia also tested. (MoonRay Dokumentation)
HardwareMulticore CPU; NVIDIA CUDA/OptiX-capable GPU for XPU on Linux; Apple M-series hardware required by the documented macOS build. (MoonRay Dokumentation)
Processing backendsScalar CPU, SIMD wavefront vector CPU, hybrid XPU and Auto fallback modes. (MoonRay Dokumentation)
OutputsOpenEXR and deep EXR, OpenDCX, Cryptomatte, LPE, state and material AOVs. (MoonRay)
LicenceApache License 2.0, free and open source. (MoonRay Dokumentation)
DocumentationOfficial MoonRay documentation
DownloadOpenMoonRay source repository, coordinated through the top-level repository and Git submodules. (MoonRay)
Websiteopenmoonray.org