Dreamworks released MoonRay, an open source production renderer. It has many interesting features and is of course production proven. It’s unclear how it will evolve in the future, if MoonRay will end up replacing many commercial and/or open source renderers, if other studios will adopt it, if it will also find a way to individual users, etc. But it certainly will be interesting.
Many will be asking for MoonRay integration into Blender, and the path to that is through Hydra. Blender support for Hydra is being worked on, and the MoonRay developers have indicated they are following this development and also see it as the way to go. The Blender Hydra implementation will need to mature, and renderer add-ons need to do additional work to integrate nicely besides what is offered by the Hydra API. So expect this to take some time.
MoonRay has GPU acceleration for ray intersection, but appears to run everything else including shading and sampling on the CPU. Cycles on the other hand was designed to have equal functionality on the CPU and GPU, which tends to give better performance but can also be more restrictive or time consuming in implementing features.
It will be interesting to see how MoonRay evolves in this area, if there will be a big rewrite to port the full renderer to the GPU and adapt algorithms. Their current approach to for interactivity is through networked rendering with many CPUs. This may be less suitable for an individual Blender users, where fast rendering on a single GPU is the most common workflow.
Cycles and Blender aim to support GPUs from different vendors with NVIDIA, AMD, Intel and Apple. MoonRay for now only has ray intersection offloading for NVIDIA cards. If those vendors get involved in MoonRay I think that will benefit other renderers like Cycles as well, as the APIs are not as mature yet and many of the same challenges we have will need to be resolved.
From the Cycles’ side, we’ll certainly be looking at the code for inspiration. It is Apache licensed just like Cycles and so exchanging code should be simple in that regard. Hopefully there will also be ways in which we can collaborate directly or indirectly.
I agree, It would be great to have XPU feature in cycles by checking moonray’s code, Renderman also has XPU and Moonray is good way to read the code to understand how XPU can be implemented to Cycles. We have light tree and also if path guiding comes to GPU, and plus XPU can make cycles extra fast alll together, Cycles can almost become the render engine applying and perfecting all the newly invented features as pioneer (because as far as I know , most commercial engines stick to one side to improve on one area to have fame on that area, so users always compare advantages or disasvantages, but Cycles seem like becoming one with the one who easily adopt all the best new ways from papers or new technologies to add them on the refactored base thanks to Cycles X). Also if moonray has a feature similar to adaptive domelight that automatically detect windows isntead of manually using portals, it might also be good thing to implement to cycles by inspiring from its code
XPU doesn’t mean the same thing in Renderman and Moonray,. Assuming you refer to doing only ray tracing on the GPU and the rest on the CPU as in Moonray, it was an explicit decision for Cycles not to work like that.
I think that’s more a way for existing CPU renderers to get some extra performance, rather than a way to design a render engine with best performance.
I could be mis-understanding this, but I believe the Moonray approach of GPU for ray traversal and CPU for everything else has some other benefits.
By only doing the ray traversal on the GPU, you only need to store the BVH and scene geometry on the GPU, allowing GPUs with “small” amounts of VRAM to be used to speed up the rendering of larger scenes.
With Cycles, if the scene doesn’t fit in VRAM, you have to render with the CPU. With this combined approach, larger scenes can still fit in VRAM meaning CPU rendering can be sped up, even on large scenes.
And since the GPU isn’t doing any shading, a bunch of features can be implemented easier. For example, external libraries can be used in Cycles with GPU ray traversal acceleration while the librarie doesn’t have GPU backend support. For example OSL, or Open Path Guiding, or OpenImageIO with on-demand texture loading and mip-mapping should work with this approach. Maybe MaterialX?
For me personally, I would like to see this “GPU for traversal, CPU for everything else” approach added to Cycles as an option, primarily due to it’s ability to improve feature parity between “GPU backends” by running shading and some other functions on the CPU.
I do understand that this comes with a reduction in performance compared to GPU only in almost all situations.
There are some benefits, but the other solution to those is to work on out of core GPU rendering. Implementing multiple approaches in Cycles adds code complexity and constraints on the design, and energy spent on optimizing yet another type of device configuration.
We already spend too much time on this sort of thing in Cycles by supporting many different GPU APIs and devices, and not enough on algorithmic optimizations and features.
i personally hope that Out of Core rendering will be enabled in both Cycles and Moonray in the future (maybe Blender 4.x) I am tired of my GPU ram limitations and would be OK with a small performance drop on GPU for out of core rendering as it would still be faster than just rendering on CPU … Blenders current out of core rendering system is clunky and doesnt always work … would be nice if it had full out of core rendering … additionally i do look forward to the future of Blender and this new Hydra thingy