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 0 option
_stageMetersPerUnit is 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 _stageMetersPerUnit is 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.
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.
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.
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?