12 ms·

DreamWorks releases OpenMoonRay source code

765 points by dagmx 4y ago

ur-whale 4y ago
Man, I can't wait for this to be properly (luxrender-level) integrated to Blender. Especially the shaders (materials), which I feel is currently the weakest part of all the open source renders Blender supports natively (eevee, cycles, lux)
- boppo1 4y ago
  Can you elaborate on what's not good about eevee/cycles shaders? By proper integration do you imagine it will use Blender's node shader system or a different system? I'm not being combative, I'm in the process of learning enough of Blender's code to be able to contribute.
  - ur-whale 4y ago
    I could write a book about this, but to make it short, what most users of a 3D system like Blender want when they get to the shading/rendering part of their work is to simply: - pick an object in the scene - pick a pre-made rich and complicated shader (wood, glass, tar, etc...) from a huge library of shaders expressed in a standard form (as in: that will work with whichever render, be it cycles, luxrender, moonray, etc...) - drop it to the object without having to screw around for hours with texture scaling, rotation, uvs - rinse and repeat until all objects in the scene are shaded Very few people have the skills/knowledge and patience to put their own shaders together themselves by assembling basic nodes into a large and complicated shader tree. There has been some (feeble) attempts to build standard libraries of Shaders around Blender: https://github.com/LuxCoreRender/LoL https://github.com/LuxCoreRender/LoL https://www.youtube.com/watch?v=mCShkpW1c2w https://www.youtube.com/watch?v=mCShkpW1c2w These are: - hard to use - not always free - not standard and portable across renders In practice, assigning materials to a large scene in Blender is still a giant, time-consuming PITA.
    - _flux 4y ago
      I've used Blender only a little, but surely you're aware of the Asset Browser introduced in the 3.0? They seem easy enough to use, but of course they'd need to be high-quality to work similarly with all renderers. Granted I don't actually know where to find such libraries except for the small free asset bundles at https://www.blender.org/download/demo-files/#assets https://www.blender.org/download/demo-files/#assets or perhaps by paying Blender organization for them, so maybe this doesn't really address your core point :).
chungy 4y ago
The README is a bit opaque when I don't know the terminology, but the website seems to clue me in that it's a raytracer: https://openmoonray.org/ https://openmoonray.org/
- pcollinsmokonut 4y ago
  It is a path-tracer which is slightly more advanced than a ray-tracer.
- toxik 4y ago
  MCRT = Monte Carlo Ray Tracing
homarp 4y ago
previous discussion https://news.ycombinator.com/item?id=32357470 https://news.ycombinator.com/item?id=32357470
- app4soft 4y ago
  It was an announcement of upcoming source opening, but at the moment there was no public source repo.
ykl 4y ago
For anyone that is curious, this is the paper that describes the core vectorized path tracing architecture in Moonray: http://www.tabellion.org/et/paper17/MoonRay.pdf http://www.tabellion.org/et/paper17/MoonRay.pdf Extracting sufficient coherency from path tracing in order to be able to get good SIMD utilization is a surprisingly difficult problem that much research effort has been poured into, and Moonray has a really interesting solution!
- bhouston 4y ago
  Is there any comparisons to GPU-accelerated rendering? It seems most people are going that direction rather than trying to optimize for CPUs these days, especially via AVX instructions.
  - jsheard 4y ago
    CPUs are still king at the scale Dreamworks/Pixar/etc operate at, GPUs are faster up to a point but they hit a wall in extremely large and complex scenes. They just don't have enough VRAM, or the work is too divergent and batches too small to keep all the threads busy. In recent years the high-end renderers (including MoonRay) have started supporting GPU rendering alongside their traditional CPU modes, but the GPU mode is meant for smaller scale work like an artist iterating on a single asset, and then for larger tasks and final frame rendering it's still off to the CPU farm. Pixar did a presentation on bringing GPU rendering to Renderman, which goes over some of the challenges: https://www.youtube.com/watch?v=tiWr5aqDeck https://www.youtube.com/watch?v=tiWr5aqDeck
    - pixelpoet 4y ago
      What's your opinion on renderers such as Redshift which explicitly target production rendering and support out of core rendering on GPUs? See e.g. https://www.maxon.net/en/redshift/features?categories=631816 https://www.maxon.net/en/redshift/features?categories=631816 (Disclosure: I work on this.)
      - berkut 4y ago
bhouston 4y ago
Looks nice! It has a Hydra render delegate so that is nice. Does Blender support being a Hydra client yet? It would be nice to have it supported natively in Blender itself. If it did, one could easily switch renderers between this and others. I understand Autodesk is going this way with its tooling.
- capableweb 4y ago
  > It would be nice to have it supported natively in Blender itself. If it did, one could easily switch renderers between this and others. Blender in general is setup to work with different renderers, especially since the work of Eevee which is the latest renderer to be added. Some part of the work on integrating Eevee also put some groundwork for making it easier in the future to add more of them. Most probably this renderer would be added as a addon (if someone in the community does it), rather than in the core of Blender.
- semi-extrinsic 4y ago
  I had the same question. There exists a USD addon for Blender that support Hydra, so probably you could get that to work with a bit of trial and error! https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA...
- dagmx 4y ago
  AMD have an addon for Blender that supports Hydra, though it is a bit slow. There's ongoing work to add it to Blender itself natively https://projects.blender.org/BogdanNagirniak/blender/src/branch/hydra-render https://projects.blender.org/BogdanNagirniak/blender/src/bra...
