Moonray macOS: update build compatibility for Houdini 21.0.680

[rolledhand]

Compatibility:

build (Houdini 21.0.680, macOS Tahoe, Xcode 26.0.1)

Issues/Tickets:

• Discussion: Houdini 21 compatibility #222

Release notes comment:

Adds macOS compatibility updates required to build OpenMoonRay against Houdini 21.0.680 using Houdini-provided USD/PXR and Python 3.11, including Boost 1.82 alignment and Houdini USD library naming compatibility updates.

Comments for the reviewer:

• Scope is Houdini 21.0.680 compatibility on macOS.
• Tested environment:
  • macOS Tahoe
  • Xcode 26.0.1
  • Houdini 21.0.680
• Built dependencies in Houdini mode with -DNO_USD=1 to avoid local USD conflicts.
• Validation outcome:
  • dependency build succeeds
  • main project configure/build succeeds
  • install succeeds
  • MoonRay appears as a selectable renderer in the Solaris viewport
• Main compatibility changes in this PR:
  • Houdini 21.0.680 path updates
  • Houdini-owned USD/PXR pathing updates
  • Python 3.11 include/lib updates
  • PXR metadata updates for Houdini 21 / USD 25.05
  • Boost 1.82 alignment for this toolchain path
  • Houdini USD library naming compatibility fix:
    libpxr_usdRiImaging.dylib -> libpxr_usdRiPxrImaging.dylib
• Important note:
  • In this tested setup, using libhboost_python311-mt-a64.dylib did not resolve all expected pxr_boost::python references during link, while libpxr_python.dylib did.
• Compatibility notes doc:
  • https://github.com/rolledhand/openmoonray/blob/Moonray-Houdini21-macOS/docs/Houdini21_macOS_changes.md
• Related background discussion:
  • Houdini 21 compatibility #222
• Related cmake_modules branch:
  • https://github.com/rolledhand/cmake_modules/tree/boost-1.82-macro-update
• Related cmake_modules compare:
  • https://github.com/dreamworksanimation/cmake_modules/compare/main...rolledhand:boost-1.82-macro-update?expand=1

Look or scene setup change:

No intended look change; this PR is compatibility, pathing, and build integration focused.

Special notes for production:

• Tested target in this branch: Houdini 21.0.680 on macOS Tahoe with Xcode 26.0.1.
• Production Houdini 21.0.679 has not been validated in this branch.
• SideFX Xcode compilation note was used only as sanity context; direct relevance to OpenMoonRay-specific build/runtime behavior remains uncertain.
• SideFX sanity reference:
  • https://www.sidefx.com/changelog/?categories=52&journal=17.5&show_versions=on
• Separate Houdini shader/HDA UX issues are not addressed by this PR.

Attention/Reviewers:

dreamworksanimation/openmoonray-maintainers

Checklist:

• Documentation has been updated.
• Includes new unit tests.
• Includes new RATS tests.

[rolledhand]

Tested on production build of Houdini 21.0.671, works there as well.

[randypacker]

Thanks for the update and PR contribution! We'll take a look at it soon. In the meantime, could you please send over a CLA to moonray@dreamworks.com, so that's cleared?

[rolledhand]

Hi @randypacker - just sent the CLA. Also tried to update to the latest release. I'd like to help even more and get things working, but this is as far as I'm currently capable of taking it. Hope that some of it helps at least slightly, even as an initial kick-off.

As a quick summary of what works and what doesn't. It builds and renders, lights work but when it comes to the native DWA materials they still don't take any effect at all, although the mtlx standard surface seems to be working for some material traits.

Dome light doesn't work when I tried to add one myself (worked on one of the "Solaris" demos), same case for motion blur from one of the demos, tweaking light parameters e.g. spread doesn't automatically update the IPR - normalize has an unpleasing effect, render settings started working with the latest release. I'm attaching my testing images.

H21 seems to require libpxr_usdRiPxrImaging.dylib instead of libpxr_usdRiImaging.dylib. Docs:
https://www.sidefx.com/docs/hdk/pxr_2usd_imaging_2usd_ri_pxr_imaging_2tokens_8h.html

