Houdini 21 (Hydra Scene Index mode): native Houdini primitive geometry does not render in hdMoonray

[codesavory]

Under Houdini 21, Hydra runs in Scene Index mode, and hdMoonray doesn't render native Houdini primitives. A Sphere LOP renders blank with Moonray, but renders fine in Houdini GL, and a USD asset (crag) renders fine with Moonray. So the geometry is valid and the delegate works; only native primitives in Scene Index mode fail.

Env: macOS Apple Silicon, Houdini 21.0.631, Houdini USD 23.x (v0_25_5), Python 3.11, hdMoonray 6.41.0.0, scalar exec mode.

Repro:

1. Sphere LOP in Solaris, render with Moonray → blank.
2. Same sphere, Houdini GL → renders.
3. crag.usd with Moonray (Debug) → renders.

Sphere + Moonray (blank):

Sphere + Houdini GL (renders):

crag.usd + Moonray Debug (renders):

Rob Wilson confirmed on ASWF Slack this is a known Scene Index limitation he's working on:

if you are using Houdini 21, it is running Hydra in SceneIndex mode. There are few things that don't work in that mode, including primitive geometry. I'm currently working on fixes for these issues.

Slack thread: https://academysoftwarefdn.slack.com/archives/C0AHKA6E17Z/p1776195285395069

I have a working Houdini 21 / macOS build and am happy to help fix this — pointers on where Scene Index primitive handling lives would be welcome.

[gripeyes]

Hey, I just got this one to work yesterday, I'll be pushing the changes today on my forks and send it to you. Also trying to fix the AOVs etc.

Did you build on Tahoe/Seqoia btw? I'm about to downgrade to Sequoia today since I started having some Clang during build issues w/ the latest Tahoe.

The primitive handling lives in the hdMoonray where I'm currently trying to aling h20.5 USD/hydra requirements w/ Moonray for the translation layer - at least assuming it works and should be handled that way.

[codesavory]

Nice, looking forward to your branch. I'll test it against my repro as soon as it's up.

On the OS question: I'm on Tahoe (macOS 26, Apple Silicon) and the OpenMoonRay / hdMoonray build itself was clean. No Clang errors. The only Apple Silicon gotcha I hit was needing HDMOONRAY_EXEC_MODE=scalar at runtime. Vector mode crashes on ARM. Rest of the stack: Houdini 21.0.631, Python 3.11, hdMoonray 6.41.0.0.

If the Clang errors are during the OpenMoonRay compile, I'd suspect Xcode CLT version, TBB, or ISPC before I'd suspect Tahoe. Happy to share my CMake invocation and toolchain versions before you downgrade.

Good to know primitive handling lives in the hdMoonray translation layer. That matches what Rob hinted at on Slack. I'll dig in there once you push.

[gripeyes]

It's already up, but I'm trying to push it towards a proper v1 first, hopefully by the end of the week.

I'm pretty certain it has something to do with Tahoe + Xcode, I have to clean up either way and already backed everything up, but if there's a way to not downgrade it might be even better. Can't say that I like the newest OS version honestly. I'd be grateful for any insights either way.

Planning to stabilize light filters, finish an artist friendly lop/rop along with getting AOVs stable (not sure how high chance of a success there) and maybe also check out color pipeline as I was having mismatch on the final exrs. Think that it could mark the v1 target from my side.

[codesavory]

Yeah, your Tahoe + Xcode hunch is probably right. That's where most of the macOS 26 build pain is right now. But I got mine to build clean on Tahoe, so it's doable without going back to Sequoia. Here's my whole setup so you can diff it against yours.

First thing I'd check: I'm on full Xcode 26.0.1 (Build 17A400), not the standalone Command Line Tools. xcode-select -p gives me /Applications/Xcode.app/Contents/Developer. If yours points at /Library/Developer/CommandLineTools, the CLT clang and the Xcode clang can drift, and that throws Clang errors mid-build. Quick check, might be your culprit.

Full toolchain that worked for me:

macOS        26.5 (Tahoe), Apple Silicon arm64
Xcode        26.0.1 (17A400)
clang        Apple clang 17.0.0 (clang-1700.3.19.1)
CMake        4.3.1
ISPC         1.20.0 (LLVM 15.0.7)   built from source via the deps step
TBB          2020 U3
Houdini      21.0.631  (Python 3.11, USD 23.x / pxr v0_25_5)
hdMoonray    6.41.0.0

Deps build (one-time):

cd source/openmoonray/building/macOS
mkdir build-deps && cd build-deps
CMAKE_POLICY_VERSION_MINIMUM=3.5 cmake ..
CMAKE_POLICY_VERSION_MINIMUM=3.5 cmake --build .

Main build:

cd source/openmoonray
CMAKE_POLICY_VERSION_MINIMUM=3.5 cmake --preset macos-houdini-release
CMAKE_POLICY_VERSION_MINIMUM=3.5 cmake --build --preset macos-houdini-release

The CMAKE_POLICY_VERSION_MINIMUM=3.5 prefix matters on CMake 4.x. It errors on cmake_minimum_required() below 3.5, which a bunch of the deps still declare. Without it the deps configure step dies and it reads like a compiler error when it's really a policy error. Tripped me up at first.

Two more, both runtime not build: HDMOONRAY_EXEC_MODE=scalar (vector/ISPC path crashes on ARM), and the Metal toolchain has to be installed for XPU shader compile (xcodebuild -downloadComponent MetalToolchain).

If none of that lines up, paste your Clang errors and I'll dig in with you. The v1 scope sounds good. Light filters and stable AOVs are what I'm after too, so I'll test branches as you push them.