dimator 4y ago
i'm curious: what is the incentive for dreamworks to open-source this? surely having exclusive access to a parallel renderer of this quality is a competitive advantage to other studios?
- ronsor 4y ago
  The other large studios that compete with them (e.g. Pixar) already have their own just-as-good renderers.
  - fuzzybear3965 4y ago
    Even still, what's the incentive to open-source? So the community can bootstrap a better solution than Pixar?
    - mdorazio 4y ago
      By showing they care about open source, there's a chance they'll attract developers and animators who care about that.
      - pipo234 4y ago
        Seems targeted at CentOS7, support for which is sunset in little over a year. Smells a bit like abandonware, hoping for adoption by unpaid volunteers. Still, dumping it into FOSS community is not the worst graveyard for commercial software...
        Vt71fcAqt7 4y ago
        They just released a feature film with this renderer, grossing $462 million and widely praised for its animation. Large studios don't update so regularly vs e.g. a startup. They have very specific setups, which is in fact a large part of why it took them so long to release moonray vs when they said they would last year. And they are moving to Rocky Linux soon IIRC. >dumping it into FOSS community They are not "dumping" anything. Would it have hurt to look into the facts before commenting?
antegamisou 4y ago
Wonder how it fares against the monopoly of Pixar’s Renderman.
- ralusek 4y ago
  I don't think there is a monopoly renderer.
  - jsheard 4y ago
    There isn't even a monopoly within Disney, they acquired Pixar 17 years ago but Disney Animation Studios still develop their own Hyperion renderer completely independently of Pixar/Renderman.
    - sosodev 4y ago
      Just because it's hard to migrate existing workflows or is there something that makes Hyperion superior?
      - jsheard 4y ago
        Hyperion has the advantage of being exclusive to WDAS, so they can tailor it to their exact workflow and requirements, while Renderman is a commercial product with many users outside of Pixar all with their own wants and needs.
      - Arelius 4y ago
        Hyperion was designed to specifically take advantage of a specific ray batching architecture that's particularly good for out of core renderers. Which can be good for particularly large and complex scenes.
app4soft 4y ago
Anybody has a success with build & run it under Linux? (Debian 11.x/Ubuntu 22.04.x)
- zokier 4y ago
  The docs are for centos but from the looks of it I don't see any major roadblocks for Debian based distros? https://docs.openmoonray.org/getting-started/installation/building-moonray/building-moonray-centos-7/ https://docs.openmoonray.org/getting-started/installation/bu...
- alhirzel 4y ago
  It appears they currently only support a Docker container build and a CentOS build. I am working on a build script (PKGBUILD) for Arch Linux.
- ur-whale 4y ago
  The docker-based build worked fine for me on Ubuntu 22.04. I haven't yet tried to pull the resulting binaries out of the docker container to see if it still works natively on 22.04.
- gonsolo 4y ago
  Yes: https://github.com/dreamworksanimation/openmoonray/issues/45 https://github.com/dreamworksanimation/openmoonray/issues/45 It's quite a hack, but it works. :)
pipeline_peak 4y ago
o boi, shrek engine
- isatty 4y ago
  Perfection
- dagmx 4y ago
  Memes aside, this has actually never been used for a shrek film. The first film it was used for was How to Train Your Dragon 3.
  - aidenn0 4y ago
    If it was used in any of the Puss in Boots movies, then it was at least used in a Shrek spinoff...
    - jsheard 4y ago
      Puss in Boots: The Last Wish was rendered with this
  - zirgs 4y ago
    They might use this renderer for the 5th one.
deleted 4y ago
[deleted]
abdellah123 4y ago
I'm a software engineer with no animation xp. Can someone explain what this tool is (and is not) and how it fits in an animation project. e.g: can I make an animation movie using only moonray? what other tools are needed? and what knowledge do I (we) need to do that?
- virtualritz 4y ago
  It's an offline 3D rendering software that turns a scene description into a photorealistic image. Usually such a description is for a single frame of animation. Offline being the opposite of realtime. I.e. a frame taking possibly hours to render whereas in a realtime renderer it must take fractions of a second. Maybe think of it like a physical camera in a movie. And a very professional one for that. But then a camera doesn't get you very far if you consider the list of people you see when credits roll by. :] Similarly, at the very least, you need something to feed the renderer a 3D scene, frame by frame. Usually this is a DCC app like Maya, Houdini etc. or something created in-house. That's where you do your animation. After you created the stuff you want to animate and the sets where that lives ... etc., etc. Moonray has a Hydra USD delegate. That is an API to send such 3D scenes to a renderer. There is one for Blender too[1]. That would be one way to get data in there, I'd reckon. Hope that makes sense. [1] https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA...
- hirako2000 4y ago
  I have no experience with moonray, but it being a render, the answer would be.. No. The renderer is only one piece of the entire animated movie production pipeline. Modeling -> Texturing ~ rigging /Animation -> post processing effects -> rendering - > video editing That's a simplified view of the visual part of producing a short or long cgi film It is a lot of knowledge to aquire so a production team is likely made of specialists and sub specialists (lighting?) working to a degree together. The best achieving software, especially given its affordability is likely Blender. Other tools lile cinema4d, Maya and of course 3d smax are also pretty good all in one products that cover the whole pileline, although pricey. Start with modeling, then texturing, then animation. Etc. Then dive into the slice that attracts you the most. Realistically you aren't going to ship a professional grade film so you may as well just learn what you love, and who knows perhaps one day become a professional and appear in the long credit name list at the end of a Disney/Pixar, Dreamworks hit.
