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.
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
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
3 Likes
It seems the website doesn’t like me copy and pasting the full error message, but here’s a screenshot of the full warning.
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.
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'
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 likelibusd_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_lookupto 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.
Hello again!
I’ve written a successful .rdla/.rdlb exporter from blender (using USD as a mediator), so you can (sort of) render your blender projects in MoonRay. You just have to run the external moonray_gui script for it to work.
I’ve hit a roadblock with linking USD. So until that get’s sorted I can’t develop the tool any further. If someone who knows more about monolithic building and linking libraries could get in touch, that would be awesome.
Theres also shell script that should automatically build MoonRay on RHEL9 into ~/.mfb. If anyone wants to play around with it, feel free to give it a go.
2 Likes
Linked some pretty pictures 
The kitchen set was imported into blender using USD, then exported out as a .rdla,
The lounge set is the blender 4.1 splash screen. It seems that Moonray needs “tiled” (.tx) images, which Blender doesn’t generate.
Still lots of work needed to get exporting to work correctly, but It’s getting there.
Would love to get the renderer to work inside of Blender though, hopefully a solution will be found soon.
11 Likes
Do we need a custom build of MoonRay to use the add-on?
Ay the moment you can run the addon using the standard installation of moonray. (Or without moonray at all, but youll just have a functionless UI)
chances are I probably will have to develop a custom build, however I havent looked into that yet.
If youre installing moonray yourself, you need to build it as ~/.mfb/installs/openmoonray
Just want to remind you that the only thing working in blender is the export tool, theres no interactive render view yet, youll need to use the moonray_gui command.
1 Like
Ask away, no guarantees though
1 Like
Awesome! Thanks for helping
From what Ive gotten from brecht (in his message from June 25), I know im somehow supposed to link blenders monolothic USD build to Moonray. When am I supposed to do this? In the build process? Will i need to adjust the moonray code to work with a monolithic USD build?
Currently, Moonray is using Cmake for building and it I have it building USD into ~/.mfb/dependencies.
I don’t know moonray all that well, but i’d likely start by pointing moonray to the blender copy of USD rather than whatever is in ~/.mfb/dependencies and see what shakes out.
1 Like
So I tested building moonray as monolothic. The monoloithic build compiles successfully, but when I try building Moonray…
In file included from /usr/include/boost/python/detail/prefix.hpp:13,
from /usr/include/boost/python/dict.hpp:8,
from /usr/local/include/pxr/base/tf/scriptModuleLoader.h:38,
from /home/hoske/.mfb/source/moonray/hydra/moonray_sdr_plugins/moonrayShaderDiscovery/moduleDeps.cpp:6:
/usr/include/boost/python/detail/wrap_python.hpp:57:11: fatal error: pyconfig.h: No such file or directory
57 | # include <pyconfig.h>
| ^~~~~~~~~~~~
compilation terminated.
gmake[2]: *** [moonray/hydra/moonray_sdr_plugins/moonrayShaderDiscovery/CMakeFiles/moonrayShaderDiscovery.dir/build.make:90: moonray/hydra/moonray_sdr_plugins/moonrayShaderDiscovery/CMakeFiles/moonrayShaderDiscovery.dir/moduleDeps.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs…
[ 1%] Building CXX object arras/arras4_core/arras4_network/lib/network/CMakeFiles/network.dir/InetSocketPeer.cc.o
In file included from /usr/local/include/pxr/base/tf/pySafePython.h:44,
from /usr/local/include/pxr/base/tf/pyLock.h:31,
from /usr/local/include/pxr/usd/ar/resolverContext.h:40,
from /usr/local/include/pxr/usd/ar/resolver.h:33,
from /home/hoske/.mfb/source/moonray/hydra/moonray_sdr_plugins/moonrayShaderDiscovery/discoveryPlugin.cpp:12:
/usr/include/boost/python/detail/wrap_python.hpp:57:11: fatal error: pyconfig.h: No such file or directory
57 | # include <pyconfig.h>
| ^~~~~~~~~~~~
compilation terminated.
/usr/bin/ld: cannot find -lusdImaging
CMake Error at arras/arras4_core/arras4_computation_api/lib/computation_api/cmake_install.cmake:52 (file):
file INSTALL cannot find
“/home/hoske/.mfb/build/arras/arras4_core/arras4_computation_api/lib/computation_api/libcomputation_api.so”:
No such file or directory.
Call Stack (most recent call first):
arras/arras4_core/arras4_computation_api/lib/cmake_install.cmake:47 (include)
arras/arras4_core/arras4_computation_api/cmake_install.cmake:47 (include)
arras/arras4_core/cmake_install.cmake:52 (include)
arras/cmake_install.cmake:47 (include)
cmake_install.cmake:47 (include)
It can’t find python, you’ll likely have to nudge it to the right folders
When I use -DPYTHON_EXECUTABLE, -DPYTHON_INCLUDE_DIRS, etc. it says they’re not used by the project in CMake.
I was able to find a way to link blender’s USD monolithic build instead of building it myself, but I’m still getting the pyconfig.h error.
When linking python, do I need to link the systems python? or blenders? should it matter?
There’s no way to tell what it wants, you’ll have to rummage though their cmake files, see where it finds python and look at whatever module (if any) they use, some projects have some wrapper around it some don’t, beyond looking at the code, you really can’t tell. There’s no magic “just set this var” and it’ll work here, IE in our deps builder the following variations are in use:
-DMATERIALX_PYTHON_EXECUTABLE=...
-DPython3_EXECUTABLE=...
-DPYTHON_EXECUTABLE=...
-DPYBIND11_PYTHON_EXECUTABLE_LAST=...
-DPython_EXECUTABLE=...
Solved the pyconfig issue! had to use the CMakePresets.json alongside hacking into the pxrConfig.cmake to get it to work.
I’m now down to what (feels like) the last major hurdle, getting the monolithic library to link correctly.
# - Configuration file for the pxr project
# Defines the following variables:
# PXR_MAJOR_VERSION - Major version number.
# PXR_MINOR_VERSION - Minor version number.
# PXR_PATCH_VERSION - Patch version number.
# PXR_VERSION - Complete pxr version string.
# PXR_INCLUDE_DIRS - Root include directory for the installed project.
# PXR_LIBRARIES - List of all libraries, by target name.
# PXR_foo_LIBRARY - Absolute path to individual libraries.
# The preprocessor definition PXR_STATIC will be defined if appropriate
get_filename_component(PXR_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
set(PXR_MAJOR_VERSION "0")
set(PXR_MINOR_VERSION "23")
set(PXR_PATCH_VERSION "11")
set(PXR_VERSION "2311")
# Set the root directory for USD
set(USD_ROOT "$ENV{HOME}/programming/blender-git/blender/lib/linux_x64/usd")
set(PYTHON_INCLUDE_DIRS "$ENV{HOME}/programming/blender-git/blender/lib/linux_x64/python/include/python3.11")
# Path to the USD monolithic library
set(PXR_usd_ms_LIBRARY "${USD_ROOT}/lib/libusd_ms.so")
# Set include directories
set(PXR_INCLUDE_DIRS "${USD_ROOT}/include" CACHE PATH "Path to the pxr include directory")
# Initialize PXR_LIBRARIES with the path to the monolithic library
set(PXR_LIBRARIES "${PXR_usd_ms_LIBRARY}")
# If PXR_STATIC is defined, include Windows-specific libraries
if(NOT ON)
if(WIN32)
list(APPEND PXR_LIBRARIES Shlwapi.lib)
list(APPEND PXR_LIBRARIES Dbghelp.lib)
endif()
add_definitions(-DPXR_STATIC)
endif()
# Provide useful information for debugging
message(STATUS "PXR_INCLUDE_DIRS: ${PXR_INCLUDE_DIRS}")
message(STATUS "PXR_LIBRARIES: ${PXR_LIBRARIES}")
include_directories(${PXR_INCLUDE_DIRS})
message(STATUS "PYTHON_INCLUDE_DIRS:" ${PYTHON_INCLUDE_DIRS})
include_directories(${PYTHON_INCLUDE_DIRS})
link_libraries(${PXR_LIBRARIES})
This is the pxrConfig.cmake file (edited with lots of help from ChatGPT). The build gets to about 5% and then gives up throwing a bunch of linking errors.
/usr/bin/ld: cannot find -lar
/usr/bin/ld: cannot find -lndr
/usr/bin/ld: cannot find -lsdr
collect2: error: ld returned 1 exit status
gmake[2]: *** [moonray/hydra/moonray_sdr_plugins/moonrayShaderParser/CMakeFiles/moonrayShaderParser.dir/build.make:113: moonray/hydra/moonray_sdr_plugins/moonrayShaderParser/moonrayShaderParser.so] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:11080: moonray/hydra/moonray_sdr_plugins/moonrayShaderParser/CMakeFiles/moonrayShaderParser.dir/all] Error 2
[ 5%] Linking CXX shared library hdMoonrayAdapters.so
/usr/bin/ld: cannot find -lusdImaging
collect2: error: ld returned 1 exit status
gmake[2]: *** [moonray/hydra/hdMoonray/plugin/adapters/CMakeFiles/hdMoonrayAdapters.dir/build.make:114: moonray/hydra/hdMoonray/plugin/adapters/hdMoonrayAdapters.so] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:10958: moonray/hydra/hdMoonray/plugin/adapters/CMakeFiles/hdMoonrayAdapters.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
I’ve seen on the OpenUSD git repo theres some information about how to properly link the monolithic build. But it’s all setup for target_link_libraries, but i want to use link_libraries.
Not really sure what I need to do here…
Start by asking the question, why is it looking for usdImaging ? Judging by your pxrConfig.cmake it shouldn’t be using it, so who’s telling it to link it? my first stop would likely be your CMakeCache.txt maybe it cached the old non monolithic libs?
1 Like