MoonRay Renderer: DreamWorks' Path to Open-Source Production Rendering

In 2023, DreamWorks Animation did something unusual: they open-sourced MoonRay, the renderer that had powered films like "How to Train Your Dragon 3," "The Boss Baby," and "Puss in Boots: The Last Wish." For a studio that built its competitive advantage partly on proprietary technology, releasing a production-grade renderer to the world signaled confidence—and a philosophical shift in how film studios approach rendering technology.

MoonRay represents DreamWorks' bet on the future of rendering: path-traced, XPU hybrid (CPU and GPU), USD-native, and open. It's not positioned to replace Arnold or RenderMan in every studio, but for teams building custom rendering pipelines or needing an alternative to commercial renderers, MoonRay offers something rare: a production-proven, actively maintained open-source path.

The History and Why DreamWorks Opened It

MoonRay's origins trace to DreamWorks' internal rendering technology stack. Like other major studios, DreamWorks maintained a proprietary renderer optimized for their specific workflow. However, as the studio expanded and faced the complexity of maintaining proprietary tools, they recognized that open-source alternatives could actually benefit them.

By releasing MoonRay, DreamWorks accomplished several strategic goals. First, they could pool development resources with a broader community. Second, they retained credibility and technical relevance in a landscape where studios increasingly collaborate. Third, for independent filmmakers and smaller studios, providing a proven renderer removes a significant barrier to production-quality output.

The timing was significant. By 2023, Pixar's RenderMan (partially open-sourced years earlier) and open-source tools like OpenImageIO and MaterialX were already establishing a culture of open tooling in VFX. MoonRay joined this ecosystem as a mature, battle-tested renderer.

Technical Architecture

MoonRay is a path tracer at heart. It samples rays from the camera into the scene, bounces them off surfaces, and accumulates light energy to build photorealistic images. This approach is the industry standard for offline rendering—Arnold, RenderMan, and V-Ray all use path tracing as their core algorithm.

What distinguishes MoonRay is its XPU hybrid architecture. The X stands for "extensible"—XPU rendering means computation can seamlessly use both CPUs and GPUs, dynamically distributing work to whichever resource is most efficient. In 2026, GPU rendering is nearly standard, but XPU is relatively rare outside research contexts. MoonRay's implementation allows studios to render on mixed-resource farms: CPU nodes when necessary, GPU when efficient.

This matters practically. A farm might have some older CPU-only machines and newer GPU nodes. A GPU-centric renderer (like Octane or Redshift) can't efficiently use CPU-only hardware. A pure CPU renderer underutilizes GPU capacity. MoonRay theoretically balances both.

Path Tracing and Light Transport

MoonRay's path tracer is physically accurate. It computes light transport correctly: subsurface scattering, caustics, global illumination, and complex material interactions behave realistically. This is essential for photorealistic animation.

For efficiency, MoonRay implements adaptive sampling and denoising, critical for production rendering. You don't want to render 1,000 samples per pixel (slow); MoonRay's adaptive approach renders fewer samples where they're not needed and more where detail matters. A denoiser (often based on Intel's OpenImageDenoise) cleans up remaining noise. This workflow is now standard across modern renderers.

USD Integration

MoonRay was designed around USD (Universal Scene Description), Pixar's open standard for describing 3D scenes. This is crucial because USD is becoming the interchange format across VFX pipelines. Scenes described in USD can move between tools without compatibility shims.

Many commercial renderers now support USD, but MoonRay's integration is native. Scene description, materials, geometry, lights—all USD. If your pipeline is USD-centric, MoonRay feels natural. If you're still using proprietary file formats, USD adoption adds a step.

Material System

MoonRay uses MaterialX for material definition. MaterialX is Lucasfilm's open standard for describing physically-based materials. Instead of renderer-specific shader networks (like RenderMan's RIS or Arnold's standard surface), MaterialX materials are portable: build once, use in any renderer that supports MaterialX.

For studios handling complex materials or moving assets between rendering tools, MaterialX is a meaningful improvement. You're not locked into Arnold's standard surface or RenderMan's patterns.

Comparing to Industry Standards

Against Arnold: Arnold dominates VFX and animation pipelines. Arnold is mature, ubiquitous on render farms, and has proven itself across thousands of productions. MoonRay is newer and less battle-tested in commercial pipelines. However, MoonRay's open-source nature and USD-native architecture offer flexibility Arnold (proprietary, closed) cannot. For teams already deep in Arnold, switching is costly. For new pipelines or research, MoonRay is viable.

