Moonray for Houdini

[dagoose75]

Hi everyone,

Congrats to the release of moonray to the public !!!

I wonder if someone could do a howto get moonray to work with houdini.
I saw thet is already some stuff here:
https://github.com/dreamworksanimation/moonray_dcc_plugins

I guess I still have to compile the renderer?
Well just getting started ... hopefully some 'real wizard' is going to chip in.

Cheers

[kjeffery]

Hi @dagoose75 !

You will need to compile MoonRay.

Interaction within Houdini will be done through the Hydra interface (the source code for which we also supply). The link you provided contains enhancements to LOPs to provide MoonRay shaders so that MoonRay-specific attributes are accessible. Without the LOPs plugins, you would be limited to the UsdPreviewSurface material.

[nospitters]

hi, cant get moonray show up in houdini 19.5 as described here...
#48

maybe there is a more detailed setup/install instructions on how to get it work in solaris?

[kjeffery]

I will see if we have documentation on this.

[mpjohn]

Hi All,
After a bit of trouble I now have both Moonray and Houdini working on Rocky Linux9.
Can anyone give me some advice on how to get the Moonray plugin for Houdini to work? I'm a Houdini noob.

Thanks
M

[mpjohn]

Hi there,

I'm a Houdini noob. I followed the setup instructions. It took me a while to find the Dwa base shader then I hooked it up to a collect node.
I don't seem to be able to access the parameters easily though. Am I just missing something silly like the attribute editor in Maya or do you have to hook up nodes to each and every parameter you want to tweak?

Thanks in advance for any help on this!

[BrianHanke]

Just click on DwaBaseMaterial1, you've got collect1 selected now. But you're currently in /obj context so MoonRay won't work there anyway. You need to use Solaris. Click the menu at the top where it says Build and select Solaris.

[mpjohn]

Thanks Brian. I've gone into Solaris but then the sphere I was trying to assign the Dwa shader to disappears.
In Solaris I still haven't found any tweakable parameters in the shader.
I hoped it might be possible to assign a Dwa base shader to a sphere and tweak parameters on that...but it's not so easy :/

[mpjohn]

I can see I have a TON to learn here. But just to make sure....do I need to manually add a node to each parameter I want to tweak. Say the diffuse color...that's not automatic ?...I need to dig in there for each attribute? Thanks!

[BrianHanke]

First thing's first, click on Persp there in the viewport. Is MoonRay listed in the dropdown? If it is, what happens when you click on it?

[mpjohn]

Hi Brian,
Moonray isn't listed. Dang! Does that mean I've done something wrong? I've done what the docs said about he env variable but I've also copied the files over.

Thanks!
M

[mpjohn]

But I can see all the nodes nonetheless....

[mpjohn]

I did get an error message though...

xdg-open: no method available for opening 'http://mydw.anim.dreamworks.com/display/GSHADERS/Moonshine+-+Shaders+and+Procedurals+for+Moonray?path=/mat/DwaBaseMaterial1'
5110: Fatal error: Segmentation fault (sent by pid 115)

[BrianHanke]

Hi Brian, Moonray isn't listed. Dang! Does that mean I've done something wrong? I've done what the docs said about he env variable but I've also copied the files over.

Thanks! M

I haven't been following the convo before this so I'm not sure what build process you used. But MoonRay needs to be built against Houdini's libraries in order to work in Solaris.

Houdini is able to see the MoonRay assets but, as you've noticed, the parameters are all empty since MoonRay isn't actually loaded.

I haven't touched MR in a long time, but I did write a build guide for CentOS 7 and Houdini 19.5. Things may be quite different now though. I'm not even sure it will build with Houdini 20 at all. BrianHanke#3

[mpjohn]

Thanks Brian. That's super helpful. Just so I'm clear about rebuilding Moonray...Building against means having Houdini installed before running through the build? New to all this. It's not for the faint hearted is it?!

[BrianHanke]

It sure isn't! Definitely one of the most frustrating/annoying/complicated builds I've ever done. I'm not a pro dev by any means so that may not be saying much.