ar9av 4y ago
Quality 3d animation software is available to anyone with Blender. If someone gets this renderer working as an addon (which will obviously happen) artist will get a side by side comparison of what their work looks like with both cycles and a professional studio product, for free. This is win, win, win for Blender, OSS and the community.
- greenknight 4y ago
  Not just that, I am assuming that there are parts of that code, that will be analysed by the Cycles developers, to enhance Cycles to improve it.
  - gabereiser 4y ago
    This. Pixar’s Renderman has been an “option” for a while. It was out of band though. The cycles team will look at the theory behind what’s going on in renderers like this and will make the tech work inside cycles. Maybe someone will port this as another render option but really the sauce is their lighting models and parallel vectorization which could improve cycles already abysmally slow render times. Renderman for Blender: https://rmanwiki.pixar.com/pages/viewpage.action?mobileBypass=true&spaceKey=RFB24&title=RenderMan+for+Blender+24.0 https://rmanwiki.pixar.com/pages/viewpage.action?mobileBypas...
    - creativenolo 4y ago
      Abysmally slow compared to? I have been impressed by it
ShadowBanThis01 4y ago
It took a bit of hunting to find what an "MCRT" renderer is: Monte Carlo raytracer.
daniel-thompson 4y ago
Surprised nobody has mentioned this, but it looks like it implements the render kernels in ISPC^, which is a tool that exposes a CUDA-like SPMD model that runs over the vector lanes in the CPU. ISPC is also used by Disney's Hyperion renderer, see https://www.researchgate.net/publication/326662420_The_Design_and_Evolution_of_Disney%27s_Hyperion_Renderer https://www.researchgate.net/publication/326662420_The_Desig... Neat! ^ https://ispc.github.io/ https://ispc.github.io/
- xmcqdpt2 4y ago
  Neat! Vectorization is the best part of writing Fortran. This looks like it makes it possible to write fortran-like code in C. I wonder how it compares to ifort / openMP?
  - daniel-thompson 4y ago
    OpenMP starts with a serial model, the programmer tags the loop they want to run in parallel with a directive, and the compiler tries to vectorize the loop. This can always fail, since it relies on a computer program reasoning about an arbitrary block of code. So you have to really dig into the SIMD directives and understand their limitations in order to write performant code that actually does get vectorized. ISPC starts with an SPMD programming model, and exposes only operations that conform to the model. "Vectorization" is performed by the developer - it's up to them to figure out how to map their algorithm or problem to the vector lanes (just like in CUDA or OpenCL). So there's no unexpectedly falling off the vectorization path - you start on it, and you can only do stuff that stays on it, by design.
    - xmcqdpt2 4y ago
      Specifically I meant OMP workshare which parallelizes vector operations in Fortran, https://www.openmp.org/spec-html/5.0/openmpsu39.html https://www.openmp.org/spec-html/5.0/openmpsu39.html sorry should have been more specific.
- ykl 4y ago
  Hyperion does not use ISPC. Source: I am one of the Hyperion developers.
ChrisMarshallNY 4y ago
Lots of submodules. We were just talking about these, the other day...
- WizardClickBoy 4y ago
  I came looking for this comment! Madness.
mindcrime 4y ago
Is anybody else intrigued by the mention of multi-machine and cloud rendering via the Arras distributed computation framework.? Is this something new? The code seems to be included as sub-modules of OMR itself, and all the repos[1][2][3] show recent "Initial Commit" messages, so I'm operating on the assumption that it is. If so, I wonder if this is something that might prove useful in other contexts... [1]: https://github.com/dreamworksanimation/arras4_core https://github.com/dreamworksanimation/arras4_core [2]: https://github.com/dreamworksanimation/arras4_node https://github.com/dreamworksanimation/arras4_node [3]: https://github.com/dreamworksanimation/arras_render https://github.com/dreamworksanimation/arras_render
- bobsomers 4y ago
  I can maybe add a bit of context to this. I worked on Moonray/Arras at DWA about 8-9 years ago. Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for shots that will get reviewed the next day. But sometimes it’s really nice to have a very immediate, interactive workflow at your desk. Typically you need to use a different renderer designed with a more real-time architecture in mind, and many times that means using shaders that don’t match, so it’s not an ideal workflow. Arras was designed to be able to give you the best of both worlds. Moonray is perfectly happy to render frames in batch mode, but it can also use Arras to connect dozens of workstations together and have them all work on the same frame in parallel. This basically gives you a film-quality interactive lighting session at your desk, where the final render will match what you see pixel for pixel because ultimately you’re using the same renderer and the same shaders.
  - sweetrobot2k 4y ago
    Sick!
  - a_e_k 4y ago
    Neat! Parallelizing a single frame across multiple machines was something I'd wanted to try back when I was working on RenderMan. It used to be able to do it back in the REYES days via netrender, but was something we lost with the move to pathtracing on the RIS architecture. Could you go into a bit more detail on how the work is distributed? Is it per tile (or some other screen-space division like macro-tiles or scan-lines)? Per sample pass? (Surely it's not scene distribution like the old Kilauea renderer from Square!) Dynamic or static scheduling? Sorry, so many questions. :-)
