MoonRay Renderer from Dreamworks - blender native renderer.
MoonRay is DreamWorks’ open-source, award-winning, state-of-the-art production Monte Carlo Ray Tracing renderer, which has been used on feature films such as How to Train Your Dragon: The Hidden World, Trolls World Tour, The Bad Guys, the upcoming Puss In Boots: The Last Wish, as well as future titles. MoonRay was developed at DreamWorks and is in continuous active development and includes an extensive library of production-tested, physically based materials, a USD Hydra render delegate, multi-machine and cloud rendering via the Arras distributed computation framework.
MoonRay is developed in-house and is maintained by DreamWorks Animation for all of their feature film production. Many thanks go to all of the engineers for building and delivering this state of the art MCRT renderer since the very beginning, and to DreamWorks Animation for continuing a long tradition of contributing back to the wider computer graphics community.
DreamWorks Animation has Open Sourced MoonRay [ openmoonray.org/ ], its in-house production renderer, it is available now at ...
github.com/dreamworksanimation/openmoonray
MoonRay is released under the Apache License, Version 2.0, which is a the same license as Cycles.
Considering this is production tested on more than 8 Feature Films and Shorts and has over 50 full time developers as well as about 30 contributors working on it integration into blender just makes sense.
This should be the target for blender 4.0.
12 Comments
Why it isn't expected to be feasible in its current state:
Normally it takes several years to get from its current state to a state that is mature enough to be included in a tool like Blender. Then there is also the responsibility who should be doing this. Blender Foundation doesn't have the resources to do such a project as it requires a full time team of several developers only to investigate what is missing and what should be developed.]
Yes it is promissing, but being open source is just a small step of the many huge steps that needs to be taken before it can be included anywhere useful for end-users/individuals.
Perhaps the easiest path is the USD/Hydra path, which is already in development.
I though the USD/Hydra path would be the easiest way as well that's why I mentioned it in the OP.
OK so probably not possible in the very short term but IMO should be on the radar for the near future. Some thoughts, would like to hear your thoughts on them...
With Apple and Microsoft as sponsors porting work could be offloaded to them,they probably know their platforms better plus help from Nvidia / Intel / AMD GPU teams.
There are other people on the MoonRay dev team from Intel etc. with minimal input from the MoonRay core devs it could be possible.
Initial releases should only be testing only not production, cause surely its a complex renderer.
This would be a bit tricky as MoonRay can have some elaborate setups. Ultimately to what LuxCore has in place, its own Shader Editor.
Similar to how 3rd party renderers currently do it. Rendering Parameters exposed in the Render Properties, Lights and World Properties change etc.
I think you're on the right track with the discussion! See hereby feedback based on my experience of commercial giants, studios and open source communities.
It isn't realistic to believe that we have the power to change priorities of commercial entities. Especially those big ones you mentioned. They need to make their own priority and sometimes they match ours.
Most render engine developers partner up with Hardware vendors as that is a win-win combination. That is common practice, not something special. It just points out the complexity that goes into making a render engine.
Any development should strive to hit the market as soon as possible to get feedback from community. In my experience it takes years to develop (even integrate) technologies in a way that it is useful for everyone in the community. See for example how hard it is for some vendors to actually support a production renderer.
Any integration should happen on the same level as Cycles or any other external render engine. (Cycles is developed as an addon and can be disabled, you know) I haven't seen any features that should be developed to core blender in order to support other render engines that isn't already planned or in development. In order to integrate another render engine in Blender requires a lot of TD work, not code development work. Development that are still in progress:
Biggest challenge isn't on Blender's core, but on making sure that an for years developed internal tool can be used by regular users (responsibility for MoonRays community), Integrate MoonRay into Blender (can be anyone's responsibility, but don't think BF would be the ideal candidate for this; explanation below).
The technology is very promising, but it is too early to say how the future of MoonRay will look like. What are their target audience. If they chose to stick to bigger studios with own development/maintenance teams, then they have other priorities than when targeting artists.
That all said, what does it bring to Blender... There is quite some benefits to artists and smaller studios to distribute it directly in a Blender release. The maintenance, shift of knowledge, would be very difficult to sell. Cycles has been designed with artists in mind. And when facing technical decisions we also make a small studio would be able to maintain a cycles setup. A real production renderer can be very overwhelming and might not be an ideal render engine for a community product like Blender. That doesn't stop anyone to actually develop and deliver this outside the flag of Blender Foundation. This has been proven many times to be more feasible.
Hello, please create a pull request to realize the right click select idea for loop cut in edit mode for surface object: blender.community/c/rightclickselect/v86n/ Thank you!
Here is Brecht's comment about MoonRay: devtalk.blender.org/t/moonray-and-cycles/28436
That would be a gigantic task and is unthinkable for Blender 4.0 As long as the roadmap for Moonray isn't clear, Windows, Macos and other linux versions arent avalible and other Hardware is supported, we dont have to think about that.
It would need huge support from hardware vendors AND Dreamworks and integrating it on the UI and UX side is a huge task on its own. maybe a dream for the distant future.
I suspect this isn't something the current BF can realistically do with their current team size and resources. Maybe someone external or addon devs could, but that sounds like it would require a dedicated team for it.
Maybe this is usefull
github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon
What about to improve Cycles with Moonray's API and architecture?
I could be wrong but that would probably take longer than integrating MoonRay into blender.
Also an option would be intergrating Cycles features that are missing ( If any ) to MoonRay. As it's all Open Source.
Switching an architecture can be compared with rebuilding an application. Cycles just had a new architecture and it doesn't make sense to replace it with another one just because.... Same with changing an API. an API is built with an architecture in mind.