The idea is that MoonRay comes with its own libraries by default, but in order to work with Houdini it needs to use Houdini's versions of those same libraries. So, you have to point the MoonRay build process to your Houdini installation. It's not that simple, but that's the general idea.

[mpjohn]

Yikes. I thought I was through the trees on this but that sounds pretty difficult.
Great information though...thanks!

[BrianHanke]

You've done great to get this far, you're at the final boss now. That guide is all I know on the topic, hopefully it's still at least a bit relevant even though MR and Houdini have been updated in the meantime. Good luck!

[mpjohn]

Ha Ha great analogy. Thanks Brian. I hope I do get there. It makes me wonder how on Earth you figured all this stuff out yourself?!

[mpjohn]

[jlanz]

Can you provide more information? Which build step were you on when you got this? What are your environment variables? Is there a CMakeCache.txt file you can share?

[mpjohn]

[mpjohn]

I found this referecne to a bug online...
https://bugs.gentoo.org/821217

But how do I get past this issue I wonder?

[mpjohn]

I suspect I may need to reinstall everything from scratch to get this working.
Is there a version of Houdini that's recommended to work with Moonray on Rocky 9?

The cruel thing is when I first open Solaris Moonray appears as an option but quickly disappears... never to reappear until I restart Houdini again.

[BrianHanke]

I don't recall any segfaults when I was doing this. I remember the first thing I did to test the build was put a single cube in the Solaris scene and switch to MoonRay. It should render identical to Karma. If that works then all should be good. If not, there's a problem with the build or with environment variables.

[mpjohn]

I've restarted the build in case I missed some steps ( building against Houdini ). I've run into this issue...which has me stumped.
Any ideas how to fix this? In the cmake/source section it's finding the optix headers ?

[ 1%] Building CUDA object moonray/moonray/lib/rendering/rt/CMakeFiles/rendering_rt_optix.dir/gpu/optix/OptixGPUPrograms.ptx
[ 1%] Built target map_primvar_objlib_make_dir
[ 1%] Built target CombineDisplacement_make_build_dir
[ 1%] Built target NormalDisplacement_make_build_dir
In file included from /usr/local/include/optix_device.h:43,
from /usr/local/include/optix.h:41,
from /source/moonray/moonray/lib/rendering/rt/gpu/optix/OptixGPUMath.h:8,
from /source/moonray/moonray/lib/rendering/rt/gpu/optix/OptixGPUPrograms.cu:5:
/usr/local/include/optix_7_device.h:1008:10: fatal error: internal/optix_7_device_impl.h: No such file or directory
1008 | #include "internal/optix_7_device_impl.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake[2]: *** [moonray/moonray/lib/rendering/rt/CMakeFiles/rendering_rt_optix.dir/build.make:76: moonray/moonray/lib/rendering/rt/CMakeFiles/rendering_rt_optix.dir/gpu/optix/OptixGPUPrograms.ptx] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:12212: moonray/moonray/lib/rendering/rt/CMakeFiles/rendering_rt_optix.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

[mpjohn]

So I started the process again and rebuilt Moonray without errors while pointing to the Houdini install and pxr-houdini folders as per Brian's instructions.

Unfortunately in Solaris while Moonray is active showing any kind of geometry causes a crash.

Does this error message from Houdini suggest a python mismatch? And if so should I update to python 3.7. I'm clutching at straws here :/

File "/opt/hfs19.5/python/lib/python3.7/importlib/init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
SystemError: initialization of _tf raised unreported exception

[BrianHanke]

@mpjohn If you're using Houdini 19.5, it comes in two flavors: Python 3.9 or 3.7. Houdini 20 is 3.10 or 3.9 I think. I don't recall which version I used when building on CentOS, but I do remember that I had to install a different version and set it as the default. I assume it needs to match the Houdini Python.

[mpjohn]

I've build the latest Moonray ( 1.5.0.0 ) on Rocky Linux. So far so good.

Now I've been trying to get it to work with Houdini for quite a while with no luck. I hoped the new version might work better.
So far I've tried with the python 3.9 and python 3.10 versions of Houdini 20 with similar results.

