Why DreamWorks' releasing MoonRay under the Apache open source license is akin to Panavision giving away Millennium DXLs along with the blueprints.
Back in the 90s, when someone mentioned “RenderMan” most would think of a rendering engine from Pixar. In reality however, RenderMan wasn't actually a rendering engine at all, but rather an open standard for rendering engines; Pixar's version was called PhotoRealistic RenderMan (PRMan).
The heart of the RenderMan standard was a scene description language and a shader language. Being open, anyone developing a rendering engine could write a parser for both, and anyone developing a 3D animation system could implement an exporter for them.
Open source software is a very different beast. One of the most famous open source applications on the internet is Blender3D. Anyone can download the source code for Blender, including the well loved Cycles rendering engine. Some studios have even taken advantage of Blender's open source nature to customize it for their own in-house production pipelines.
Because of the license that Blender is released under, in spite of having huge amounts of funding from companies like Epic, Ubisoft, and Bethesda, the application is still completely open source. The pace of Blender improvements now rivals that of DaVinci Resolve, yet the source code remains freely available.
Pixar has developed a new standard for 3D animation systems to share data called USD: Universal Scene Description. Along with that are the Open Shading Language (OSL) and ILM's MaterialX specification. Part of the specification includes what is termed a USD Hydra Delegate, which is a much simpler idea than it sounds like; it's essentially a plug-in interface for a rendering engine.
SideFX Software got on board with USD early and has a mature, production ready implementation of it now in Solaris, which is a Houdini workspace designed for scene assembly, look development, lighting, and rendering. Since Solaris is based on USD, it can render to any Hydra Delegate. From the user's point of view, switching renderers requires no more effort than dropping down an appropriate node in the Solaris environment.
Houdini has two production rendering engines now. One is the older, CPU only Mantra which is well respected for image quality, features, and robustness. It does not however use GPU compute, so it falls well short of most of its contemporaries in the speed department thanks to the meteoric rise of GPU computing power in recent years. The second option now available is Karma, which is faster than Mantra but more importantly includes an XPU option which uses both the CPU and GPU compute. Karma is also a USD Hydra delegate with (beta) support for MaterialX shaders.
For SIGGRAPH 2022, a few of Intel's developers implemented a prototype USD Hydra delegate using Intel's open source Embree rendering system. Being a Hydra delegate, it sits in Solaris just like Karma does, allowing Intel an opportunity to tease us with the might of its next generation GPU.
Because USD is an open standard, a certain well known and well loved open source 3D animation system supports it also: Blender. AMD has implemented full USD Hydra delegate support as one of the features of ProRender for Blender.
Dreamworks is well known for its stylized animation, but the studio also does photorealistic visual effects for film, commercials, and TV. Rather than relying on a 3rd party production renderer, DreamWorks developed its own in house.
Called MoonRay, DreamWorks in house renderer is a state of the art distributed path tracer. It supports the usual laundry list of features like Cryptomatte, and deep output, a flexible and extensible suite of layerable shaders, light filters, volumetric rendering, and light filters.
While the rendering features by themselves don't set MoonRay apart from the likes of Arnold, V-Ray, Redshift, and even Cycles, there are a few areas where MoonRay is leading the pack.
First is its XPU mode. One of the challenges that render engine developers face is that CPUs and GPUs handle math slightly differently. While in a purely integer world there would be no differences, that's not the case in floating point; it's entirely possible to have two different processors execute exactly the same instructions and end up with different results. Because there are standards for floating point arithmetic defined by the IEEE, the nature of floating point arithmetic makes it nearly impossible for every compute architecture to deliver identical results. The differences are not large by any means, they're typically limited to the last few decimal points in each operand, but over the course of several iterations they can add up. If every node is the same, there's nothing to worry about, but if the GPU is running 200 iterations of a shader and the CPU is running the other 200, then the two sets of resulting pixels can look different enough to manifest as a rendering glitch.
Because of this, most of the GPU accelerated rendering systems on the market currently use either the CPU or the GPU, and rarely both. In most cases “both” means render on the CPU and then use the GPU for output filters like noise reduction, so that the issue of differences in rounding affect the entire image, and in a way that is consistent throughout an image sequence.
SideFX and Isotropix are working on XPU renderers that can use both the CPU and the GPU to render an image with pixel perfect accuracy, so that there will be no difference between pixels rendered on the GPU vs pixels rendered on the CPU.
DreamWorks is already there with MoonRay; its XPU mode is able to use the GPU as a supplemental compute node, instead of only as a stage in the rendering process.
This is actually a bigger deal than it sounds at first, because GPU rendering actually performs pretty poorly unless the entire scene and all of its textures is able to reside in the GPU's memory. Being able to efficiently load balance the rendering effort across the CPU and GPU is a big deal for performance, because it lets the renderer boost performance by using the GPU but without being limited by GPU memory.
MoonRay's other banner feature set is also performance oriented. It's vectorized from the bottom up, and has been from the start of development. MoonRay uses Intel's Embree for ray tracing, and DreamWork's own vectorized ray integrator and shading and texturing engines.
The other side of MoonRay's performance feature set is its cloud based distributed rendering framework called Arras. The Arras SDK is designed to simplify connecting to a renderfarm, and also to integrate MoonRay with a client application. The MoonRay demos show examples of artists interactively working in Houdini connected to a 32-node MoonRay cluster that uses the system GPU for denoising, and the result is a blazing fast interactive viewport render, a tremendous boon for look development.
Another feature of MoonRay is that it supports the Hydra Render Delegate standard, so out of the box artists with applications like Houdini and Katana will be able to use MoonRay as an interactive as well as production rendering engine.
Since DreamWorks is releasing MoonRay under the Apache open source license and the USD Hydra specification is open, expect to see MoonRay pretty much everywhere in the near future.
Choosing a render engine for an animation project is akin to choosing a camera for a film project, such as Eevee for realtime, interactive work which makes it great for look development and Cycles for final rendering to take advantage of the physically based ray traced output.
In that analogy, DreamWorks' releasing MoonRay under the Apache open source license is akin to Panavision giving away Millennium DXLs, along with the blueprints.
DreamWorks uses MoonRay in Linux, so the Windows and OSX ports are currently in limited beta. There are some application developers already working on integrating MoonRay into their software as well.
Since it's in beta testing, DreamWorks doesn't have a time table for releasing MoonRay to the public yet, but it's a good bet that it's going to become very popular very quickly when it launches and raises the bar for third party rendering engines.