jtxt 4y ago
Maybe they are moving to rendering with Unreal? Our studio did.
boywitharupee 4y ago
Can someone please explain the differences between real-time renderers and offline renderers? Do real-time renderers optimize frame by frame and focus on retaining some quality while prioritizing performance, using techniques like LOD and occlusion? Do offline renderers focus solely on quality? Are scene descriptions for both types of renderers different? What are the standard description files in games versus movies?
- Arrath 4y ago
  While I'm not terribly familiar with the subject myself: Note that figure 2 in TFA calls out Astrid's character model as consisting of "1.67GB of geometry and 11.1GB of textures". That's stupidly massive compared to asset sizes for e.g. video game character models and texturing, and would probably choke a commercial real-time engine all on its own.
- ur-whale 4y ago
  Real time renderers focus on being real time as the most important constraint and therefore make lots of compromises and take a lot of shortcuts. Offline renderers try to simulate light transport as exactly as possible within a time budget. For example, one of the best algorithm to create high quality renders of scenes with very complicated light transport problems (something like this: [1]) uses ray-tracing monte-carlo integration techniques. Up until very recently, this was completely out of reach for a real time render. [1] https://blenderartists.org/uploads/default/original/4X/9/f/c/9fc01ed0e919d34be367328a28d8d9e58ead24a8.jpg https://blenderartists.org/uploads/default/original/4X/9/f/c...
- delta_p_delta_x 4y ago
  Like someone else said, real-time renders need to output at a reasonable frame-rate, which is the top priority. Therefore, per-frame image quality can take a fairly severe hit before things start being noticeable. For the record, most real-time renderers are rasterisation-based, where geometry is assembled, rasterised, and then the fragments shaded. This is what almost all video games have been running on since the 1990s. Many so-called 'RTX' games you see today still do the bulk of their rendering using rasterisation and all the associated hacks to achieve photorealism, and only enable path-tracing for specular reflection, soft shadows, and diffuse-diffuse global illumination. A high-quality real-time path-traced pipeline was impossible to achieve in playable framerates until very recently (~5 years ago). This is because we simply didn't have the hardware to do it, and denoising algorithms weren't very powerful until we got generative AI algorithms (OptiX, DLSS, etc). Even today, any real-time path-traced pipeline renders much fewer samples than any offline render does—usually 3 or 4 orders of magnitude less—simply because it would be too slow and a waste to render so many samples for a frame that would be displayed for several milliseconds and then promptly discarded. Offline renderers do jack the quality up, and they use massive render-farms with hundreds of thousands of cores, with memory on the order of 10^14-10^15 bytes. The scales are completely off the charts; a single frame using an off-line renderer can take up to several hours to render on an average home computer.
ur-whale 4y ago
So, I've finally managed to compile Moonray and play with it. TBH, this was really not as straightforward as it ought to have been: - some Optix-using code failed to compile against latest Optix SDK, code had to be patched. - the build instructions at [4] aren't completely foolproof either (don't quit the container before you manage to snapshot it, or else) When I finally got a clean compile, I tried to render a USD scene [1] ... it turns out Moonray only reads its own proprietary format (RDL) and you need to convert like so (I haven't found this documented anywhere, [3] now fails to load for me) hd_usd2rdl -in Attic_NVIDIA.usd -out Attic_NVIDIA.rdla To quote [2]: Hydra Render Delegate MoonRay comes with a Hydra Render Delegate that is compatible with any DCC tool with Hydra support, for interactive preview rendering. Upon finalization of the Hydra API specification, MoonRay will provide support for final frame batch rendering, and its Hydra Render Delegate will be the supported path to transform USD into MoonRay's internal RDL scene format. The conversion is not without hiccups: Warning: in Tf_PyLoadScriptModule at line 122 of /build/USD-prefix/src/USD/pxr/base/tf/pyUtils.cpp -- Import failed for module 'pxr.Glf'! ModuleNotFoundError: No module named 'pxr' The render is also problematic, is spits a long list of stuff like this (fails to load textures, basically): Invalid image file "/tmp/Attic_NVIDIA/Materials/PreviewSurfaceTextures/curtain_mat_inst_Roughness.png": OpenImageIO could not find a format reader for "/tmp/Attic_NVIDIA/Materials/PreviewSurfaceTextures/curtain_mat_inst_Roughness.png". Is it a file format that OpenImageIO doesn't know about? Resulting render looks ugly (no textures) In conclusion: fantastic that Dreamworks decided to release Moonray, but at this point, it's still got some very sharp edges. [1] this one: https://developer.nvidia.com/attic-nvidia https://developer.nvidia.com/attic-nvidia [2] https://openmoonray.org/about https://openmoonray.org/about [3] https://docs.openmoonray.org/ https://docs.openmoonray.org/ [4] https://docs.openmoonray.org/getting-started/installation/building-moonray/building-moonray-container/ https://docs.openmoonray.org/getting-started/installation/bu...
- bobsomers 4y ago
  I wrote the RDL2 library for Moonray when I worked at DWA about 8-9 years ago. At the time, USD was still very nascent, and we already had RDL (v1) as an internal reference point, so that’s ultimately why Moonray uses something “non-standard” by modern conventions. RDL has two on-disk formats, RDLA (for “Ascii”) and RDLB (for “Binary”). The text format is literally just a Lua script which uses various function calls to instantiate scene objects and set their parameters. It’s great for spinning up test scenes and doing development work on shaders or the renderer itself. The binary format (which at the time used Protobuf to serialize scene objects, not sure if that’s still true) is more suited to production workflows where you don’t want to deal with things like floating point to text precision issues and a more space efficient representation is preferred. I found some documentation and examples of the RDL format here: https://docs.openmoonray.org/getting-started/about/rdl-scene-format/ https://docs.openmoonray.org/getting-started/about/rdl-scene... And it looks like the user documentation has some examples of how to do things, including instantiating various types of scene objects: https://docs.openmoonray.org/user-reference/ https://docs.openmoonray.org/user-reference/