I've edited the houdini env file and the shaders appear in Houdini. I've also run the post build run once shader setup...
/installs/openmoonray/bin/rdl2_json_exporter --out /installs/openmoonray/shader_json/ --sparse

Moonray appears in Solaris...until I try to render with it at which point the following 2 errors pop into the log.....

Plugin HdMoonrayRendererPlugin is missing TfType registration
No renderer plugins found! Check before creation.

Can anyone help me out please? I'm hoping it's some small thing I've done wrong...but even if it's a big thing...can you point me in the right direction?!!

I have a hunch that Houdini packages could help but I've tried that it's not straight forward.

Is this a question of the conflicking pxr packages between Moonray's version and Houdini's?

I have installed rez - maybe that's the answer?!

Any suggestions would be greatly appreciated.

One other question...with the moonrayDCC plugins. Do I have to clone that? Or can I just use the folder from the installed Moonray directory?

[mpjohn]

One other error I forgot to mention...

[PluginDiscover] A prim adapter for primType 'GeometryLight' already exists! Overriding prim adapters at runtime is not supported. The last discovered adapter (UsdImagingGeometryLightAdapter) will be used. The previously discovered adapter (GeometryLightAdapter) will be discarded.

[mpjohn]

Now I know, and have previously tried, to build Moonray "against" Houdini.
There must be a better way....surely?!

[mpjohn]

Building against Houdini

If I understand things correctly then there are 2 reasons we have to build Moonray against Houdini...

(i) The python versions are slightly different
(ii) The Pixar USD versions are different

What I've found is that when you follow the current unofficial instructions that pxrConfig.cmake in usr/local is a key file.

By default it's 2.4kB but the edited "Houdini" version is smaller at around 1.8kB. If you swap the file before the build it won't work.

I know you can later use symlinks to direct the build to the correct versions of the usd files but there must be an easier way.

Surely someone out there can write out all the steps to make this work. I know it isn't easy. I've tried several times.

But maybe it's time to prioritise this so that people can actually start using Moonray?

[mpjohn]

I've rebuilt Moonray against Houdini v20.0.625 - Py3.9 ( was that the best version to try?! )
The build all went fine / no errors ( suspicious!? )
I can see Moonray in Houdini but when I turn it on in Solaris I get three errors and moonray disappears...
The errors are...

[PluginDiscover] A prim adapter for primType 'GeometryLight' already exists! Overriding prim adapters at runtime is not supported. The last discovered adapter (UsdImagingGeometryLightAdapter) will be used. The previously discovered adapter (GeometryLightAdapter) will be discarded.

Plugin HdMoonrayRendererPlugin is missing TfType registration

No renderer plugins found! Check before creation.

My hope is that because I'm a Houdini noob that I've done something wrong in loading the plugin.
I'm also finding that if I call Houdini from the command line it doesn't find the Dreamworks shaders but if I call it from the symlink then it does.

I would love to be able to get this working before I retire :/
Any advice at all would be much appreciated.

[mpjohn]

Here's a crazy idea. What if there were 2 versions of the source for Moonray. One for the standard build and one which uses the SideFX version of USD. Would that fix things so that people could start to use it without problems with a particular version of Houdini?

https://github.com/sideeffects/USD

Not sure how to do this of course because I'm not a developer.

[mpjohn]

Can anyone help me out with these errors....These are after I swapped out the pxrConfig.cmake etc and set up sim links to Houdini's versions of the usd files....Hard to know if I'm close or a million miles away from getting this to work :/

CMake Error in moonray/hydra/hdMoonray/src/CMakeLists.txt:
Imported target "hd" includes non-existent path

"/include"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

CMake Warning at moonray/hydra/hdMoonray/src/CMakeLists.txt:11 (add_library):
Cannot generate a safe runtime search path for target hdMoonray because
files in some directories may conflict with libraries in implicit
directories:

runtime library [libosdCPU.so] in /lib may be hidden by files in:
  /usr/local/lib
