OpenMoonRay: A Complete Guide to DreamWorks’ Production-Proven Renderer Now Under the Academy Software Foundation

DreamWorks’ OpenMoonRay renderer joins the Academy Software Foundation. Learn how to use this production-proven, open-source path tracer in your VFX pipeline.

The Missing Piece in Your Open‑Source VFX Pipeline

You have built a solid open‑source pipeline: OpenUSD for scene description, OpenVDB for volumes, OpenColorIO for color management. 

But when it comes to rendering, you still rely on proprietary solutions or hobbyist engines that cannot handle feature‑film complexity. The gap between “works on my machine” and “survives a 100,000‑core render farm” feels unbridgeable.

What if you could stand on the shoulders of a renderer that has already delivered dozens of blockbuster movies – and now lives entirely in the open?
That is exactly what DreamWorks Animation and the Academy Software Foundation (ASWF) have made possible with OpenMoonRay.

What You Will Learn

• The origin, architecture, and key capabilities of the MoonRay renderer.

• Why DreamWorks open‑sourced it and what its move to the ASWF means for long‑term sustainability.

• Practical steps to build, run, and integrate OpenMoonRay into your own projects.

• Common mistakes developers make when adopting a high‑end renderer – and how to avoid them.

What Is MoonRay? (And Why Should You Care?)

MoonRay is a production‑quality, Monte Carlo ray tracer developed inside DreamWorks Animation over more than a decade. Before its open‑source release, it powered every frame of films such as:

How to Train Your Dragon: The Hidden World

• The Bad Guys

• Puss in Boots: The Last Wish

• Kung Fu Panda 4

• The Wild Robot

• The Bad Guys 2

Unlike research renderers or academic prototypes, MoonRay was built to survive brutal production realities: thousands of shots, terabytes of geometry, complex lighting, and strict deadlines. 

When DreamWorks announced plans to open‑source the renderer, the industry paid attention – and when the code finally landed as OpenMoonRay, it became one of the most significant open‑source graphics releases in years.

The Renderer That Keeps Improving

Since its initial open‑source publication, OpenMoonRay has not been abandoned. The development team continues to add features, improve performance, and fix bugs. 

By contributing the project to the ASWF, DreamWorks ensures that governance, intellectual property, and future development follow a transparent, community‑driven model – just like OpenEXR and OpenVDB.

Key Architectural Pillars

  1. Path tracing with full spectral rendering – MoonRay uses a physically based, unbiased path tracer. It supports spectral rendering (wavelength‑based light transport), which delivers more accurate colors and material response than RGB‑only engines.

  2. The Arras distributed framework – Rendering a single frame of a modern animated film can require billions of ray samples. Arras is MoonRay’s proprietary distributed execution system, designed to scale from a laptop to tens of thousands of cores with minimal overhead. 

In the open‑source version, you get the same framework – meaning you can experiment with distributed rendering across your own cluster or cloud instances.

 3. Production material and light libraries – OpenMoonRay includes the same shading and lighting models used in DreamWorks films, from subsurface scattering and hair/fur to area lights and environment maps.

 4. USD integration – The renderer natively understands Universal Scene Description (USD), the open‑source scene description format pioneered by Pixar and now an ASWF project. You can feed it a USD stage and start rendering with minimal translation.

Why OpenMoonRay Matters for Developers

Democratizing High‑End Rendering

Before OpenMoonRay, if you wanted a renderer capable of handling a full‑length animated feature, your options were either expensive commercial products (RenderMan, Arnold, V-Ray) or closed, in‑house systems. 

OpenMoonRay removes the financial and legal barriers. You can download, modify, and even redistribute your changes – as long as you comply with the Apache 2.0 license.

Interoperability with the ASWF Ecosystem

The Academy Software Foundation exists to host and sustain open‑source projects that are critical to motion picture production. By joining ASWF, OpenMoonRay sits alongside:

• OpenVDB – for volumetric effects (fire, clouds, smoke)

• OpenColorIO – for color management

• OpenEXR – for high‑dynamic‑range image storage

• Open Shading Language (OSL) – for programmable shading

• OpenUSD – for scene description

This means you can build a completely open VFX pipeline from asset creation to final render without leaving the ASWF ecosystem. OpenMoonRay reads OSL shaders, consumes OpenVDB volumes, respects OpenColorIO transforms, and writes OpenEXR frames – all natively.

Getting Started with OpenMoonRay

The renderer is designed for Linux (mainly Rocky Linux 8/9, though other distributions work with minor adjustments). Windows and macOS are not officially supported, but you can use WSL2 or containers.

Prerequisites

• CMake (3.20+)

• C++17 compiler (GCC 9+ or Clang 12+)

• CUDA (optional, for GPU acceleration – though MoonRay is primarily CPU‑based, some components use CUDA)

• Dependencies: TBB, OpenEXR, OpenVDB, OSL, Intel Embree, OpenImageIO, and others. Most can be installed via package managers or built from source.

Building from Source

1. Clone the repository

1. bash

   git clone https://github.com/DreamWorksAnimation/openmoonray.git
   cd openmoonray

 2. Run the dependency script (the project provides a install_deps.sh for Rocky Linux – adapt to your distro).

3. Configure with CMake

1. bash

   mkdir build && cd build
   cmake .. -DCMAKE_INSTALL_PREFIX=/opt/openmoonray

4. Build and install

1. bash

   make -j $(nproc)
   make install
   
   

Practical Example: Rendering a Simple USD Scene

Assume you have a USD file, sphere.usda, containing a sphere, a camera, and a distant light.