Against RenderMan: RenderMan is also industry-standard and increasingly open (parts of it open-sourced). RenderMan is perhaps the most sophisticated renderer available, with advanced features like path-traced displacement and deep rendering capabilities. MoonRay matches RenderMan's core quality but is somewhat less feature-rich. RenderMan's integration with Houdini is tight. MoonRay's integration is improving but less mature.

Against V-Ray: V-Ray is GPU-focused, rendering speed-optimized. MoonRay aims for quality and flexibility. They're not direct competitors—different design philosophies. V-Ray is faster; MoonRay is more extensible.

Against Octane/Redshift: Both GPU renderers, rapid iteration. MoonRay is offline/batch-rendering focused. Octane and Redshift prioritize viewport preview and real-time feedback. If you need to see materials and lighting in real-time, Octane/Redshift win. If you need production-grade ray-traced rendering with extensive customization, MoonRay wins.

In summary: MoonRay is comparable to Arnold and RenderMan in capability, exceeds them in openness and extensibility, but lacks their ecosystem maturity and farm integration depth.

Getting Started with MoonRay

Installing and learning MoonRay requires technical sophistication. Unlike commercial renderers with installers and GUIs, MoonRay requires:

1. Building from source (GitHub repository)
2. Compiling with dependencies (boost, tbb, openEXR, materialX, etc.)
3. Integrating with your 3D application (Houdini, Maya, or custom scripts)

This isn't a dealbreaker, but it's a barrier for non-technical artists. Studios with dedicated software engineers can absolutely handle it. Freelancers expecting plug-and-play workflows will be frustrated.

DreamWorks has worked to lower the barrier—official builds and Docker containers exist—but it remains more technical than "Install Arnold, click render."

For Houdini users, MoonRay integration is most developed. Houdini has official MoonRay support, and the USD pipeline is native, making the experience smooth. For Maya, integration exists but is less mature. For other applications, custom setup is required.

Rendering a First Scene

Once set up, workflow is straightforward:

1. Describe your scene in USD
2. Configure rendering parameters (samples, denoising, output format)
3. Run the renderer
4. Monitor progress, save EXR output

MoonRay outputs standard OpenEXR files with deep/beauty pass support, making compositing integration standard.

Performance and Render Times

MoonRay's performance is competitive. On CPU-only hardware, it's somewhat slower than optimized CPU renderers like RenderMan. On GPU, it's comparable to Octane/Redshift at quality settings (not real-time preview speed, but final render speed).

XPU hybrid rendering's real advantage emerges at scale. A farm with 1,000 mixed-CPU/GPU nodes can theoretically distribute work efficiently. Pure GPU renderers can't. In practice, few farms exploit this advantage yet—GPU rendering is dominant, so CPU capacity sits idle anyway. As farms age and become more heterogeneous, MoonRay's flexibility becomes valuable.

Denoising is critical for performance. With Intel's OIDN denoiser, you can reduce sample counts significantly without visible noise. This is standard practice now; denoising isn't "cheating," it's smart rendering.

Limitations and Caveats

MoonRay is not without drawbacks:

Ecosystem Immaturity: Arnold, RenderMan, and V-Ray have years of ecosystem development: plugins, integrations, optimized workflows. MoonRay is just beginning. If your studio relies on specialized Arnold plugins or RenderMan's deep integration with proprietary tools, MoonRay isn't ready as a replacement.

Technical Barrier: Installation and integration require software engineering expertise. Non-technical studios will struggle.

Farmware Support: Render farms support Arnold, RenderMan, V-Ray extensively. MoonRay support is emerging but not ubiquitous. We support MoonRay at Super Renders Farm, but check your farm's documentation.

Documentation: While improving, MoonRay documentation is less comprehensive than commercial tools. Learning requires digging into code and examples.

Adoption Risk: If you adopt MoonRay as your primary renderer, you're betting on continued open-source development. If DreamWorks or the community loses interest, you're unsupported. This is less risk than proprietary tools (a company going bankrupt), but it's real.

When MoonRay Makes Sense

MoonRay is right for:

• Studios building custom rendering pipelines and willing to invest engineering resources
• Teams already USD-centric and wanting a native USD renderer
• Researchers exploring rendering algorithms
• Independent filmmakers seeking production-grade open-source rendering
• Studios wanting renderer flexibility and not locked into one vendor's ecosystem

MoonRay is not right for:

• Studios expecting plug-and-play simplicity
• Teams wanting zero-friction farm integration
• Projects on tight deadlines with minimal technical support capacity
• Studios heavily invested in proprietary rendering ecosystems