runtime library [libosdGPU.so] in /lib may be hidden by files in:
  /usr/local/lib

Some of these libraries may not be found correctly.

CMake Error in moonray/hydra/hdMoonray/src/adapters/CMakeLists.txt:
Imported target "usdImaging" includes non-existent path

"/include"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

CMake Error in moonray/hydra/hdMoonray/cmd/hd_cmd/hd_render/CMakeLists.txt:
Imported target "gf" includes non-existent path

"/include/python3.6m"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

CMake Error in moonray/hydra/hdMoonray/cmd/hd_cmd/hd_usd2rdl/CMakeLists.txt:
Imported target "gf" includes non-existent path

"/include/python3.6m"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

CMake Error in moonray/hydra/moonray_sdr_plugins/moonrayShaderDiscovery/CMakeLists.txt:
Imported target "ar" includes non-existent path

"/include"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

CMake Error in moonray/hydra/moonray_sdr_plugins/moonrayShaderParser/CMakeLists.txt:
Imported target "ar" includes non-existent path

"/include"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

CMake Error in moonray/moonshine_usd/lib/geometry/usd/CMakeLists.txt:
Imported target "usd" includes non-existent path

"/include"

in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

• The path was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and references files it does not
  provide.

[mpjohn]

I got rid of all the errors apart from this one by tweaking the pxrTargets.cmake file...anyone know how to fix this?

CMake Warning at moonray/hydra/hdMoonray/src/CMakeLists.txt:11 (add_library):
Cannot generate a safe runtime search path for target hdMoonray because
files in some directories may conflict with libraries in implicit
directories:

runtime library [libosdCPU.so] in /lib may be hidden by files in:
  /usr/local/lib
runtime library [libosdGPU.so] in /lib may be hidden by files in:
  /usr/local/lib

Some of these libraries may not be found correctly.

[mpjohn]

gmake[2]: *** No rule to make target '/lib/libpython3.6m.so', needed by 'moonray/hydra/moonray_sdr_plugins/moonrayShaderParser/moonrayShaderParser.so'. Stop.

[rgwilson68]

Hi,

I'm sorry that you are having so many issues building Moonray for Houdini. It is definitely possible, but there are quite a few things that can throw it off in difficult-to-diagnose ways. Unfortunately it is very hard for me to tell exactly what is going wrong based on the error messages, but I can provide a few suggestions:

I'd recommend using Rocky 9, and Houdini 19.5 with Python 3.9. We haven't tested building for Houdini 20.

Moonray has to build with the same version of all libraries that it shares with Houdini. The libraries built by the Rocky 9 process should match Houdini 19.5. If there's any doubt, then /building/Rocky9/CMakeLists.txt shows the version of each package that Moonray uses. The file toolkit/third_party_libraries.json should list the versions of libraries that Houdini uses. You can compare the two to check for mismatches. To build for a different version of Houdini, like 20, you may need to update the versions in the Moonray build.

Incompatible libraries may cause link errors, but may also just manifest as random crashes when using the app.

In theory you could build against the actual libraries shipped with Houdini, rather than just trying to match versions. These are in dsolib and toolkit/include under the Houdini install. However Houdini does not come with a vanilla set of CMake configs for these libraries : toolkit/cmake/HoudiniConfig.cmake exists but will not be found or understood by Moonray's cmake.

To get the correct version of SideFx's custom built USD, you need to use the repository at https://github.com/sideeffects/USD instead of https://github.com/PixarAnimationStudios/USD. You need to identify the right commit tag for the version of Houdini and USD, which should be shown in the github web interface. Replace the GIT_REPOSITORY and GIT_TAG fields in building/Rocky9/CMakeLists.txt (last section, for USD) before doing the dependency build.

I provided a pxrConfig.cmake file for BrianHanke which should let you use the copy of USD distributed with Houdini. However, this is a bit of a hack : since USD seems to be causing problems, I'd suggest the above process of downloading from the SideFx site -- see if that works better. If you do use my hacked pxrConfig.cmake, make sure the env vars listed in README.txt are set up correctly.

