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]

Native Moonray camera controls exposed for pers/orth camera. Other camera types and some features deferred for now due to the design of Solaris. It's possible to implement them in the future and expand to the full feature set.

UI:
OpenMoonRay/moonray_dcc_plugins#3

[rolledhand]

Checkpoint update: initial native MoonRay light filter exposure is now wired through the Houdini/Solaris path.

This is not intended as a final “all light filters are complete” checkpoint yet. The current state is that the generated MoonRay light filter VOP HDAs are exposed for Houdini’s Light Filter Library workflow, and the hdMoonray side now handles editable Solaris ramp interpolation tokens by expanding them to the authored ramp point count.

Validated so far:

• MoonRay light filter HDAs are generated/exposed in Houdini.
• ColorRampLightFilter renders correctly with editable ramps beyond the default two points.
• Ramp positions, values, and interpolation basis are authored as native Solaris ramp arrays.

Still needs follow-up:

• Full pass across every exposed light filter.
• Cookie/projector-related filters still need more validation.
• Some filters are exposed for testing but should still be considered unstable until verified individually, not sure about float ramps yet.
• Cookie/textures are still unstable.
• There's a possible necessity for a proper life cycle clean up again.

Images:

[rolledhand]

Tested float ramp with light rod and combining multiple light filters together. I'm considering this part stable for now. What's still not stable is handling of the lifecycle through the native Solaris lightfilter subnetwork as changes (assigning and reassigning light filters) still requires a render restart to take an effect, especially with multiple light filters assigned to one light.

[rolledhand]

A small note before the next commit and push, the light filter life cycle should now be fixed. I'll have to do a proper testing on all of them. Eventually when it comes to Solaris and light filters you can you the native subnetwork assign to light (more than one) to achieve CombineLightFilter so to say.

[rolledhand]

H20.5/macOS runtime and Beauty output validation pass

I pushed a follow-up cleanup and validation pass for the H20.5/macOS MoonRay runtime path, the default Beauty output path, and the custom MoonRay Render Settings LOP disk-output contract.

This pass keeps the scope intentionally narrow: Beauty/default output is validated, while non-beauty AOV transport remains deferred.

What changed

1. macOS runtime startup

   • Added install-time ad-hoc signing so execComp no longer gets killed by macOS policy during production Arras startup.
   • Updated setup paths so Houdini can find the installed MoonRay Python stubs.
   • Pinned the setup default to the H20.5.584 proof target.

2. Default Beauty output path

   • Fixed the Hydra color / final-color path so it resolves through MoonRay beauty before sourceName / sourceType handling.
   • This restores the direct/default Beauty path and keeps it separate from RenderOutput-backed AOVs.

3. Render Settings / disk output

   • Removed the incomplete RenderSettingsPrim bridge from this pass.
   • Kept aovsupport=false, since Beauty RenderProduct/RenderVar disk output works without advertising unsupported full AOV support.
   • Updated the custom MoonRay Render Settings LOP so disk output authors a Beauty RenderVar / orderedVars by default.

4. Viewport UI cleanup

   • Reverted the adaptive sampling viewport DS regression back to the previous working condition.
   • Synced the installed DS payloads so Houdini loads the corrected definitions.

Validation

Validated from a fresh H20.5.584 shell with production HdMoonrayRendererPlugin:

• Direct/default color render: filled, nonconstant EXR.
• Custom MoonRay Render Settings LOP default: filled, nonconstant EXR.
• Generic Render Settings + built-in RenderProduct/RenderVar: filled, nonconstant EXR.
• DCC validation: 51 PASS, 0 FAIL, 6 SKIP.

Deferred / still open

Non-beauty AOVs are still intentionally deferred. They are mapped and declared, and the debug renderer can produce data, but production Arras currently zero-fills those RenderOutput payloads.

cameraDepth is kept only as historical diagnostic evidence, not as the next implementation path.

One runtime issue is still noted separately: Arras logs SocketPeer::receive: Bad file descriptor after successful output writes. I’m not suppressing that without a proper teardown.

