Cycles Hydra Render Delegate and USD feedback

This is a topic for discussion about the Hydra Render Delegate for integration in other applications, and USD support for the standalone Cycles.

This is mainly aimed at developers that want to improve the implementation to turn this into something usable, not a supported feature for end users. Contributions are welcome.

Editing of device settings, render settings and materials is completely missing or limited host applications, which is the main thing to improve. Choosing the render device can be done with an environment variable like CYCLES_DEVICE=OPTIX.


hey @SteffenD how do you build cycles for houdini ?
i know nothing about building blender nor cycles, should i wait for someone to upload a cycles version for houdini or should i learn to do it myself ?

Hey @brecht I co-own a small 30ish people studio, we’ve been Blender based since a few years now and are producing solid work with it. Thank you so much to the Blender team for putting some effort into this Hydra delegate, It will allow us to expand and solidify our pipeline take bigger jobs, diversify our team and grow.

Again thank you.

@NizarAmous, there is a sort of guide published on building for houdini ⚙ D14594 Cycles Hydra: support for building against Houdini, also on the build instructions on this page,

Hope this helps :slight_smile:


Hi @NizarAmous and sorry for the late reply.
I’m not a coder or experienced builder, but following the guides here I managed to successfully build Blender on Linux and Windows. Both should work fine if you follow the guides closely.
As @EstebanCovo already mentioned there is also a guide on how to build Cycles Hydra delegate for Houdini and it should be just as easy to follow. I haven’t tried it on Windows yet but on Linux everything works as stated there.
The support for Cycles inside Houdini Solaris is pretty basic still but it already feels quite nice to see “Cycles” in the Houdini viewport.

1 Like

The guide for building Cycles is not as detailed as the one for Blender. Generally you need to install all the same development tools and packages as Blender, and then following the build instructions in the Cycles should work.



managed to build cycles for houdini 19.0.561 with the instruction in “” for windows.
the plugin loads fine in houdini and i can select cycles in solaris.
but it renders nothing…(test geo, domelight, usdpreviewsurface material…)
i can see its doing the samples (1024) in the top info but nothing to see in the viewport…empty…
any hints whats going wrong?

(on building, i got some warnings concerning cycles_scene.vcxproj, but the build was successfull)

edit: the …/hydra/camera.cpp hack didnt help…

Hi, I’m not an expert by any stretch but I managed to build Cycles standalone in windows and get some render examples running out of it, this has been really straightforward, just to clarify a few points: for OPTIX I recommend sticking with the 7.3 installation since to get the 7.4 running you have to update the libs cmake file.
To generate the build files for the Hydra delegate using Houdini on windows you have to use something like: cmake -D HOUDINI_ROOT=C:\Program Files\Side Effects Software\Houdini 19.0.383 -S cycles/ -B builddel/ -G "Visual Studio 16 2019"
On the guide it says that the variable is called -DHOUDINI_ROOT, this might be easy to spot to a seasoned programmer but for a beginner it might be confusing.

Also if Cycles asks for some libraries that it can’t find, what I did was to copy and paste those libraries next to the executable, at least in debug mode this happened to me

After getting Cycles Standalone running on windows no problem, I get painfully stuck while trying to get it to build with Houdini based Hydra Delegate, it throws a few errors that I don’t get while just building the standalone version, Basically it says that differences have been detected between a value in a library and a valio in the plugin.obj file or the standalone.obj file. I’m surely doing something wrong but if someone has any idea of what this might be it would be tremendously helpful.
I’m attaching the errors as reference as not to clog the post but I’m going to copy a couple of lines here, maybe someone smarter than I can get an Idea of what’s going on without too much hassle

