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.

[rolledhand]

Mesh Tesellation with subdivision controls exposed which include smooth normals as well and working along with the Motion Blur tab.

Render Geo Settings node UI:

Results:

Current issues:

terminal error like this:

__SceneVariables__.target_adaptive_error: cannot convert long long to Float

__SceneVariables__.sample_clamping_value: cannot convert long long to Float

Will be fixing that in the next push.

[rolledhand]

still pre-long long to Float conversion fix

[rolledhand]

long long to Float conversion fixed, it also changed the output/behaviour of bilinear subd, is it a desired/expected result?

[rolledhand]

MoonRay SpotLight checkpoint

I pushed a checkpoint for the MoonRay SpotLight UI/backend path. From now on all UI changes will have images in dcc_plugins PR as a way to create a system between the two.

This is not the final lifecycle cleanup yet, but it is now functionally working.

What changed

One important note first, Solaris has a point-light intent, while MoonRay does not appear to have a native PointLight scene class.

As a temporary design choice the intent remains SphereLight + treatAsPoint, not a fake PointLight which Moonray doesn't natively support. I'm still considering how to handle this aspect, but keeping it as a regular SphereLight for now.

The key change and checkpoint highlight is that it adds a MoonRay native Enable Native MoonRay SpotLight path and tab in the Houdini light UI.

The goal is to keep two paths clear:

1. Standard USD/Solaris ShapingAPI path

   • This is the native Solaris shaping way, but it doesn't expose all the native MoonRay Spotlight parameters
   • Current behavior:
     • SphereLight + ShapingAPI goes through the current backend MoonRay SpotLight path.
     • DiskLight + ShapingAPI goes through the current backend MoonRay SpotLight path.
     • RectLight + ShapingAPI remains RectLight with spread.
   • Barndoor controls, focus, IES will be handled in the light filter pass I'll be delving into later.

2. Explicit MoonRay override path

   • The new MoonRay UI control authors an explicit Moonray native-specific override:

     custom token moonray:class = "SpotLight"
     

   • This is separate from the renderer-neutral USD ShapingAPI path, it turns the intial usdLuxlight type into the native MoonRay Spotlight type e.g. RectLight to Spotlight, this was a design decision I made to simplify this whole aspect and make it more artist friendly.
   • hdMoonRay now accepts this explicit override and resolves it to MoonRay’s native SpotLight.

Current functional state

Validated locally:

• moonray:class = "SpotLight" now validates against MoonRay/RDL2 scene classes.
• Enable Native MoonRay SpotLight updates live without needing to touch Solaris spotlightenable.
• Switching the override ON/OFF rebuilds the underlying RDL light class instead of keeping the stale original class.
• PointLight remains invalid and falls back safely.
• Standard USD ShapingAPI behavior is unchanged in this checkpoint.
• The Houdini UI cleanup keeps existing MoonRay parameter labels/types/defaults/help text intact, except for the new helper checkbox.

What's next and why is it a just a checkpoint?

I'm currently trying to find a cleaner lifecycle handling. I've been thinking about resetLightObject() by utilizing createSceneObject() for SceneContext. According to the docs here: https://docs.openmoonray.org/developer-reference/scene_rdl2-library/

Images

[rolledhand]

Also as a bit of a side node from older commits and images which I shared in the dcc_plugins PR since I have decided to go with this structure.

The Domelight translation works now and exposes the native Moonray controls in the tab which was empty prior to that. Again images from the IPR:

I have to thank to @kubo-von for this part who showed me how to expose primitive_type in the Houdini UI.

I'll keep trying to implement further translations from my initial plan so they're exposed natively on build and launch with occasional Solaris redesigns if I find them as a more artist friendly solution. This one didn't need any as it's the regular approach with other render engines.

[rolledhand]

Follow-up pushed: I moved the live light class-swap cleanup into a shared resetLightObject() helper used by both Sync() and Finalize(). This keeps the working SpotLight override behavior from the checkpoint, while making the RDL light lifecycle handling cleaner and consistent with the existing hdMoonRay pattern of making old RDL objects inert instead of trying to delete them.

[rolledhand]

Just notes for future task from my side.

[rolledhand]

MoonRay Solaris Render Settings / USD Render ROP / AOV checkpoint

Adding a catch-up checkpoint for the MoonRay Render Settings LOP, USD Render ROP, and AOV work now pinned in this branch.

This set of changes focuses on making the Houdini/Solaris MoonRay integration more usable from the artist side, while keeping the AOV implementation honest about what is actually working through the main delegate today.

Custom MoonRay Render Settings LOP

Added and expanded the source-generated custom MoonRay Render Settings LOP:

• Lop::DW_MOONRAY::moonrayrendersettings::1
• Source of truth:
  • moonray_dcc_plugins/houdini/python3.11libs/moonray_render_settings.py
• Generated HDA:
  • moonray_dcc_plugins/houdini/otls/Lop::DW_MOONRAY::moonrayrendersettings::1.hda

The node authors a native USD RenderSettings/Product/Var contract for MoonRay, including:

• RenderSettings prim path
• RenderProducts parent path
• RenderVars parent path
• output picture / product name
• camera relationship
• manual and camera-computed resolution modes
• Beauty RenderVar
• a selected set of MoonRay moonray:sceneVariable:* settings

The node preserves the expected Houdini/Solaris render contract and uses Houdini’s existing resolution helpers for camera-derived resolution.

Validated resolution modes:

• manual resolution
• set width, compute height from camera
• set height, compute width from camera