[rolledhand]

hdMoonRay color-management checkpoint

I pushed the first real hdMoonRay renderer working-space path for Houdini 20.5.584.

This makes RenderSettings.renderingColorSpace affect actual MoonRay/RDL scene values for authored color constants, instead of only changing husk’s downstream image-save transform.

The implementation adds a direct OpenColorIO-backed conversion layer in hydramoonray, consumes renderingColorSpace through RenderDelegate::SetRenderSetting(), and converts typed USD/Hydra color values before assignment into MoonRay objects.

What changed

1. Renderer working-space conversion

   • Added ColorManagement.h / ColorManagement.cc.
   • Linked hydramoonray against OpenColorIO::OpenColorIO.
   • Consumed RenderSettings.renderingColorSpace through RenderDelegate::SetRenderSetting().
   • Used TfToken("renderingColorSpace") for H20.5.584 compatibility.

2. Authored color constants

   • Converted material authored color constants and typed RDL color attributes.
   • Converted light authored color values.
   • Converted light-filter authored color values.
   • Routed generic typed RDL color conversion through the same path.

3. Render-settings lifecycle fix

   • Guarded RenderDelegate::setDisableLighting() before dirtying lights when mRenderIndex is not available.
   • This prevents a MarkSprimDirty() crash seen during TX validation when disableLighting=true.

Core proof

Case	RDLA value
None / Rec.709	Rgb(0.5, 0.25, 0.125)
ACEScg	Rgb(0.39735195, 0.265866846, 0.146427065)
Rec.2020	Rgb(0.401436865, 0.265854001, 0.142148465)

renderingColorSpace now changes actual MoonRay/RDLA scene values. It is no longer only husk’s downstream save transform changing the final image.

Validation

Validated against Houdini 20.5.584:

• Rebuilt and installed hydramoonray and hd_moonray Release.
• Installed dylibs link libOpenColorIO.2.0.dylib.
• Installed dylibs are ad-hoc signed.
• husk --list-renderers lists both MoonRay delegates.
• DCC validation remains green: SUMMARY PASS=51 FAIL=0 SKIP=6.
• Default/no-RenderProduct smoke render exits 0 and writes a valid EXR.
• git diff --check passed in parent, hdMoonray, and DCC.

Deferred / still open

This pass intentionally does not claim full material color management in the broad sense.

• Texture destination gamut conversion into ACEScg/Rec.2020 is not solved.
• UsdUVTexture.sourceColorSpace=auto/sRGB/raw still survives into MoonRay and TX tests render, but that is source decode, not destination working-space conversion.
• MaterialX image color management remains unproven.
• Viewport/IPR visual parity still needs fresh GUI validation.
• AOV transport was not touched.

[rolledhand]

Still need to do actual testing on this part, since I'm suspicious about a beauty pass encoded with "raw" value, but we will see. I'm stabilizing the USD Render ROP next which used to be that way before too.

Also as an insight - this doesn't mean that AOVs are stable, but "aovsupport" : true, must be set to true for the USD Render ROP to see Moonray a render delegate in the dropdown. It doesn't show up at all otherwise.

[rolledhand]

DCC/USD Render ROP output-path fix

I pushed a DCC-only fix for the generated MoonRay USD Render ROP output-path contract.

The previous MoonRay ROP helper deliberately left outputimage blank, so husk fell back to RenderProduct.productName = "$HIP/render/$HIPNAME.$OS.$F4.exr". When consumed outside the correct Houdini ROP/node context, that resolved to:

./render/untitled..0001.exr

That made successful renders hard to find and did not match native USD Render ROP behavior.

What changed

1. Owned USD Render ROP output authority

   • The generated MoonRay-owned usdrender_rop now drives output through outputimage.
   • outputimage references the owning MoonRay Render Settings LOP product_name.
   • RenderProduct.productName remains valid as the USD fallback path.