765 points by dagmx 4y ago

Man, I can't wait for this to be properly (luxrender-level) integrated to Blender. Especially the shaders (materials), which I feel is currently the weakest part of all the open source renders Blender supports natively (eevee, cycles, lux)

boppo1 4y ago
Can you elaborate on what's not good about eevee/cycles shaders? By proper integration do you imagine it will use Blender's node shader system or a different system? I'm not being combative, I'm in the process of learning enough of Blender's code to be able to contribute.
- ur-whale 4y ago
  I could write a book about this, but to make it short, what most users of a 3D system like Blender want when they get to the shading/rendering part of their work is to simply: - pick an object in the scene - pick a pre-made rich and complicated shader (wood, glass, tar, etc...) from a huge library of shaders expressed in a standard form (as in: that will work with whichever render, be it cycles, luxrender, moonray, etc...) - drop it to the object without having to screw around for hours with texture scaling, rotation, uvs - rinse and repeat until all objects in the scene are shaded Very few people have the skills/knowledge and patience to put their own shaders together themselves by assembling basic nodes into a large and complicated shader tree. There has been some (feeble) attempts to build standard libraries of Shaders around Blender: https://github.com/LuxCoreRender/LoL https://github.com/LuxCoreRender/LoL https://www.youtube.com/watch?v=mCShkpW1c2w https://www.youtube.com/watch?v=mCShkpW1c2w These are: - hard to use - not always free - not standard and portable across renders In practice, assigning materials to a large scene in Blender is still a giant, time-consuming PITA.
  - _flux 4y ago
    I've used Blender only a little, but surely you're aware of the Asset Browser introduced in the 3.0? They seem easy enough to use, but of course they'd need to be high-quality to work similarly with all renderers. Granted I don't actually know where to find such libraries except for the small free asset bundles at https://www.blender.org/download/demo-files/#assets https://www.blender.org/download/demo-files/#assets or perhaps by paying Blender organization for them, so maybe this doesn't really address your core point :).

chungy 4y ago

The README is a bit opaque when I don't know the terminology, but the website seems to clue me in that it's a raytracer: https://openmoonray.org/ https://openmoonray.org/

pcollinsmokonut 4y ago
It is a path-tracer which is slightly more advanced than a ray-tracer.
toxik 4y ago
MCRT = Monte Carlo Ray Tracing

homarp 4y ago

previous discussion https://news.ycombinator.com/item?id=32357470 https://news.ycombinator.com/item?id=32357470

app4soft 4y ago
It was an announcement of upcoming source opening, but at the moment there was no public source repo.

ykl 4y ago

For anyone that is curious, this is the paper that describes the core vectorized path tracing architecture in Moonray: http://www.tabellion.org/et/paper17/MoonRay.pdf http://www.tabellion.org/et/paper17/MoonRay.pdf Extracting sufficient coherency from path tracing in order to be able to get good SIMD utilization is a surprisingly difficult problem that much research effort has been poured into, and Moonray has a really interesting solution!

bhouston 4y ago
Is there any comparisons to GPU-accelerated rendering? It seems most people are going that direction rather than trying to optimize for CPUs these days, especially via AVX instructions.
- jsheard 4y ago
  CPUs are still king at the scale Dreamworks/Pixar/etc operate at, GPUs are faster up to a point but they hit a wall in extremely large and complex scenes. They just don't have enough VRAM, or the work is too divergent and batches too small to keep all the threads busy. In recent years the high-end renderers (including MoonRay) have started supporting GPU rendering alongside their traditional CPU modes, but the GPU mode is meant for smaller scale work like an artist iterating on a single asset, and then for larger tasks and final frame rendering it's still off to the CPU farm. Pixar did a presentation on bringing GPU rendering to Renderman, which goes over some of the challenges: https://www.youtube.com/watch?v=tiWr5aqDeck https://www.youtube.com/watch?v=tiWr5aqDeck
  - pixelpoet 4y ago
    What's your opinion on renderers such as Redshift which explicitly target production rendering and support out of core rendering on GPUs? See e.g. https://www.maxon.net/en/redshift/features?categories=631816 https://www.maxon.net/en/redshift/features?categories=631816 (Disclosure: I work on this.)
    - berkut 4y ago

bhouston 4y ago

Looks nice! It has a Hydra render delegate so that is nice. Does Blender support being a Hydra client yet? It would be nice to have it supported natively in Blender itself. If it did, one could easily switch renderers between this and others. I understand Autodesk is going this way with its tooling.

capableweb 4y ago
> It would be nice to have it supported natively in Blender itself. If it did, one could easily switch renderers between this and others. Blender in general is setup to work with different renderers, especially since the work of Eevee which is the latest renderer to be added. Some part of the work on integrating Eevee also put some groundwork for making it easier in the future to add more of them. Most probably this renderer would be added as a addon (if someone in the community does it), rather than in the core of Blender.
semi-extrinsic 4y ago
I had the same question. There exists a USD addon for Blender that support Hydra, so probably you could get that to work with a bit of trial and error! https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA...
dagmx 4y ago
AMD have an addon for Blender that supports Hydra, though it is a bit slow. There's ongoing work to add it to Blender itself natively https://projects.blender.org/BogdanNagirniak/blender/src/branch/hydra-render https://projects.blender.org/BogdanNagirniak/blender/src/bra...

dimator 4y ago