"C:\HydraDelegates\Cycles\builddel\Cycles.sln" (default target) (1) ->
"C:\HydraDelegates\Cycles\builddel\ALL_BUILD.vcxproj.metaproj" (default target) (2) ->
"C:\HydraDelegates\Cycles\builddel\src\app\cycles.vcxproj.metaproj" (default target) (4) ->
"C:\HydraDelegates\Cycles\builddel\src\app\cycles.vcxproj" (default target) (31) ->
(Link target) ->
  libosdCPU_md.lib(patchTable.obj) : error LNK2038: se detectaron diferencias para '_ITERATOR_DEBUG_LEVEL': el valor '0' no coincide con el valor '2' en cycles_standalone.obj [C:\HydraDelegates\Cycles\builddel\src\app\cycles.vcxproj]
  libosdCPU_md.lib(patchTable.obj) : error LNK2038: se detectaron diferencias para 'RuntimeLibrary': el valor 'MD_DynamicRelease' no coincide con el valor 'MDd_DynamicDebug' en cycles_standalone.obj [C:\HydraDelegates\Cycles\builddel\sr

"C:\HydraDelegates\Cycles\builddel\Cycles.sln" (default target) (1) ->
"C:\HydraDelegates\Cycles\builddel\ALL_BUILD.vcxproj.metaproj" (default target) (2) ->
"C:\HydraDelegates\Cycles\builddel\src\hydra\hdCycles.vcxproj.metaproj" (default target) (36) ->
"C:\HydraDelegates\Cycles\builddel\src\hydra\hdCycles.vcxproj" (default target) (37) ->
  libosdCPU_md.lib(patchTable.obj) : error LNK2038: se detectaron diferencias para '_ITERATOR_DEBUG_LEVEL': el valor '0' no coincide con el valor '2' en plugin.obj [C:\HydraDelegates\Cycles\builddel\src\hydra\hdCycles.vcxproj]
  libosdCPU_md.lib(patchTable.obj) : error LNK2038: se detectaron diferencias para 'RuntimeLibrary': el valor 'MD_DynamicRelease' no coincide con el valor 'MDd_DynamicDebug' en plugin.obj [C:\HydraDelegates\Cycles\builddel\src\hydra\hdC

errors.txt (31.0 KB)

I don’t know this consider is a feedback or not.
I have the same thing now, it’s success but not really render anything out in viewport but render does work in the MPlay with color management disable Specify $OCIO environment variable thing prompt.

I’m not sure the build fail in someway, is it suppose to have the viewport settings? there is no render parameter settings there like samples, light path?

I’m leaving this here in case another noob (like me :slight_smile: ) with msbuild stumbles on the problem, basically the problem has to do with msbuild making a debug compile by default, this caused aparently a mismatch with the Hydra build which was release, to fix I just flagged the release property.

MSBuild Cycles.sln -p:Configuration=Release

In this instance MSBuild’s path is already added to my path’s variables
As a last note, you can use visual studio community directly if you don’t want to use the console, just build as release not as debug.

Hope this helps someone.

Hi, everything builds correctly now (apparently) but the path I get to the Hydra delegate is:
<path to build>\build\bin\Release\hdCycles.dll
next to the Cycles.exe
On the instructions it is made apparent that the build should have yield a folder structure similar to:

<path to cycles>/build/bin/houdini/dso/usd_plugins houdini
<path to cycles>/build/bin/houdini/packages/cycles.json

I don’t seem to have these structures or these files, I’m sure I messed up doing the build somewhere, most likely during the project generation, since this line:


didn’t work for me on windows I had to change it to

cmake -D HOUDINI_ROOT="C:\Program Files\Side Effects Software\Houdini 19.0.383" -S cycles/ -B build/ -G "Visual Studio 16 2019"

And probably messed up something, if someone could point where this mistake might be or how to use a better line to build the project on windows I would greatly appreciate it.

I found them in here:


Still don’t know how to make the process generate the right folder structure

the “make” command line also not worked for me , so i ended up modifying the make.bat file and wrote the arguments in there…

for me it builds the folder structure so i can point to it with the PXR_PLUGINPATH_NAME env var…
i also use WITH_BLENDER=0

but as i mentioned above i get an empty solaris viewport when choosing cycles…

@soulcage would it be to much to ask to see your folder structure and json files?

Ok, I’ve got the same problem you have, now it recognizes that there is a Cycles Delegate but I have no geometry showing, if I switch to Karma the geo is there, switch to cycles and there is no geo present.

I actually don’t get cycles render parameters or apparently any cycles material nodes, I can only infer that since it recognizes the plugInfo.json file it makes a placeholder render delegate but the file structure and .json file is messed up, so it just doesn’t find the actual delegate or renderer or both (although it seems to be running samples when I switch to cycles so I’m at a loss here).

Can please somebody that has made it work for windows post a small for dummies guide?, I’ll keep digging, probable will make an ubuntu partition so I can try to run it there and compare the file structure

I haven’t been trying too many things with the Hydra delegate in Houdini, but at least I can get the “Rubbertoy” test geometry to show up in the rendered Cycles view. I’m on Linux and use the latest daily build of Houdini.
Lighting looks like a completely white environment and there are no further settings like samples or dev ice. But at least something shows up in the Viewport which is a huge baby step :wink:

then the empty viewport seems to be a windows build thing…

@EstebanCovo my folder structure is like that:



"Plugins": [
        "Info": {
            "Types": {
                "HdCyclesPlugin": {
                    "bases": [
                    "displayName": "Cycles",
                    "priority": 0
        "LibraryPath": "../hdCycles.dll",
        "Name": "hdCycles",
        "ResourcePath": "../../../../",
        "Root": "..",
        "Type": "library"

quick n dirty modified make.bat:

@echo off

REM Convenience wrapper for CMake commands

setlocal enableextensions enabledelayedexpansion

set BUILD_DIR=build
set PYTHON=python
set COMMAND=%1

if "%COMMAND%" == "" (
  set COMMAND=release

if "%COMMAND%" == "release" (
	if not exist "%BUILD_DIR%" mkdir %BUILD_DIR%
	cd %BUILD_DIR% && cmake %BUILD_CMAKE_ARGS% -DWITH_BLENDER=0 -DWITH_CYCLES_HYDRA_RENDER_DELEGATE=ON -DHOUDINI_ROOT="C:\Program Files\Side Effects Software\Houdini 19.0.561" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=bin/Release .. && cmake --build . --target install --config Release
) else if "%COMMAND%" == "debug" (
	if not exist "%BUILD_DIR%" mkdir %BUILD_DIR%
	cd %BUILD_DIR% && cmake %BUILD_CMAKE_ARGS% -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=bin/Debug .. && cmake --build . --target install --config Debug
) else if "%COMMAND%" == "clean" (
	cd %BUILD_DIR% && cmake --build . --target install --config Clean
) else if "%COMMAND%" == "test" (
	cd %BUILD_DIR% && ctest --config Release
) else if "%COMMAND%" == "update" (
	%PYTHON% src/cmake/
) else if "%COMMAND%" == "format" (
	%PYTHON% src/cmake/
) else (
  echo Command "%COMMAND%" unknown

Looks like the OpenGL interop “hack” to keep viewport updates on the GPU isn’t always working properly in Houdini right now. Will need to look into that, since it’s working in other applications. But you can disable that for now by replacing this line: render_delegate.cpp · rC from #ifdef _WIN32 to #if 0. That should cause things to show up in Houdini on Windows too, instead of just getting an empty viewport.

I did some changes to make building on Windows easier:

  • Change default install directory to install/, so that multi config always installs files to the same directory regardless of build config
  • Install Hydra dll in install/hydra subdirectory, to make the directory layout a bit cleaner and be more consistent with the Houdini case
  • Init install prefix and build type to good defaults even when not using the make wrapper
  • Tweak build instructions to work for Windows, using a cmake command instead of BUILD_CMAKE_ARGS
  • Build with Visual Studio project files for make wrapper. Speeds up builds since NMake is single threaded, and gives a Visual Studio project to work with.

I can confirm that with the change suggested by @pmoursnv the viewport starts working.