2. ROP wiring cleanup

   • loppath now uses the native-style input expression:
     • opinput(".", 0)
   • rendersettings references the owning MoonRay Render Settings LOP render settings prim.
   • Added relative sibling-path normalization so ownership/repair still works when opinput(".", 0) evaluates to a relative path like moonrayrendersettings1.

3. Validation coverage

   • Added tests for ROP expressions, outputimage following product_name, rename/repair/recreate behavior, disconnect handling, and duplicate prevention.
   • Updated the audit doc to remove stale “outputimage blank” wording and document the repaired output-authority split.
   • Regenerated the MoonRay Render Settings LOP HDA.

Validation

Validated against Houdini 20.5.584:

• DCC validation: SUMMARY PASS=59 FAIL=0 SKIP=6
• Source/install Python and HDA payloads match by SHA-256
• Manual husk explicit -o writes a valid nonconstant EXR
• Absolute RenderProduct.productName fallback writes a valid nonconstant EXR
• Plain USD Render ROP with blank outputimage and concrete RenderProduct.productName writes a valid nonconstant EXR
• Owned MoonRay ROP output override writes a valid nonconstant EXR
• Saved HIP $HIP output path writes under the saved HIP directory
• Default $HIP/render/$HIPNAME.$OS.$F4.exr now evaluates with populated $HIPNAME and $OS in the owned ROP path
• git diff --check passed
• aovsupport=true remains enabled

Still open

This does not address the next Render Settings issues yet:

• Sampling/export needs a separate audit. The inspected USD currently authors sampling_mode = "uniform" with pixel_samples = 8, while adaptive settings are also present.
• Frame range handoff still needs validation beyond USD layer metadata.
• GUI/ROP repeated sync/restart behavior still needs investigation:
  • MCRT: Detected change in resolution
  • Starting Rendering (syncId:2/3/4)
• EXR metadata is still weak: OIIO reports only oiio:ColorSpace = "Linear", without a specific working gamut.
• EXR renderTime_s and renderMemory_s metadata appears incorrect and needs a separate metadata pass.

[rolledhand]

Also there's a time dependency now, but that'd be an easy fix once the more important issues are fixed.

[rolledhand]

Fixed the time dependency and switching uniform/adaptive in the dropdown now works correctly with "greying out" the adaptive/uniform sampling in the native LOP.

[rolledhand]

Native AOV zero-fill root cause found and repaired

I ran a full fix-and-prove pass for the production native AOV zero-fill issue on the H20.5.584 MoonRay/Houdini/Solaris stack.

The important result is that the zero-fill was not caused by USD RenderVar authoring, RenderBuffer lookup, RDLA declaration, or final EXR writing.

Temporary sender/receiver diagnostics showed:

• mcrt had active, finite, nonzero native AOV values before encoding.
• The receiver saw zero values immediately after PackTiles::decodeRenderOutput().
• A sender-side self-decode of the freshly encoded packet also produced zeros.

That narrowed the first proven data loss to the H16 PackTiles encode/decode path.

A standalone Apple Silicon repro then confirmed the root cause: the existing ARM NEON scalar half conversion corrupted values such as 5.12391 into near-zero half data. The scalar __fp16 path produced the expected half value. The Apple path now uses scalar __fp16 conversion plus std::memcpy bit transport, while the non-Apple path remains unchanged.

What changed

1. Fixed Apple Silicon H16 PackTiles conversion

   • scene_rdl2/lib/common/grid_util/PackTiles.cc
   • Replaced the broken ARM scalar half conversion path with scalar __fp16 conversion plus std::memcpy.
   • This fixes H16 PackTiles payload corruption in the production Arras AOV path.

2. Fixed matching native MoonRay half output conversion

   • moonray/lib/rendering/rndr/RenderOutputWriter.cc
   • Applied the same Apple Silicon half conversion fix for native MoonRay half output writing.

3. Fixed pre-bind Arras RenderBuffer allocation

   • moonray/hydra/hdMoonray/plugin/hd_moonray/ArrasRenderer.cc
   • Pre-bind allocation now honors the requested channel count.
   • Buffers are cleared/reallocated when size or channel count changes.
   • This avoids treating every unresolved pre-bind buffer as Beauty/RGBA before the RenderOutput is bound.