i'm curious: what is the incentive for dreamworks to open-source this? surely having exclusive access to a parallel renderer of this quality is a competitive advantage to other studios?

ronsor 4y ago
The other large studios that compete with them (e.g. Pixar) already have their own just-as-good renderers.
- fuzzybear3965 4y ago
  Even still, what's the incentive to open-source? So the community can bootstrap a better solution than Pixar?
  - mdorazio 4y ago
    By showing they care about open source, there's a chance they'll attract developers and animators who care about that.
    - pipo234 4y ago
      Seems targeted at CentOS7, support for which is sunset in little over a year. Smells a bit like abandonware, hoping for adoption by unpaid volunteers. Still, dumping it into FOSS community is not the worst graveyard for commercial software...
      - Vt71fcAqt7 4y ago
        They just released a feature film with this renderer, grossing $462 million and widely praised for its animation. Large studios don't update so regularly vs e.g. a startup. They have very specific setups, which is in fact a large part of why it took them so long to release moonray vs when they said they would last year. And they are moving to Rocky Linux soon IIRC. >dumping it into FOSS community They are not "dumping" anything. Would it have hurt to look into the facts before commenting?

antegamisou 4y ago

Wonder how it fares against the monopoly of Pixar’s Renderman.

ralusek 4y ago
I don't think there is a monopoly renderer.
- jsheard 4y ago
  There isn't even a monopoly within Disney, they acquired Pixar 17 years ago but Disney Animation Studios still develop their own Hyperion renderer completely independently of Pixar/Renderman.
  - sosodev 4y ago
    Just because it's hard to migrate existing workflows or is there something that makes Hyperion superior?
    - jsheard 4y ago
      Hyperion has the advantage of being exclusive to WDAS, so they can tailor it to their exact workflow and requirements, while Renderman is a commercial product with many users outside of Pixar all with their own wants and needs.
    - Arelius 4y ago
      Hyperion was designed to specifically take advantage of a specific ray batching architecture that's particularly good for out of core renderers. Which can be good for particularly large and complex scenes.

app4soft 4y ago

Anybody has a success with build & run it under Linux? (Debian 11.x/Ubuntu 22.04.x)

zokier 4y ago
The docs are for centos but from the looks of it I don't see any major roadblocks for Debian based distros? https://docs.openmoonray.org/getting-started/installation/building-moonray/building-moonray-centos-7/ https://docs.openmoonray.org/getting-started/installation/bu...
alhirzel 4y ago
It appears they currently only support a Docker container build and a CentOS build. I am working on a build script (PKGBUILD) for Arch Linux.
ur-whale 4y ago
The docker-based build worked fine for me on Ubuntu 22.04. I haven't yet tried to pull the resulting binaries out of the docker container to see if it still works natively on 22.04.
gonsolo 4y ago
Yes: https://github.com/dreamworksanimation/openmoonray/issues/45 https://github.com/dreamworksanimation/openmoonray/issues/45 It's quite a hack, but it works. :)

pipeline_peak 4y ago

o boi, shrek engine

isatty 4y ago
Perfection
dagmx 4y ago
Memes aside, this has actually never been used for a shrek film. The first film it was used for was How to Train Your Dragon 3.
- aidenn0 4y ago
  If it was used in any of the Puss in Boots movies, then it was at least used in a Shrek spinoff...
  - jsheard 4y ago
    Puss in Boots: The Last Wish was rendered with this
- zirgs 4y ago
  They might use this renderer for the 5th one.

deleted 4y ago

[deleted]

abdellah123 4y ago

I'm a software engineer with no animation xp. Can someone explain what this tool is (and is not) and how it fits in an animation project. e.g: can I make an animation movie using only moonray? what other tools are needed? and what knowledge do I (we) need to do that?

virtualritz 4y ago
It's an offline 3D rendering software that turns a scene description into a photorealistic image. Usually such a description is for a single frame of animation. Offline being the opposite of realtime. I.e. a frame taking possibly hours to render whereas in a realtime renderer it must take fractions of a second. Maybe think of it like a physical camera in a movie. And a very professional one for that. But then a camera doesn't get you very far if you consider the list of people you see when credits roll by. :] Similarly, at the very least, you need something to feed the renderer a 3D scene, frame by frame. Usually this is a DCC app like Maya, Houdini etc. or something created in-house. That's where you do your animation. After you created the stuff you want to animate and the sets where that lives ... etc., etc. Moonray has a Hydra USD delegate. That is an API to send such 3D scenes to a renderer. There is one for Blender too[1]. That would be one way to get data in there, I'd reckon. Hope that makes sense. [1] https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA...
hirako2000 4y ago
I have no experience with moonray, but it being a render, the answer would be.. No. The renderer is only one piece of the entire animated movie production pipeline. Modeling -> Texturing ~ rigging /Animation -> post processing effects -> rendering - > video editing That's a simplified view of the visual part of producing a short or long cgi film It is a lot of knowledge to aquire so a production team is likely made of specialists and sub specialists (lighting?) working to a degree together. The best achieving software, especially given its affordability is likely Blender. Other tools lile cinema4d, Maya and of course 3d smax are also pretty good all in one products that cover the whole pileline, although pricey. Start with modeling, then texturing, then animation. Etc. Then dive into the slice that attracts you the most. Realistically you aren't going to ship a professional grade film so you may as well just learn what you love, and who knows perhaps one day become a professional and appear in the long credit name list at the end of a Disney/Pixar, Dreamworks hit.

ar9av 4y ago

