OpenMoonRay: DreamWorks' Production Path Tracer, Built from Submodules

What OpenMoonRay renders that a general-purpose renderer does not

MoonRay is a production path tracer, meaning it solves the rendering equation by tracing light paths rather than approximating them with rasterised shadow maps and screen-space effects. The README describes it as rendering images for animation, visual effects and other uses, and says it was open sourced by DreamWorks, where it is in active use for feature film animation. That provenance is the point: the material library is described as production-tested and physically based, so the shaders are the ones a studio shipped films with, not a research set. It runs on CPU and on hybrid GPU hardware, which the project calls XPU. It also ships a USD Hydra render delegate, so a host application that speaks Hydra can hand it a scene rather than requiring an export step. The audience is therefore narrow and specific: pipeline engineers at studios and vendors who already work in USD and want a path tracer they can modify, plus researchers who need a physically based reference. A hobbyist who wants a double-clickable application is not the target reader of this repository.

Why the top-level repository is mostly a shell

Cloning openmoonray does not give you the renderer. The README states plainly that this is the top-level repository and that the actual source code lives in a number of other repositories referenced as git submodules. The directory listing bears that out: alongside CMakeLists.txt, CMakePresets.json and the platform preset files, the tree contains moonray/, arras/, tsc/, rats, building/, scripts/, testdata/ and SDKScript, each of which is a submodule entry rather than inlined code. arras is the scene-graph and rendering framework layer, moonray the renderer itself, and rats is the regression testing tool the README links to. The practical consequence is that a plain clone gives you a build skeleton with empty directories, and every subsequent operation has to be submodule-aware. It also means version skew is a real hazard: the top-level commit pins particular submodule commits, and if you update one submodule by hand you are building a combination the project never tested. The CMake presets files (CMakeLinuxPresets.json, CMakeMacOSPresets.json, CMakeDWAPresets.json) are the supported entry points into the configuration, and CMakePresets.json ties them together.

Installing MoonRay on Linux or macOS from source

The README does not list dependencies or give a build command inline; it directs readers to the Building MoonRay page on docs.openmoonray.org for Linux, macOS and container builds. What the repository does give is the clone invocation, which must recurse into the submodules or you get an empty tree. Run this from the directory where you keep source checkouts.

git clone --recurse-submodules https://github.com/OpenMoonRay/openmoonray.git

After the clone finishes, the submodule directories should be populated rather than empty. If they are not, the recurse flag did not take effect and the build will fail at configuration time. From there, the configuration step goes through the checked-in CMake presets rather than a hand-written cmake invocation, which is why CMakePresets.json and the per-platform preset files sit at the top level. The exact preset names are not reproduced in the README, so read the Building MoonRay page and the preset files themselves before running a configure step. For a first real use, the repository points at two things worth doing before you attempt a full production scene: reading the source structure page, which the README calls a helpful start, and then reading the Developer's Guide. If your host application is Hydra-based, the USD Hydra render delegate is the integration path; if you are rendering from the command line, the local, multi-machine and cloud rendering modes described in the README are the relevant ones. The README does not document a rollback or uninstall procedure for a source build, so treat the install prefix as disposable.

Where OpenMoonRay will disappoint you

The biggest constraint is platform. The README names Linux and macOS, plus a container route, and the preset files follow that split with CMakeLinuxPresets.json and CMakeMacOSPresets.json. There is no Windows preset file in the top-level listing, and the README does not claim Windows support. Anyone arriving from a search for a Windows build will find nothing here to install. The second constraint is that this is a source build of a large multi-repository C++ project, and the README delegates all dependency and toolchain detail to an external documentation site. That means the repository alone is not sufficient to get running, and a documentation change can invalidate your build notes without any change in the repository. Third, the top-level repository is a thin wrapper, so an issue you hit may belong to a submodule rather than to openmoonray itself, and the README does not describe how that triage is supposed to work. Finally, hybrid GPU rendering is described as an option alongside CPU, not as a replacement, so hardware expectations should be set by the CPU path first.

How OpenMoonRay differs from Blender Cycles and Pixar RenderMan

Cycles, the path tracer inside Blender, is the obvious comparison for anyone who wants a free physically based renderer, and the difference is integration surface. Cycles is designed to be driven from Blender's own scene format and UI, with an application as the front door. MoonRay is designed to be driven from a USD scene through a Hydra render delegate, with a pipeline as the front door. If your assets are USD and your host speaks Hydra, MoonRay plugs in without a conversion step; if your assets live in Blender files, Cycles is the shorter path and MoonRay is the wrong tool. Pixar RenderMan is the closer comparison in intent, since both are studio path tracers with production material libraries, but the licensing and access models differ: MoonRay is released under Apache License 2.0, a free open source licence maintained by the Apache Software Foundation, and the source is public. That matters if you need to read or modify the renderer rather than only call it. The README does not make performance claims against either, and none should be inferred from the repository.

Licence, governance and the cost of keeping up

MoonRay is released under Apache License 2.0, and the repository carries the LICENSE file along with THIRD-PARTY.md, which is where the bundled and linked dependency licences are enumerated. Apache-2.0 is permissive and includes an explicit patent grant, which is generally what a studio wants when embedding a renderer in a pipeline, but the third-party file is the one to read before shipping, because a path tracer pulls in image codecs, math libraries and USD itself, and those carry their own terms. This is not legal advice; have counsel review THIRD-PARTY.md against your distribution model. On governance, the repository contains GOVERNANCE.md and CODE_OF_CONDUCT.md, and the README describes MoonRay as an active member project of the Academy Software Foundation, with contributions governed by CONTRIBUTING.md. Maintenance is current: the last push to the default branch was on 2026-09-12, and the most recent release listed is v2026.29.1 from 2026-07-17. The upgrade cost is the submodule graph. Release tags like v2026.29.1 and openmoonray-3.6.0.1 suggest a dated release cadence, and moving between them means moving the top-level commit and letting the submodules follow, not pulling individual components.

Editorial conclusion

Adopt OpenMoonRay if you already run a USD-based pipeline on Linux or macOS and can absorb a source build of a multi-repository CMake project; skip it if you need a packaged installer or a Windows build, because the README only points at Linux, macOS and a container. Before committing, verify that your USD version matches the one the Hydra delegate expects, that your CPU or hybrid GPU hardware is covered by the build presets in CMakeLinuxPresets.json and CMakeMacOSPresets.json, and that you can keep the submodules in step, since the top-level repository is only a shell around them.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. OpenMoonRay/openmoonray on GitHub
3. Project website
4. README
5. Releases