bash

moonray scene.usda -out image.exr -res 1920 1080 -samples 64

This launches the MoonRay executable, parses the USD stage, and renders a 1920x1080 image with 64 samples per pixel. The output is an OpenEXR file.

For distributed rendering (multiple machines or processes):

bash

arras_render --scene scene.usda --hosts node1,node2,node3 --out final.exr

Here, arras_render is the Arras launcher that farms out buckets to the listed hosts. The same system was used to render The Bad Guys across DreamWorks’ render farm.

Integrating as a Library

You are not forced to use the command‑line tools. OpenMoonRay exposes C++ APIs for:

• Loading USD stages and converting them to internal scene representations.

• Driving the ray tracer programmatically frame by frame.

• Implementing custom light or material plugins.

This makes it feasible to embed MoonRay into a DCC tool (like Maya or Blender) or to use it as a backend for a real‑time preview renderer.

Anúncio  C++ - Curso Completo (PT-BR)  https://amzn.to/4uuPVgE

Adversiting :C++ Primer (ENG)  https://amzn.to/42VkjEL

I earn a comission with you make a purchase. 

Common Mistakes to Avoid (And How to Fix Them)

1. Underestimating Hardware Requirements

MoonRay is a production renderer – it expects many cores and ample RAM. Trying to render a feature‑film shot on a laptop with 8 GB of memory will lead to swapping or crashes.

Solution: Start with simple scenes (one object, one light). Use the -samples flag to lower sample counts during development. For serious work, provision cloud instances or a dedicated workstation with 32+ cores and 64+ GB RAM.

2. Ignoring the USD Ecosystem

New users often attempt to feed MoonRay with custom scene formats (OBJ, FBX, Alembic) directly. While the renderer can read some of those via OpenImageIO, its true strength is USD. If you do not have a USD pipeline, you will fight the tool.

Solution: Invest time in learning OpenUSD. Convert your assets to USD using usdconvert or usdcat. Treat MoonRay as a USD renderer, not a general‑purpose converter.

3. Skipping the Arras Documentation

Arras is powerful but has its own concepts: “worker pools”, “buckets”, “dispatcher”, and “results collector”. Running a single‑machine render works fine, but distributed rendering fails if you ignore process management.

Solution: Read the docs/arras.md in the repository. Start by running two processes on one machine (--hosts localhost,localhost), then scale to networked nodes. Verify that all hosts have the same library versions and shared storage.

4. Assuming GPU Acceleration “Just Works”

Unlike OptiX or CUDA‑only renderers, MoonRay is primarily CPU‑based. Some components (e.g., denoising) use CUDA, but the core path tracer does not. Expecting real‑time GPU performance will lead to disappointment.

Solution: Design your workflow for offline, batch rendering. Use lower‑quality preview passes for iteration, and only the final frame at full sample counts. If you need a GPU renderer for real‑time work, consider looking at other projects – MoonRay is about uncompromising quality, not speed.

FAQ

Q: Is OpenMoonRay free for commercial use?

Yes. It is licensed under Apache 2.0, which allows commercial use, modification, and redistribution without royalties. You must include the original copyright notice and disclaimer.

Q: How does OpenMoonRay compare to Blender’s Cycles?

Both are unbiased path tracers, but MoonRay was built for massive distributed rendering (Arras) and integrates deeply with USD and the DreamWorks material model. Cycles is more user‑friendly for individuals and has better GPU support. MoonRay shines in studio pipelines that already use ASWF components.

Q: Do I need to sign a contributor agreement to submit bug fixes?

Once the project is fully under ASWF governance, contributions will follow the standard ASWF Developer Certificate of Origin (DCO). As of now, check the repository’s CONTRIBUTING.md – but the move to ASWF simplifies legal paperwork.

Q: Can I use OpenMoonRay for real‑time rendering or games?

Not realistically. MoonRay is designed for offline, high‑quality rendering where a single frame may take minutes or hours. For real‑time applications, look at real‑time engines (Unreal, Unity, Godot) or real‑time ray tracing APIs (Vulkan RT, DXR).

The Future: OpenMoonRay Under ASWF Governance

Moving a project into the Academy Software Foundation is not a symbolic gesture. It comes with:

A neutral legal home – Patents, trademarks, and copyrights are managed by the foundation, not a single company.

Continuous integration and release infrastructure – ASWF provides CI resources and release engineering.

A formal technical steering committee – Decisions about features and roadmaps involve multiple stakeholders, not just DreamWorks.

Long‑term sustainability – Even if DreamWorks’ priorities change, the project can continue through community and other member companies.

For developers, this means you can rely on OpenMoonRay as a stable, well‑governed foundation for your own tools. You are no longer dependent on a single vendor’s goodwill.

In the coming months, expect more documentation, sample scenes, and possibly GPU ray‑tracing contributions from the community. The codebase is mature, but its open‑source journey is just beginning.

Conclusion

You now have a clear map of OpenMoonRay – what it is, why it matters, how to build it, and what to watch out for. The most valuable next step is also the simplest:

Clone the repository and render your first USD scene today.

Even if all you do is render a single sphere with a few lights, you will have crossed the threshold from “hearing about” to “using” a production renderer. From there, you can:

• Experiment with the Arras distributed framework on a small cluster.

• Contribute a bug fix or a missing feature.

• Integrate MoonRay into your studio’s existing ASWF pipeline.

And if you need to brush up on USD, start with our [Beginner’s Guide to OpenUSD for Render Engineers] – because MoonRay and USD are now inseparable companions.