There have been some issues with https://github.com/log4cplus/log4cplus when I was trying to install/build, hence the change there.

Additionally what I was attempting as a bit of a workaround was getting "DWA materials linked to mtlx native ones" as a bit of a workaround on the older release. Managed to get basic mtlx image working without tiling, but it goes way too deep for me at my current stage. I've got that one in another fork which was "forcing it" through Materials.cc in hydraMoonray.

[rolledhand]

Sorry for the duplicate images of cornell box and the "motion blur/noise sampler" demos.

[kubo-von]

The DomeLight not working will be probably caused by the fact that since some USD version, dome lights have DomeLight_1 as a type.

[matthewlow-dwa]

/dco

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: rolledhand / name: Jakub Svoboda (1a299f5, 4b9bb50, 9ee53f2, cc25a18, e43cc0b)

[rolledhand]

Everything signed off now @matthewlow-dwa , I've already sent some signed CLA on mail, but signed some "EasyCLA" in here as well.

[matthewlow-dwa]

Thanks @rolledhand ! We are in the middle of transferring to a new CLA management system, so thanks for re-signing in EasyCLA, as we are unable to transfer prior signatures sent via email. EasyCLA will be the system to use going forward.

[rolledhand]

You're welcome, hope this PR helps at least slightly, even as a kick-off version. I'm calling it a "Houdini launches with it and you can render state" with a couple of things which I mentioned earlier which aren't working.

Additionally here's one more of my attempts to get mtlx working - the tiling still didn't work (besides the commit name as I had it on Karma IPR by a mistake):
OpenMoonRay/hdMoonray@2a52294

But it was rather in general a bit "hacky" workaround by translating the native mtlx nodes into the native Moonray ones, not a true mtlx implementation, but I managed to get a non-tiled albedo to work. Not sure if it might help you in any way.

[rolledhand]

A quick and short summary, still in build/test mode, especially hdMoonRay is not the cleanest yet. I am trying to establish a working base first. Most of the visible Houdini/Solaris UI changes with screenshots are in moonray_dcc_plugins.

So far:

• exposed native MoonRay nodes in USD MaterialX subnet contexts. This can be deleted in the future, but it is useful for now.
• fixed iridescence_interpolations token -> IntVector conversion, which kept popping up in terminal.
• made DomeLight work and exposed MoonRay parameters in the tab.
• created a dedicated moonraymaterialbuilder subnetwork in Material Library.
• added the DWA/MoonRay icon to the builder. This can be changed later if you have any dedicated ones.
• cleaned the default material node layout so it is non-overlapping, can be tweaked later.
• confirmed the material builder authors proper MoonRay surface/displacement outputs and renders.

Built for Houdini 20.5 / Python 3.11 so far. I plan to bump to Houdini 21 after making the H20.5 path stable first.

Next steps before the H21 bump:

• expose MoonRay render geometry settings, especially subdivision/adaptive tessellation parameters.
• get SpotLight working and aligned with the Solaris authoring approach.
• get AOVs working and establish an artist-friendly node for them.
• try to create a dedicated MoonRay ROP node similar to Karma/Arnold/RenderMan and align output aspects like resolution along with it.
• get light filters working.
  -update OCIO version and make sure that the husk config gets read, faced an IPR/exr comp mismatch when I was trying to render but I had tweaked 2.0 config, will have to dive a bit deeper

During this build I had some issues around the light filter / mesh light adapter path. The problematic parts were mainly MoonrayLightFilterAdapter and MoonrayMeshLightAdapter. They pulled in Houdini USD imaging headers and hit the same Houdini 20.5 USD 24 + Xcode 26 SdfChildrenProxy compile issue, so they currently go through the local compatibility workaround.

So I would treat light filters and mesh lights as a later dedicated pass:
visible Houdini UI -> valid USD light filter prims/relationships -> hdMoonRay adapter consumes them -> MoonRay LightFilter objects are created -> lights attach them correctly -> RDL/render proves it.