Build against OpenUSD 25.11 built from source with Python 3.12, OCIO 2.2.1,
OpenVDB, Ptex and Embree, replacing the 25.05/py311 mix.
Build system:
- CMAKE_PREFIX_PATH -> third_party/OpenUSD-v25.11; HDARNOLD_ROOT ->
hdArnold-v25.11. hdEmbree is bundled in the USD build now, so
HDEMBREE_USD_ROOT is no longer needed.
- FindOpenUSD: drop usd_ndr (ndr was merged into sdr in 25.11).
- hdArnold plugin renames: ndrArnold -> nodeRegistryArnold, plus the new
usdImagingArnold plugin.
- Glob the version-suffixed OpenColorIO_*.dll instead of hardcoding 2_1.
- Drop the python311.dll workaround; USD and Cycles now share Python 3.12.
- Cycles: deploy OpenColorIO_2_5.dll (needed by its bundled OpenImageIO) and
stop the debug-DLL filter from eating IlmThread.dll -- the regex `d[.]dll$`
also matched legitimate Release DLLs.
Runtime fixes:
- cullStyle now defaults to Nothing, matching usdview (viewSettingsDataModel
cullBackfaces=False). BackUnlessDoubleSided drops back faces on geometry
that isn't authored doubleSided, which hdEmbree applies to occlusion rays
too, so interiors shaded as single-sided.
- Set HDARNOLD_osl_includepath (and PXR_MTLX_STDLIB_SEARCH_PATHS) in main.cpp
before the plugin DLL pre-load. hdArnold compiles MaterialX via generated
OSL that begins with #include "mx_funcs.h"; without an include path Arnold
fails with "fatal error: 'mx_funcs.h' file not found". It must be set before
any plugin loads because TF_DEFINE_ENV_SETTING caches the value when
hdArnold.dll registers its settings.
- Deploy the MaterialX standard library next to the executable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- NodeThumbnailCache/MaterialPreviewRenderer: keep a material node
thumbnail stale (re-pumped each frame) until the shared preview
renderer actually converges, instead of caching after one render
pass. Progressive delegates (Arnold/Cycles/Embree) need multiple
passes to accumulate past their first noisy sample, so thumbnails
previously froze on an early frame and only "fixed themselves"
when toggling thumbnail display forced a fresh render.
- MaterialEditorPanel: add a Color Space row under Asset-typed
shader inputs, authoring the attribute's colorSpace metadata from
the active OCIO config's color spaces.
- MaterialManager: surface Sdr-declared allowed values (enums) per
shader input so the property panel can render a dropdown instead
of free text.
- CMakePresets.json: build the release preset with debug info
(RelWithDebInfo) for easier diagnosis.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hydra's HdxColorCorrectionTask rendered prims black in OCIO mode and could
corrupt the GlfDrawTarget bind stack on failure (skipping Unbind), blacking
out every later frame including sRGB. Replace it with our own GL post-process:
the scene renders linear (RGBA16F) and is corrected by a fullscreen shader --
linear->sRGB encode, or OCIO via the OCIO 2.1 GPU API (GpuShaderDesc plus
uploaded 1D/3D LUT textures). OCIO build failures fall back to sRGB (never
black) and USD diagnostics are routed to the app log.
- core: ViewportColorCorrector + ApplyViewportColorCorrection in UsdSceneRenderer
- utils: OcioConfigParser enumerates displays/views/colorspaces/looks from $OCIO
- ui: gear-menu OCIO controls (ViewportTile) + per-viewport persistence (ViewportPanel)
- Application: point $OCIO at the bundled ACES 1.2 config
- CMake: link/copy OpenColorIO, download ACES 1.2 config; plus hdCycles build
config (disable OpenVDB/Embree, fix TBB/OpenSubdiv/Imath dirs, exclude CRT DLLs)
- main: pre-flight plugin DLL load check to skip plugins with missing deps
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two independent fixes for the install layout:
1. Cycles bundles old MSVC CRT DLLs (MSVCP140 v14.34, VCRUNTIME140 v14.34)
that are placed in install/bin/ via the CYCLES_INSTALL_DIR copy. These take
precedence over System32 on the DLL search path. sycl8.dll (built with newer
VS2022 CRT v14.42) calls functions that don't exist in the old version, causing
ERROR_DLL_INIT_FAILED (1114) when hdCycles.dll loads embree4 -> sycl8. Fix:
exclude MSVCP140*.dll, VCRUNTIME140*.dll, ucrtbase*.dll, api-ms-win-*.dll from
the install(DIRECTORY cycles_install/) rule. The system VC++ Redistributable
satisfies these at runtime.
2. usd_python.dll (the OpenUSD Python bindings DLL) was compiled against Python
3.11 while our build targets Python 3.12. Add auto-detection of python311.dll
from common install paths and deploy it to both the build output and install/bin/
so the dependency chain hdCycles->usd_python->python311 is satisfied.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Build Cycles from third_party/cycles via ExternalProject (WITH_CYCLES=ON)
- Deploy hdCycles.dll + plugin metadata to usd/ alongside hdEmbree/hdArnold
- Copy Cycles runtime deps (embree4, openvdb, OIDN, sycl, imath, etc.) via
a cmake -P script that globs at build time, excluding CRT DLLs to avoid
MSVCP140 version conflicts
- Deploy tbb12.dll explicitly from the precompiled lib tree (required by
openvdb/embree4 but absent from the install output)
- Bake all renderer paths into CMakePresets.json default preset
(WITH_CYCLES, HDARNOLD_ROOT -> E:/library/hdArnold, ARNOLD_LOCATION,
HDEMBREE_USD_ROOT) so a fresh configure needs no manual -D flags
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
indigo