Integration with Super Renders Farm

We support MoonRay rendering on our cloud infrastructure. For teams evaluating MoonRay, render farm compatibility is critical. We can handle MoonRay jobs with:

• USD scene description
• MaterialX material definitions
• Denoising enabled for efficiency
• EXR output with deep passes

If you're considering MoonRay, we can help stress-test your pipeline on cloud infrastructure without committing to local hardware buildout.

The Broader Context: Open Rendering

MoonRay is part of a larger shift toward open-source rendering. Pixar's RenderMan is partially open. Pixar's MaterialX is open. NVIDIA's OptiX (used by Octane) is increasingly open. OpenImageIO, TinyEXR, and numerous rendering components are open-source.

This shift benefits everyone: studios get flexibility, researchers can innovate, and the entire industry raises the baseline quality. Twenty years ago, proprietary rendering was standard. In 2026, open components are normal.

MoonRay exemplifies this trend. DreamWorks didn't release MoonRay because they wanted to give away competitive advantage—they released it because open tools, collectively developed, benefit everyone, including themselves.

FAQ

Q: Should we migrate from Arnold to MoonRay? A: Not immediately, unless you have strong technical capacity and need the flexibility. Arnold is proven, battle-tested, and ubiquitous. MoonRay is emerging. If Arnold works for your pipeline, stay. If you're building a new pipeline and want vendor independence, MoonRay is worth evaluating.

Q: Can I render MoonRay scenes on most render farms? A: Not yet. Most farms support Arnold, RenderMan, V-Ray, Octane. MoonRay support is growing but not universal. Check your farm's documentation. We support it at Super Renders Farm, but it's not standard everywhere. This will improve as adoption grows.

Q: Is MoonRay slower than Arnold? A: Roughly comparable. MoonRay might be slightly slower on CPU, slightly faster on GPU, depending on configuration. Denoising makes the difference negligible. Speed is not a reason to choose or avoid MoonRay.

Q: Do I need to learn USD to use MoonRay? A: Effectively, yes. MoonRay can read other formats (via import), but native USD is where it shines. If your pipeline is already USD, adoption is easy. If not, you're learning USD alongside MoonRay, which doubles complexity.

Q: Is MoonRay suitable for production animation? A: Yes, it's been used in DreamWorks productions. It's production-proven. However, ecosystem support (farm integration, plugins, community help) is less mature than Arnold or RenderMan. For ambitious projects, budget integration and testing time.

Q: What's the difference between MoonRay and Pixar's RenderMan? A: Both are path-tracers, both support USD and MaterialX. RenderMan is more feature-rich (advanced displacement, deep rendering), more mature, and better integrated with Houdini. MoonRay is simpler, more open, and offers XPU hybrid rendering. RenderMan has 30 years of refinement; MoonRay is just starting. For straightforward path tracing, both work. For cutting-edge rendering features, RenderMan leads.

Q: Can I use MoonRay with Blender or other non-Houdini tools? A: Not natively. Houdini integration is primary. For Blender, you can export USD and render, but there's no Blender plugin. For Maya, community efforts exist but are not official. If your pipeline is Houdini-centric, MoonRay is straightforward. If you use other tools, integration work is required.

Related Resources

For broader rendering strategy and farm optimization, see our GPU Cloud Render Farm guide, which covers multiple renderers including MoonRay. We also offer detailed Arnold Cloud Rendering and V-Ray farm integration documentation if you're comparing options.

For USD-centric pipelines, our Blender Cloud Rendering guide discusses USD adoption in Blender, relevant if your pipeline spans multiple applications.

Conclusion

MoonRay represents DreamWorks' confidence in open-source rendering and their commitment to industry standards like USD and MaterialX. It's not a replacement for Arnold or RenderMan in established studios, but for new pipelines, ambitious studios, and research contexts, it's a compelling option.

The renderer is capable, proven in production, and genuinely open. Its limitations are primarily ecosystem-related: fewer integrations, less farm support, steeper installation curve. These are temporary challenges; as adoption grows, they'll diminish.

In 2026, MoonRay isn't yet the default for animation rendering. But it's mature enough that serious consideration is warranted. Studios that have invested in USD workflows and have technical depth can adopt it successfully. For others, it's worth monitoring as it matures.

DreamWorks' decision to open-source MoonRay reflects broader industry confidence that sharing rendering technology elevates everyone's output. That's the future of VFX tools: open, collaborative, and increasingly standardized around formats like USD and MaterialX.