It shouldn't be necessary to do any symlinking to get the build working with USD : doing this might just partially fix the problem so the build process gets further but is ultimately broken. If the configs are set correctly, CMake should find the files where they are. I don't really understand why BrianHanke needed to symlink a bunch of libraries to get the plugin working : it seemed to work for him, but I'd be worried that it is covering up a deeper problem with the build. I'd need to know more about the system to understand what's going on here.

Pre-existing installs of any of the dependencies could cause problems. The warnings like "runtime library [libosdCPU.so] in /lib may be hidden by files in: /usr/local/lib" are not ones I have encountered before, but sound like somehow libraries are installed twice in two different places. Again, there may be ways to work around this, but it is probably important to understand where the double installs are coming from. Mixing the Centos-7 and Rocky 9 processes could possibly cause this problem. A double install of USD caused by previously building Moonray with the default (non-Houdini) setup could cause problems : I would check there are no versions of USD left over from previous installs on the machine.

"[PluginDiscover] A prim adapter for primType 'GeometryLight' already exists! ..." is a known issue that should not cause serious issues.

"Plugin HdMoonrayRendererPlugin is missing TfType registration" sounds like either PXR_PLUGINPATH_NAME is not set correctly to include the path to hdMoonray.so, or that something is badly wrong with the USD installation (hard to tell which)

"No rule to make target '/lib/libpython3.6m.so', needed by..." seems quite strange in a Rocky 9 build. The Centos-7 build is configured to use python-3.6 by default, but I can't think of a reason a Rocky 9 build would try to use it.

[rgwilson68]

What do you see if you run
nm /usr/local/lib/libusd_arch.so | fgrep malloc
?

[mpjohn]

Hi Rob,

I've reinstalled Rocky 9 to make sure there's no conflict with older versions of installs. I've got the right GIT_TAG for houdini19.5.613. I build the dependencies without any issue.
Unfortunately I'm getting the exact same error...

[ 22%] Built target common_grid_util
[ 22%] Linking CXX executable hd_render
/bin/ld: /usr/local/lib/libusd_arch.so: undefined reference to __malloc_hook' /bin/ld: /usr/local/lib/libusd_arch.so: undefined reference to __memalign_hook'
/bin/ld: /usr/local/lib/libusd_arch.so: undefined reference to __free_hook' /bin/ld: /usr/local/lib/libusd_arch.so: undefined reference to __realloc_hook'
collect2: error: ld returned 1 exit status
gmake[2]: *** [moonray/hydra/hdMoonray/cmd/hd_cmd/hd_render/CMakeFiles/hd_render.dir/build.make:239: moonray/hydra/hdMoonray/cmd/hd_cmd/hd_render/hd_render] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:10694: moonray/hydra/hdMoonray/cmd/hd_cmd/hd_render/CMakeFiles/hd_render.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

When I run the command you suggested I get the following...

             U malloc@GLIBC_2.2.5
             U __malloc_hook

000000000002f500 T _ZN32pxrInternal_v0_22__pxrReserved__20ArchIsJemallocActiveEv
0000000000013b7e t _ZN32pxrInternal_v0_22__pxrReserved__20ArchIsJemallocActiveEv.cold
000000000002f360 T _ZN32pxrInternal_v0_22__pxrReserved__20ArchIsPtmallocActiveEv
0000000000013b5e t _ZN32pxrInternal_v0_22__pxrReserved__20ArchIsPtmallocActiveEv.cold
000000000002f1c0 T _ZN32pxrInternal_v0_22__pxrReserved__20ArchIsPxmallocActiveEv
0000000000013b3e t _ZN32pxrInternal_v0_22__pxrReserved__20ArchIsPxmallocActiveEv.cold
[root@localhost ~]#

I thought I finally had it :/

[mpjohn]

One more slightly confusing thing.... The git tags don't seem to correspond exactly with Houdini build numbers.
For instance there is a git tag for refs/tags/houdini19.5.613 but the closest corresponding build number I can find on the SideFX downloads page is 19.5.605 which then jumps to 19.5.640. In other words there isn't a download for houdini 19.5.613 !?

