openmoonray: Conflict with Houdini USD and MoonRay USD?
I’m splitting this off from our previous discussion since I’ve narrowed down the problem a lot.
System info: CentOS 7, MoonRay compiled using default settings from build guide, using Python 3.9.10 to match Houdini, Houdini FX 19.5.534.
See attached video. First is a quick test of moonray_gui to confirm the renderer is working. Then, launching usdview from hython, Karma works but as you can see MoonRay throws a ton of errors about “multiple debug symbol” and “already defined C++ type.”
It looks to me (as a non-coder) like the system is trying to load both MoonRay and Houdini USD libraries? Any ideas how to resolve this?
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 15 (3 by maintainers)
IT WORKS!!!
@nospitters Definitely. I’m working on a guide right now, will probably be ready this weekend. Check out my GitHub to stay updated.
No, dwa-environment is only used by internal dwa builds, so you don’t need to change it.
There are a couple of possible solutions. You should be able to get USD from the sidefx repo (https://github.com/sideeffects/USD) instead of pxr by changing the location in the dependency CMake project. You’ll have to change the git tag, but you can use symbolic tags like ‘v22.05a’ – there also seem to be tags for some specific Houdini versions on that repo.
Another way, that is more involved, is to use the USD libs and headers shipped with Houdini. To do this, you need a pxrConfig.cmake that targets these. I’ve uploaded a tar file with a modified set of config files and a README to: https://docs.openmoonray.org/assets/build_extras/moonray_houdini_pxr_config.tar – I think you should be able to access this. You’ll have to modify the CMake preset used to build MoonRay itself to get this working.
Yes indeed, that’s my conclusion too. I tried one more test, symlinking all the Houdini libraries before the final MR build step. No library errors when doing that, but I started getting syntax/API problems.
SideFX recommended that I build against the Houdini USD libraries and the professional coders I’ve talked to agree. It’s obviously a big task and above my skill level. Not much to do until DreamWorks throws us a bone…
@BrianHanke the
makes me think of an API mismatch between libraries.
My first suggestion would be to look at which version of USD Houdini is using. For example, 19.5 is on 22.05: https://www.sidefx.com/docs/houdini/licenses/index.html . Then, check if moonray is using the same version. According to https://github.com/dreamworksanimation/openmoonray/blob/9b629e0999bfe2394ad56d31c3314c5199c4db3c/building/CMakeLists.txt#L205, Moonray is also targeting 22.05.
In that case, I think that it would be good to have a dedicated guide on how to build Moonray as a DCC plugin, since in that scenario it would be safer/easier to rely on the USD and OCIO offered by the DCC, instead of having the build script compile and link to a different USD. As long as openmoonray and the DCC are on the same VFX reference platform year, most of the versions of these big libraries should be in line (even though sadly that beast of USD isn’t yet on the VFX ref platform, afaik…)
Made some progress by symlinking all the “libusd” libraries to the “libpxr” ones that come with Houdini. That eliminated 99% of the errors. Still not working though. Now we’re left with:
Honestly this is all kind of bananas. Is there anybody at DreamWorks who could lend a helping hand? I don’t think this should be this complicated and I feel like we’re all flying blind out here. Thanks!