MoonRay plugin for Blender

Contributing to Blender
1

Hey all, I’ve recently been working on a MoonRay plugin for Blender. You can see the code that I have at the moment.

I’m a bit stuck on linking the hdMoonrayRendererPlugin to a bpy.types.HydraRenderEngine in Blender 4.1.

11 Likes
2

I’ve successfully built MoonRay for RHEL9, but when trying to register the plugin, I first get:

Import failed for module 'pxr.UsdMtlx'! ModuleNotFoundError: No module named 'pxr.UsdMtlx'

It also says that Plugin HdMoonrayRendererPlugin is missing TfType registration

1 Like
3

It’s hard to say much without the complete error message, and an explanation of what you were doing (like running a particular command). Otherwise there is too much guesswork.

Note that running import pxr.UsdMtlx in the console editor in Blender works for me.

One thing to be aware of is that you should build Hydra plugins against the same USD version that Blender uses.

  • Blender 4.1 → USD 23.11
  • Blender 4.2 → USD 24.05
1 Like
4

It seems the website doesn’t like me copy and pasting the full error message, but here’s a screenshot of the full warning.

Screenshot from 2024-06-25 14-00-10
Screenshot from 2024-06-25 14-00-101608×136 9.91 KB

The error occurs when I toggle the render viewport. I’m using a custom python class called MoonRayRenderEngine

import bpy

class MoonRayRenderEngine(bpy.types.HydraRenderEngine):
    bl_idname = "MOONRAY"
    bl_label = "MoonRay"
    bl_info = "Dreamworks' MoonRay Production Renderer integration"

    bl_use_preview = True
    bl_use_gpu_context = True
    bl_use_materialx =False

    bl_delegate_id = "HdMoonrayRendererPlugin"

    @classmethod
    def register(cls):
        import pxr.Plug
        pxr.Plug.Registry().RegisterPlugins(['/home/cjhosken/org/dreamworks/openmoonray/plugin'])


    def get_render_settings(self, engine_type):
        settings = bpy.context.scene.moonray

        result = {}

        if engine_type != "VIEWPORT":
            result |= {
                'aovToken:Combined': "color",
                'aovToken:Depth': "depth",
            }

        return result
    
    def update_render_passes(self, scene, render_layer):
        if render_layer.use_pass_z:
            self.register_pass(scene, render_layer, 'Depth', 1, 'Z', 'VALUE')

    def update(self, data, depsgraph):
        super().update(data, depsgraph)


def register():
    bpy.utils.register_class(MoonRayRenderEngine)

def unregister():
    bpy.utils.unregister_class(MoonRayRenderEngine)

Moonray currently relies on USD 22.11. I’ll have a go at rebuilding with USD 23.11 and let you know what happens.

5

building for USD 23.11 seems to compile successfully (had to update a few lines in moonray)

I’m now getting this error when trying to run blender

------------------------------ blender terminated ------------------------------ blender crashed. FATAL ERROR: [TF_DEBUG_ENVIRONMENT_SYMBOL] multiple debug symbol definitions for 'TF_SCRIPT_MODULE_LOADER'. This is usually due to software misconfiguration, such as multiple versions of the same shared library loaded simultaneously in the process. Please check your build configuration. in _Register at line 139 of /src/build_linux/deps/build/usd/src/external_usd/pxr/base/tf/debug.cpp writing crash report to [ cj-rhel:/var/tmp/st_blender.934840 ] ... done. --------------------------------------------------------------------------------

There are numerous libusd files in /usr/local/lib, deleting them allows blender to start, but then I get
Coding Error: in _Load at line 260 of /src/build_linux/deps/build/usd/src/external_usd/pxr/base/plug/plugin.cpp -- Failed to load plugin 'hdMoonray': libusd_usdImaging.so: cannot open shared object file: No such file or directory in '/home/cjhosken/org/dreamworks/openmoonray/plugin/hdMoonray.so'

6

This is getting into pretty tricky build issues, which I don’t have time to help much more with. But maybe someone else does if the following advice does not help.

  • Blender uses a monolithic USD build with everything in a single libusd_ms.so, instead of a multiple smaller libraries like libusd_usdImaging.so. You may need to link against a USD build that is monolithic.
  • However I’m not sure that any Hydra plugin actually needs to be linked against specific USD shared libraries, whose name might not match, but rather it can lookup symbols that have already been loaded. For example on macOS there is -undefined dynamic_lookup to achieve that.
  • It’s possible to link specifically against Blender’s precompiled USD libraries. That’s one way to ensure things are compatible. For the Cycles Hydra plugin in Houdini for example, we also link against the Houdini USD libraries.