Quality 3d animation software is available to anyone with Blender. If someone gets this renderer working as an addon (which will obviously happen) artist will get a side by side comparison of what their work looks like with both cycles and a professional studio product, for free. This is win, win, win for Blender, OSS and the community.

greenknight 4y ago
Not just that, I am assuming that there are parts of that code, that will be analysed by the Cycles developers, to enhance Cycles to improve it.
- gabereiser 4y ago
  This. Pixar’s Renderman has been an “option” for a while. It was out of band though. The cycles team will look at the theory behind what’s going on in renderers like this and will make the tech work inside cycles. Maybe someone will port this as another render option but really the sauce is their lighting models and parallel vectorization which could improve cycles already abysmally slow render times. Renderman for Blender: https://rmanwiki.pixar.com/pages/viewpage.action?mobileBypass=true&spaceKey=RFB24&title=RenderMan+for+Blender+24.0 https://rmanwiki.pixar.com/pages/viewpage.action?mobileBypas...
  - creativenolo 4y ago
    Abysmally slow compared to? I have been impressed by it

ShadowBanThis01 4y ago

It took a bit of hunting to find what an "MCRT" renderer is: Monte Carlo raytracer.

daniel-thompson 4y ago

Surprised nobody has mentioned this, but it looks like it implements the render kernels in ISPC^, which is a tool that exposes a CUDA-like SPMD model that runs over the vector lanes in the CPU. ISPC is also used by Disney's Hyperion renderer, see https://www.researchgate.net/publication/326662420_The_Design_and_Evolution_of_Disney%27s_Hyperion_Renderer https://www.researchgate.net/publication/326662420_The_Desig... Neat! ^ https://ispc.github.io/ https://ispc.github.io/

xmcqdpt2 4y ago
Neat! Vectorization is the best part of writing Fortran. This looks like it makes it possible to write fortran-like code in C. I wonder how it compares to ifort / openMP?
- daniel-thompson 4y ago
  OpenMP starts with a serial model, the programmer tags the loop they want to run in parallel with a directive, and the compiler tries to vectorize the loop. This can always fail, since it relies on a computer program reasoning about an arbitrary block of code. So you have to really dig into the SIMD directives and understand their limitations in order to write performant code that actually does get vectorized. ISPC starts with an SPMD programming model, and exposes only operations that conform to the model. "Vectorization" is performed by the developer - it's up to them to figure out how to map their algorithm or problem to the vector lanes (just like in CUDA or OpenCL). So there's no unexpectedly falling off the vectorization path - you start on it, and you can only do stuff that stays on it, by design.
  - xmcqdpt2 4y ago
    Specifically I meant OMP workshare which parallelizes vector operations in Fortran, https://www.openmp.org/spec-html/5.0/openmpsu39.html https://www.openmp.org/spec-html/5.0/openmpsu39.html sorry should have been more specific.
ykl 4y ago
Hyperion does not use ISPC. Source: I am one of the Hyperion developers.

ChrisMarshallNY 4y ago

Lots of submodules. We were just talking about these, the other day...

WizardClickBoy 4y ago
I came looking for this comment! Madness.

mindcrime 4y ago

Is anybody else intrigued by the mention of multi-machine and cloud rendering via the Arras distributed computation framework.? Is this something new? The code seems to be included as sub-modules of OMR itself, and all the repos[1][2][3] show recent "Initial Commit" messages, so I'm operating on the assumption that it is. If so, I wonder if this is something that might prove useful in other contexts... [1]: https://github.com/dreamworksanimation/arras4_core https://github.com/dreamworksanimation/arras4_core [2]: https://github.com/dreamworksanimation/arras4_node https://github.com/dreamworksanimation/arras4_node [3]: https://github.com/dreamworksanimation/arras_render https://github.com/dreamworksanimation/arras_render

bobsomers 4y ago
I can maybe add a bit of context to this. I worked on Moonray/Arras at DWA about 8-9 years ago. Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for shots that will get reviewed the next day. But sometimes it’s really nice to have a very immediate, interactive workflow at your desk. Typically you need to use a different renderer designed with a more real-time architecture in mind, and many times that means using shaders that don’t match, so it’s not an ideal workflow. Arras was designed to be able to give you the best of both worlds. Moonray is perfectly happy to render frames in batch mode, but it can also use Arras to connect dozens of workstations together and have them all work on the same frame in parallel. This basically gives you a film-quality interactive lighting session at your desk, where the final render will match what you see pixel for pixel because ultimately you’re using the same renderer and the same shaders.
- sweetrobot2k 4y ago
  Sick!
- a_e_k 4y ago
  Neat! Parallelizing a single frame across multiple machines was something I'd wanted to try back when I was working on RenderMan. It used to be able to do it back in the REYES days via netrender, but was something we lost with the move to pathtracing on the RIS architecture. Could you go into a bit more detail on how the work is distributed? Is it per tile (or some other screen-space division like macro-tiles or scan-lines)? Per sample pass? (Surely it's not scene distribution like the old Kilauea renderer from Square!) Dynamic or static scheduling? Sorry, so many questions. :-)

jtxt 4y ago

Maybe they are moving to rendering with Unreal? Our studio did.

boywitharupee 4y ago

Can someone please explain the differences between real-time renderers and offline renderers? Do real-time renderers optimize frame by frame and focus on retaining some quality while prioritizing performance, using techniques like LOD and occlusion? Do offline renderers focus solely on quality? Are scene descriptions for both types of renderers different? What are the standard description files in games versus movies?