The camera-computed resolution modes are authored and validated during render tests, but there is still a minor initial-node-creation warning/error to clean up in the UI callback path. Manual resolution works without that issue. The Solaris resolution preset dropdown is also exposed.

The custom node does not author moonray:sceneVariable:image_width or moonray:sceneVariable:image_height; those remain render-pass-derived.

Expanded MoonRay settings

The custom Render Settings LOP now exposes a selected set of MoonRay controls for easier artist use. This is still work in progress: the current pass focuses on source-generated UI and USD authoring, while some controls still need runtime validation and polish. The intended AOV workflow is a simple checkbox-based tab for validated outputs.

Added groups include:

• Sampling
• Light Sampling Mode
• Tile Order
• Ray Depth / Path
• Clamping / Fireflies
• Volumes
• Filtering / Textures
• Global Toggles
• Debug / RDL output controls

These map directly to MoonRay scene variables from the local MoonRay metadata and Houdini parameter sources:

• SceneVariables.json
• HdMoonrayRendererPlugin_Global.ds

RDLA validation confirms that the custom LOP authors the expected moonray:sceneVariable:* attributes. Runtime behavior still needs more validation for some controls, especially parts of the Global Toggles group. For example, disabling Enable DOF currently does not disable depth of field as expected. I’ll handle a dedicated runtime validation/fix pass for these controls after the current Render Settings / USD Render ROP checkpoint.

USD Render ROP / beauty image-buffer support

Updated MoonRay renderer metadata so Houdini’s USD Render ROP can use MoonRay for image-buffer output:

• hdMoonray/plugin/houdini/UsdRenderers.json
• aovsupport = true

This was enabled only after validating that Beauty output is genuinely filled through the main HdMoonrayRendererPlugin.

Validated:

• husk --list-renderers sees:
  • HdMoonrayRendererPlugin (Moonray)
  • HdMoonrayRendererDebugPlugin (Moonray (debug))
• Houdini USD Render ROP node type is usdrender
• USD Render ROP works with:
  • renderer = HdMoonrayRendererPlugin
  • loppath = /stage/moonrayrendersettings1
  • rendersettings = /Render/rendersettings
• USD Render ROP produces filled Beauty pixels.
• Direct husk -R HdMoonrayRendererPlugin also produces filled Beauty output.
• husk -o output override works.

Example validation output:

• 512 x 256 EXR
• non-constant Beauty pixels
• max value around 123

Beauty AOV exposed

The custom MoonRay Render Settings LOP currently exposes Beauty only in its AOV tab.

Authored Beauty RenderVar:

• /Render/Products/Vars/beauty
• sourceName = "color"
• dataType = "color3f"
• driver:parameters:aov:name = "color"

This is the only AOV currently exposed because it is the only output proven to work through the main HdMoonrayRendererPlugin / USD Render ROP path.

Non-beauty AOV status

The following AOVs are intentionally deferred/hidden for now:

• Normal
• Geometric Normal
• Depth
• Motion Vectors
• Albedo
• OIDN Albedo
• OIDN Normal
• Cryptomatte / IDs

The previous AOV attempts showed that USD RenderVar metadata alone was not enough to produce valid buffers.

Current evidence:

• USD RenderVars can be authored correctly.
• MoonRay RenderOutputs are created correctly.
• RDLA contains the expected RenderOutput objects.
• The debug/local MoonRay path fills non-beauty outputs such as:
  • N
  • Ng
  • depth
  • albedo
  • OIDN helper-style outputs
• The main HdMoonrayRendererPlugin / Arras path creates and receives named non-beauty buffers, but those buffers currently decode as zero-valued.
• Therefore the remaining non-beauty AOV issue appears to be in the Arras/MCRT render-output payload/snapshot path, not in USD RenderVar authoring or the custom LOP.

For now, the UI only exposes outputs that are validated through the production delegate.

Arras RenderOutput robustness

Updated the Arras RenderOutput resolve path to be more robust:

• try full RDL object name
• try leaf name
• try discovered render-output id
• avoid marking failed AOV resolves as current/successful

This does not claim to fix non-beauty AOVs yet, but it removes fragile lookup behavior and avoids caching failed resolves as if those buffers had resolved successfully.

Changed areas

• moonray_dcc_plugins/houdini/python3.11libs/moonray_render_settings.py
• moonray_dcc_plugins/houdini/otls/Lop::DW_MOONRAY::moonrayrendersettings::1.hda
• hdMoonray/plugin/hd_moonray/ArrasRenderer.cc
• hdMoonray/plugin/houdini/UsdRenderers.json

Current status

Working:

• custom MoonRay Render Settings LOP
• expanded MoonRay settings UI / USD authoring
• Beauty RenderVar authoring
• direct husk Beauty output
• USD Render ROP Beauty output
• $F4 product output
• husk -o override
• camera-computed resolution authoring/render validation

Deferred:

• full runtime validation of every exposed SceneVariable control
• non-beauty AOV UI
• OIDN helper AOV UI
• motion vector UI
• Cryptomatte / IDs

Next backend target:

Fix the main Arras/MCRT non-beauty RenderOutput payload path so the production HdMoonrayRendererPlugin returns nonzero values for normal/depth/albedo/OIDN helper outputs, matching the debug/local path.

Images

Resolution examples.

Example of a control that still needs runtime validation/fixing: disabling Enable DOF currently does not disable depth of field as expected. Since the equivalent control works through the generic Solaris rendersettings node, this is likely an authoring/alignment issue between the custom LOP parameters and the data authored by the in-progress native MoonRay Render Settings node.