[rgwilson68]

I tried to repeat your build in a Rocky 9 docker container, and got the same problem. I think probably USD version 22.05 just doesn't build correctly on Rocky 9. So I gave you bad advice ; you probably can't build for Houdini 19.5 on Rocky 9 -- sorry about that!

So the options would be Houdini 19.5 on Centos-7 OR Houdini 20 on Rocky 9. I checked the Centos-7 build (in a container), with the USD repo switched to sidefx & tag houdini19.5.613, and Moonray seemed to build properly and run the basic tests. If you want to try this, you'll need to install Centos-7 again (or try docker...) and then just follow the instructions in building/Centos-7. Before running the build, modify CMakeLists.txt to switch to the sidefx repo as before. You should be able to get the basic tests at the end of the document to work. Then we can try running in Houdini : if there are issues, it will be likely be because of some incompatible library I didn't spot, but we may be able to figure out what that is...

Alternatively, to try building for Houdini 20 on Rocky 9, follow the same procedure but use the appropriate sidefx tag. I think you will need to make the patches to support USD 23.08 and python 3.10 that adro79 lists in his guide:

adro79#2

I will try to add USD 23.08 / Python 10 support to the main repo, possibly in the next release, so you could also wait for that. I will also try to verify that the houdini 20 build works before this release goes out.

[mpjohn]

Thanks for looking into that. I'm definitely in favour of your idea to verify which version of Houdini works with which build going forwards. That could save a lot of time and frustration for end users such as myself.

[BrianHanke]

@mpjohn Did you see this build guide? Might be helpful. adro79#2

[mpjohn]

Thanks Brian... I'll check that out.

[nicolaspopravka]

Hi everyone,

I've been working on getting Moonray reliably built for Houdini over the past few days, and I'm beginning to doubt it's currently feasible with CMake. SideFX's fork of USD is made to work with their custom version of Boost for Houdini, where all the symbols are namespaced under hboost instead of boost. However, Moonray also depends on Boost and expects the boost namespace, as you would expect.

I don't see a clear way to reconcile these differences without significant changes to the CMake files. While it's possible to achieve a successful build by following some of the suggestions made earlier in this conversation, it might technically work—but it'll be fundamentally flawed, and you're likely to encounter issues sooner or later.

I'm curious to know how DWA is internally building Moonray for Houdini. It seems like it must be a work in progress and not yet ready for production use.

[rgwilson68]

Hi,
I think the idea is that a Houdini plugin, like HdMoonray, can use the regular distribution of boost, via the "boost" namespace, without clashing with Houdini's use (via "hboost"). So you would build USD against the SideFX boost variant, but build Moonray itself against a regular boost build. They are effectively treated as completely different libraries, because the library names and internal symbols are different across the two.

Internally we use Moonray with Houdini in production, but we use our own fork of USD because we have to support multiple different apps.

[nicolaspopravka]

Great to hear that HdMoonray is in use internally! Hopefully, I can get the CMake setup sorted out soon.

How do you rebuild USD against the non-standard HBoost library ? SideFX’s fork seems to expect the standard boost namespace, and there is no documentation on how they manage this with their hboost variant. However, I noticed that Houdini includes a HoudiniConfig.cmake file, which appears to be used by at least one other Hydra plugin. Given that, it might be possible to avoid rebuilding USD entirely and instead focus on building HdMoonray against the version of USD that Houdini ships with.

I agree that Boost shouldn’t pose a problem, provided the CMake files are correctly set up.

[rgwilson68]

Sorry, my mistake, if SideFX fork seems to expect standard boost that is probably the right way to build it.
Yes, you should also be able to build Moonray against the built version of USD that comes with Houdini. The problem is getting CMake configured to use it. Using HoudiniConfig.cmake might work, but I haven't tried it yet.

[mpjohn]

I've built Moonray several times. I've never been able to get it to work properly with Houdini or any other DCC app.
I'm not touching it again until there are proper build instructions at the end of which you have a version which works with a DCC app.
Without these build instructions it's as useful to me as a chocolate teapot.