Arrath 4y ago
While I'm not terribly familiar with the subject myself: Note that figure 2 in TFA calls out Astrid's character model as consisting of "1.67GB of geometry and 11.1GB of textures". That's stupidly massive compared to asset sizes for e.g. video game character models and texturing, and would probably choke a commercial real-time engine all on its own.
ur-whale 4y ago
Real time renderers focus on being real time as the most important constraint and therefore make lots of compromises and take a lot of shortcuts. Offline renderers try to simulate light transport as exactly as possible within a time budget. For example, one of the best algorithm to create high quality renders of scenes with very complicated light transport problems (something like this: [1]) uses ray-tracing monte-carlo integration techniques. Up until very recently, this was completely out of reach for a real time render. [1] https://blenderartists.org/uploads/default/original/4X/9/f/c/9fc01ed0e919d34be367328a28d8d9e58ead24a8.jpg https://blenderartists.org/uploads/default/original/4X/9/f/c...
delta_p_delta_x 4y ago
Like someone else said, real-time renders need to output at a reasonable frame-rate, which is the top priority. Therefore, per-frame image quality can take a fairly severe hit before things start being noticeable. For the record, most real-time renderers are rasterisation-based, where geometry is assembled, rasterised, and then the fragments shaded. This is what almost all video games have been running on since the 1990s. Many so-called 'RTX' games you see today still do the bulk of their rendering using rasterisation and all the associated hacks to achieve photorealism, and only enable path-tracing for specular reflection, soft shadows, and diffuse-diffuse global illumination. A high-quality real-time path-traced pipeline was impossible to achieve in playable framerates until very recently (~5 years ago). This is because we simply didn't have the hardware to do it, and denoising algorithms weren't very powerful until we got generative AI algorithms (OptiX, DLSS, etc). Even today, any real-time path-traced pipeline renders much fewer samples than any offline render does—usually 3 or 4 orders of magnitude less—simply because it would be too slow and a waste to render so many samples for a frame that would be displayed for several milliseconds and then promptly discarded. Offline renderers do jack the quality up, and they use massive render-farms with hundreds of thousands of cores, with memory on the order of 10^14-10^15 bytes. The scales are completely off the charts; a single frame using an off-line renderer can take up to several hours to render on an average home computer.

ur-whale 4y ago

So, I've finally managed to compile Moonray and play with it. TBH, this was really not as straightforward as it ought to have been: - some Optix-using code failed to compile against latest Optix SDK, code had to be patched. - the build instructions at [4] aren't completely foolproof either (don't quit the container before you manage to snapshot it, or else) When I finally got a clean compile, I tried to render a USD scene [1] ... it turns out Moonray only reads its own proprietary format (RDL) and you need to convert like so (I haven't found this documented anywhere, [3] now fails to load for me) hd_usd2rdl -in Attic_NVIDIA.usd -out Attic_NVIDIA.rdla To quote [2]: Hydra Render Delegate MoonRay comes with a Hydra Render Delegate that is compatible with any DCC tool with Hydra support, for interactive preview rendering. Upon finalization of the Hydra API specification, MoonRay will provide support for final frame batch rendering, and its Hydra Render Delegate will be the supported path to transform USD into MoonRay's internal RDL scene format. The conversion is not without hiccups: Warning: in Tf_PyLoadScriptModule at line 122 of /build/USD-prefix/src/USD/pxr/base/tf/pyUtils.cpp -- Import failed for module 'pxr.Glf'! ModuleNotFoundError: No module named 'pxr' The render is also problematic, is spits a long list of stuff like this (fails to load textures, basically): Invalid image file "/tmp/Attic_NVIDIA/Materials/PreviewSurfaceTextures/curtain_mat_inst_Roughness.png": OpenImageIO could not find a format reader for "/tmp/Attic_NVIDIA/Materials/PreviewSurfaceTextures/curtain_mat_inst_Roughness.png". Is it a file format that OpenImageIO doesn't know about? Resulting render looks ugly (no textures) In conclusion: fantastic that Dreamworks decided to release Moonray, but at this point, it's still got some very sharp edges. [1] this one: https://developer.nvidia.com/attic-nvidia https://developer.nvidia.com/attic-nvidia [2] https://openmoonray.org/about https://openmoonray.org/about [3] https://docs.openmoonray.org/ https://docs.openmoonray.org/ [4] https://docs.openmoonray.org/getting-started/installation/building-moonray/building-moonray-container/ https://docs.openmoonray.org/getting-started/installation/bu...

bobsomers 4y ago
I wrote the RDL2 library for Moonray when I worked at DWA about 8-9 years ago. At the time, USD was still very nascent, and we already had RDL (v1) as an internal reference point, so that’s ultimately why Moonray uses something “non-standard” by modern conventions. RDL has two on-disk formats, RDLA (for “Ascii”) and RDLB (for “Binary”). The text format is literally just a Lua script which uses various function calls to instantiate scene objects and set their parameters. It’s great for spinning up test scenes and doing development work on shaders or the renderer itself. The binary format (which at the time used Protobuf to serialize scene objects, not sure if that’s still true) is more suited to production workflows where you don’t want to deal with things like floating point to text precision issues and a more space efficient representation is preferred. I found some documentation and examples of the RDL format here: https://docs.openmoonray.org/getting-started/about/rdl-scene-format/ https://docs.openmoonray.org/getting-started/about/rdl-scene... And it looks like the user documentation has some examples of how to do things, including instantiating various types of scene objects: https://docs.openmoonray.org/user-reference/ https://docs.openmoonray.org/user-reference/