4. Updated hdMoonray docs

   • Marked the old native AOV zero-fill baseline as historical/superseded.
   • Documented the Apple Silicon half-packing root cause and the repaired production AOV baseline.

Validation

Validated against Houdini 20.5.584 with production HdMoonrayRendererPlugin.

Rebuilt and installed/signed the affected runtime libraries:

• libcommon_grid_util.dylib
• librendering_rndr.dylib
• libgrid_engine_tool.dylib
• libclient_receiver.dylib
• hd_moonray.dylib

Confirmed:

• husk --list-renderers still lists MoonRay and MoonRay debug.
• aovsupport=true remains enabled.
• Temporary diagnostic strings were removed from installed dylibs.
• No source/build/install *cameraDepth* or *native_aov* scratch files were left behind.
• git diff --check passed across the touched repos.

Production HdMoonrayRendererPlugin now writes filled EXRs for explicit RenderVar tests:

• Beauty/color
• alpha
• depth
• cameraDepth
• Z
• N
• Ng
• P
• Wp
• St
• weight, constant nonzero in the simple fully sampled fixture

Still open

This pass does not claim to solve the broader AOV/UI surface yet:

• Broad AOV UI exposure is still deferred.
• Multi-AOV products are not validated yet.
• Material AOVs, LPEs, visibility AOVs, primvars, Cryptomatte, and motion vectors still need separate validation.
• Sampling live-update and repeated GUI sync/restart behavior are still not addressed.
• The remaining Beauty bayer/stripe issue still needs a GUI/IPR pass.
• Arras socket shutdown messages are still observed after successful writes and were not suppressed.
• EXR renderTime_s / renderMemory_s metadata still appears incorrect and needs a separate metadata pass.

[rolledhand]

Really glad that I can share those since this one took me quite a while to get running.

Images

[rolledhand]

MoonRay native AOV / Beauty color4f checkpoint

Adding a checkpoint for the native AOV cleanup/finalization work now pinned in this branch.

This pass stabilizes the first production-validated native AOV set for the custom MoonRay Render Settings LOP and fixes the explicit Beauty RenderVar corruption seen through the Houdini/Solaris USD Render ROP path.

Commits

DCC commit:

• e1980e564d2b440f7ea7dddfa03544b97859b19e
• Stabilize native AOV output in MoonRay Render Settings LOP

Parent commit:

• 0d8d2da55efbed49959939794532ab896bb87531
• Update MoonRay DCC native AOV UI pin

Summary

The key fix in this pass is that the explicit Beauty RenderVar is now authored as color4f instead of color3f.

Previous Beauty authoring:

• dataType = "color3f"
• sourceName = "color"
• driver:parameters:aov:format = "color3f"

Updated Beauty authoring:

• dataType = "color4f"
• sourceName = "color"
• driver:parameters:aov:format = "color4f"

This fixes the vertical RGB/bayer-like EXR corruption seen when Beauty was authored as color3f. The evidence points to the hdMoonray explicit Beauty / color path expecting the RGBA beauty-buffer contract.

Final exposed AOV set

The custom Render Settings LOP now exposes:

• Beauty/color
• alpha
• depth
• Z
• N
• Ng
• P
• Wp
• St
• weight

These are the currently stabilized native outputs for the production delegate path.

cameraDepth cleanup

cameraDepth was a made up custom AOV pass for testing. It's gone and clean now.

Backend Hydra compatibility mapping was intentionally left untouched. The product-facing depth outputs are now depth and Z.

Changed areas

• moonray_dcc_plugins/houdini/python3.11libs/moonray_render_settings.py
• moonray_dcc_plugins/houdini/otls/Lop::DW_MOONRAY::moonrayrendersettings::1.hda
• moonray_dcc_plugins/houdini/tests/dev_validate_moonray_render_settings_lop.py
• moonray_dcc_plugins/houdini/docs/moonray_render_settings_lop_audit.md
• parent submodule pointer for moonray/moonray_dcc_plugins

