I found them in here:
C:\HydraDelegates\Cycles\builddel\src\hydra\resources
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
https://wiki.blender.org/wiki/Building_Blender/CyclesHydra
but as i mentioned above i get an empty solaris viewport when choosing cycles…
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 
then the empty viewport seems to be a windows build thing…
@EstebanCovo my folder structure is like that:
..\cycles\build\bin\Release\houdini\dso\usd_plugins\hdCycles.dll
..\cycles\build\bin\Release\houdini\dso\usd_plugins\plugInfo.json
..\cycles\build\bin\Release\houdini\dso\usd_plugins\hdCycles\resources\plugInfo.json
..\cycles\build\bin\Release\houdini\packages\cycles.json
plugInfo.json
{
"Plugins": [
{
"Info": {
"Types": {
"HdCyclesPlugin": {
"bases": [
"HdRendererPlugin"
],
"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_CMAKE_ARGS=
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/make_update.py
) else if "%COMMAND%" == "format" (
%PYTHON% src/cmake/make_format.py
) 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.
First of all good job on updating the build system for the delegate.
I experimented with the Hydra delegate today and got it running on some test scenes.
Here are some of my observations:
- hdCycles does not build with Houdini 18.5.* (i.e., USD v20.08)
- the minimum USD version is 21.03 (this introduces HdMaterialNetwork2)
- the when building against plain USD the minimal supported version is 21.11 since this adds the
--use-cxx11-abi 0option -
_stageMetersPerUnitis set to 0.01 by default. This breaks lighting since the scene is rescaled but not the light parameters (which are usually in radiance). Is there a reason why_stageMetersPerUnitis not 1.0 or why the scene scale needs to be adjusted in the first place?
*the environment map is wrongly oriented (the horizon is rotated by 90 deg)
*when there is no envmap there seems to be always a white/gray constant background light
I will post some renderings and comparisons to Karma later.
Is there a plan for some validation tests against publicly available USD scenes like
ALab, Moana, Sponza?
Thanks for the details on the minimum USD and Houdini versions. I added those to the building docs now.
I also noticed various incompatibilities with lighting (and camera DoF.) It seems there is a problem in Blender’s USD exporter at least, see:
https://developer.blender.org/D14630#394344
Getting this validated with various public scenes and Blender exported scenes is certainly something we should do. Not sure when I or someone else will get to it, but it’s probably the most important thing to fix now.
@pmoursnv would know more about the reasons for _stageMetersPerUnit.
@brecht No problem.
I think it would make sense to try adding support for at least USD v20.08.
The main thing which needs to be implemented is the support for the old MaterialNetwork,
which shouldn’t be so hard. This would allow using Houdini 18 and the ALab scene.
From my experiences, Houdini Solaris and the Karma renderer are currently the best way to validate a delegate, since Solaris is able to generate -pure- USD scenes and Karma renders them pretty strict to the USD definition (i.e., since Karma is written around USD).
If I find some time I can help with some of the delegate work.
Especially when it comes to validating and setting up the lighting and material (i.e., USDPreviewShader) part.
@brecht thx for the update…
windows build, houdini 19.0.561:
-i get again the empty solaris viewport…this is not fixed for windows, right?
-with usdrender node in “out” i get some rendering in mplay, but as @sherholz mentioned the env rotation matrix is wrong…
-the usdpreviewsurface supports only diffuse color at the moment, right? (cant see any reflections yet)…
edit: oh missed that #if 0 hack from @pmoursnv. have to try…
ok, the #if 0 hack in render_delegate.cpp works now and the solaris viewport is no longer empty. but the material doesnt refresh when changing parameters, only when switching forth and back between karma and cycles…
also opacity with refraction seems not to work properly in the usdpreviewsurface material…
@brecht The DoF issue is also happening because the Blender USD exporter currently always writes out “focalLength”, “horizontalAperture” and “verticalAperture” in millimeters, but the spec declares those as “tenths of a scene unit”. Since the scene unit is set to meters (“metersPerUnit” is 1), rather than the USD default of centimeters, these should be in decimeters instead. With that changed in the USD file (simply multiplied the values by 0.01 and saved again), DoF starts behaving correctly.
Based on a comment in the relevant exporter code (usd_writer_camera.cc · rB) this was intentionally done though because usdview was misbehaving … So not sure how that is best addressed. But I’ll mention these things to Michael who’s been working on the USD importer/exporter.
@sherholz I had it building against a modified USD 20.08 fork that cherry-picked HdMaterialNetwork2, hence the comment about 20.08 working with some limitations in the original patch, but that’s not particularly useful for anybody else of course =P
_stageMetersPerUnit is set to 0.01 by default since that is the USD default (centimeters), whereas Blender/Cycles generally operates in meters. It is expected that the Hydra application overrides that to the USD metersPerUnit metadata value via the provided render setting, like Houdini does. This was necessary since light parameters are not scaled by Hydra, but the Blender USD exporter from the “universal-scene-description” branch (https://developer.blender.org/diffusion/B/history/universal-scene-description) supports exporting USD in either meters (metersPerUnit = 1) or centimeters (metersPerUnit = 0.01) and rendering the latter would thus look different even though they should look the same.
I’m guessing the environment is wrongly oriented because the render delegate is currently assuming a Z up axis (as that is what USD exported from Blender is using), so won’t behave right if the rendered USD is using a Y up axis (which is the default). This could probably be solved with another render setting.
had a look at the …/hydra/material.cpp and i see that the “opacity” of a usdpreviewsurface is mapped to the “alpha”…
karma treats “opacity” as refraction/transmission.
shouldnt it be mapped to something like “transmission”?
Kind of. I am currently investigating this.
The problem here is that opacity does not directly map to transmission, 1-opacity does.
Before:
After:
The latter one also has some changes to the light parameters to match Karma but is still WIP.
The main problem is that textured opacity requires us to set up some additional node system.
@brecht the black areas are caused by self-intersection the wall and the background plane of the shelf are exactly on top of each other.
Ideally, we will end up in something like this:
Hello,
I am working on the integration of Cycles in our 3D application using the Hydra render delegate and the USD format. It works quite well.
I made some small fixes in the hydra folder that I would like to submit to be added in the official repo.
@brecht, are you a reviewer for the pull requests? Or should I ask to someone else?
Best regards,
Nicolas
7 Likes
Yes, you can add me as reviewer. I can add additional reviewers when needed.
6 Likes
It doesn’t seem like roughness or IOR works with both USD Preview surface or MaterialX surfaces using Houdini 19.5 on macOS with M2 Max