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)
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.
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.
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/
TBH, this was really not as straightforward as it ought to have been:
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) To quote [2]:Hydra Render Delegate
The conversion is not without hiccups: The render is also problematic, is spits a long list of stuff like this (fails to load textures, basically): 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
[2] https://openmoonray.org/about
[3] https://docs.openmoonray.org/
[4] https://docs.openmoonray.org/getting-started/installation/bu...