Validation

• Python syntax validation passed.
• Installed H20.5 DCC validation passed:
  • SUMMARY PASS=90 FAIL=0 SKIP=6
• git diff --check passed in parent, DCC, and hdMoonray.
• husk --list-renderers still lists:
  • HdMoonrayRendererPlugin
  • HdMoonrayRendererDebugPlugin
• aovsupport=true remains present in source and installed UsdRenderers.json.
• No untracked generated junk remained before commit.

Runtime validation:

• EXR render tested successfully.
• Beauty color4f removes the vertical RGB/bayer-like corruption.
• Native AOVs render filled.
• EXR inspected with OIIO.
• Houdini Copernicus and Nuke both read the channels correctly.

Current status

Working:

• custom MoonRay Render Settings LOP native AOV UI
• Beauty/color output through the explicit RenderVar path
• Beauty authored as color4f
• alpha
• depth
• Z
• N
• Ng
• P
• Wp
• St
• weight
• USD Render ROP / production delegate EXR output
• Copernicus channel reading
• Nuke channel reading

Deferred:

• material/OIDN AOVs, especially albedo and normal
• LPE/light AOVs
• visibility AOVs
• primvar AOVs
• motion vectors
• Cryptomatte, if ever needed
• adaptive sampling live-update
• syncId restart loop
• GLD viewport warning

Next target

The next AOV target is material/denoising auxiliary output, with priority on OIDN-ready:

• albedo
• normal

That pass should first check the official MoonRay RenderOutput/material AOV/OIDN denoising contract and local RenderOutput.json metadata before exposing any new controls.

Images

[rolledhand]

MoonRay material / denoise AOV checkpoint

Adding a checkpoint for the material and denoising AOV work now pinned in this branch.

This pass adds a separate Material / Denoise AOV section to the custom MoonRay Render Settings LOP.

Exposed and production-proven outputs:

• Denoise Albedo
• Denoise Normal
• Material Albedo
• Material Emission
• Material Normal
• Material Roughness
• Material PBR Validity

The denoise outputs follow the official MoonRay denoiser contract:

• Denoise Albedo uses D.albedo with denoiser_input = as albedo
• Denoise Normal uses N with denoiser_input = as normal

Not exposed after testing:

• Material Color
• Factor
• Radius

These were discovered but not exposed because production proof was missing or not meaningful in this pass.

Validated:

DIrectly in Houdini, oiio, etc.

[rolledhand]

The following areas are intentionally deferred for now:

• Motion vectors for post motion blur
• LPE/light AOVs
• visibility AOVs
• primvars/custom attribute AOVs
• Cryptomatte
• syncId restart-loop cleanup
• Arras socket shutdown message
• GLD viewport warning

[codesavory]

This is a ton of solid work, Jakub. The macOS/H21 build path alone is a big unblock.

Why it's stuck

• It's one big PR mixing the build/compat fixes (done, validated) with the still-WIP shader/runtime work.
• That bundle is hard to approve as a unit, which is likely why it's sat on REVIEW_REQUIRED.

Proposal: split it

• Land the build/compat core on its own first: libpxr_usdRiPxrImaging rename, libpxr_python for pxr_boost::python, Boost 1.82, log4cplus, NO_USD deps, Python 3.11 paths.
• That part is self-contained and low-risk, and gives everyone a working H21 macOS base.
• The material/light/AOV work follows as separate PRs once stable.

How I can help

• I'm on the same toolchain (Tahoe, Xcode 26, H21.0.631) and my build came up clean with the same fixes, so I can independently reproduce and review the build PR.
• I can take AOVs off your next-steps list. I've already dug into the RenderVar → RenderOutput path (RenderBuffer.cc hardcoded table, Allocate() before Bind(), hd_usd2rdl only binding color).
• Happy to split the work however suits you while you keep pushing the rest.