Hydra renderers tend to have a default dome light so that initial stages with no lights present are rendererable (See karma, renderman, etc). Once a light of any kind is added to the scene, the default dome light should go to black (unless an actual dome light is added)

This is partially implemented but at some point, the default dome light is not turning off properly....

Hi,
I'd like to test your plug-in, however am having trouble finding any instructions on how to get it working inside of houdini. Is there a read me somewhere with this I may have missed? I am currently using H18.5, and Blender 2.90.1

Thanks

It seems like in cases of big scenes Cycles emits nanosleep signal on Linux. Constant locking and unlocking, during Sync stage slows down Cycles significantly.

-   15.15%    15.15%  husk     hdCycles.so                          [.] Normalize                                                                                                                                                        
     3.62% 0x854800000198828b                                                                                                                                                                                                            
      + pxrInternal_v0_20__pxrReserved__::mikk_get_num_verts_of_face                                                                                                                                                                     
-   14.10%    14.10%  husk     hdCycles.so                          [.] genTangSpace                                                                                                                                                     
   + 2.99% 0x854800000198828b                                                                                                                                                                                                            
     1.49% genTangSpace                                                                                                                                                                                                                  
   + 0.64% 0                                                                                                                                                                                                                             
-   13.65%     0.00%  husk     [unknown]                            [.] 0000000000000000                                                                                                                                                 
   - 0                                                                                                                                                                                                                                   
        4.96% tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::receive_or_steal_task                                                                                                                                
        1.34% __sched_yield                                                                                                                                                                                                              
        1.31% embree::sse2::BVHNIntersector1<4, 1, true, embree::sse2::ArrayIntersector1<embree::sse2::TriangleMiIntersector1Pluecker<4, 4, true> > >::intersect                                                                         
        0.81% embree::sse2::CreateMortonLeaf<4, embree::TriangleMi<4> >::operator()                                                                                                                                                      
        0.64% genTangSpace                                                                                                                                                                                                               
        0.62% embree::sse2::InstanceIntersector1::intersect    

This can be solved by Introducing HdResourceRegistry with HdAttributeSource for deferred object and attributes committing to Cycles.

Need to link against embree libs

Currently experimental support for xform based motion blur is available.

We need to add:

• More stable time sampeled xform motion blur
• Support for other imageable time sampeled xform motion blur
• Deforming mesh motion blur
• Velocity based motion blur

It should be possible to allow cycles to render via tiles for interactive and offline renders.

Cycles does not support corner normals. We are adding support to the cycles repo directly, and will subsequently need to add support to populate these in HdCycles.

Currently when you specify different visibility flags to objects in Solaris, the viewport will update this state however if you set these controls to "Do Nothing" (essentially removing the attributes from the schema) the viewport doesn't revert back to the Cycles defaults and just sticks to the last thing that it was set to.

However, when re-loading the scene from a fresh Houdini instance or rendering to husk it'll do the right thing, as the defaults are there from a fresh initialisation. I am wondering now if this is just for visibility flags, or that hdcycles might need to have a way to always fallback to defaults for all settings.

Curve geometry (often used and labeled as "guide") crashes HdCycles/Houdini.
The reason seems to be that the Cycles object is initialized and added to the scene but no geometry is ever bound to it, while Cycles expects it.

Internal ticket #5628

To allow the selection of imageable primitives in an interactive session, aov's must be properly implemented.

Requires #14 to be implemented first

There are apparently issues with curves being clipped under certain situations. Will report with more information.

Internal issue #CD-88

Need to link with embree libs

• Make subdivision more reliable
• Add support for dicing cameras (will require custom usdCycles schema)
• Add per object dicing amounts (usdCycles schema)

Currently Cycles USDShadeShader nodes are identified by the info:id identifier. This is expected to have the prefix cycles: which is, technically a valid TfToken, however is also technically an illegal identifier.

This wasn't causing too many issues yet, however completely broke the Houdini Edit Material LOP node. (And potentially lots of other things).

We will be switching to use the prefix cycles_ instead of cycles:. This change will make it into version 0.8.0.

Our internal Blender USD Export has also received this change. To try and mitigate some of the damage on breaking existing shader networks, support for reading materials with the cycles: prefix is still allowed, however has been marked as deprecated and will be removed in the future.

Sorry for letting this slip through until now!

It used to, something has regressed.

https://graphics.pixar.com/usd/docs/api/class_usd_lux_shadow_a_p_i.html

We will likely need to remove these options from the usdCycles api to avoid duplicates...

Basic support is added in this branch: https://github.com/tangent-opensource/hdcycles/tree/feature/panoramic_camera

Few missing features before PR ready.

We rely on usdcycles schema for knowing if a camera should be panoramic. Ideally we would override the UsdGeomCamera projection attribute, however this seems harder to override in Houdini and should really be extended via USD schema plugin. We could do this in usdCycles, however would require some rnd.

To properly support cycles rendering from a USD document, we must implement a custom USD schema to bridge the gap.

The result of this will be a separate open sourced repository which defines the custom schema for usdCycles.

It will be possible to build hdCycles without the schema, but 1:1 rendering support will not be possible.

More information to come.

Hello,
Normally the installation instructions are above the compile instructions.
Most users visitors only need to install the releases.

I had a different req first but I just didn't properly rtfrm.

This will involve the reading of UsdVolOpenVDBAsset's and support for volumetric Cycles materials.

We currently don't properly handle curves of different types, wraps properly

https://graphics.pixar.com/usd/docs/api/class_usd_geom_basis_curves.html#details

Hello,
I'm trying to build hdcycles on PopOS! 20.04
Build seems to go well, all the dependencies are found, but then I get this:

-- Configuring done
CMake Warning at cmake/macros/Private.cmake:1130 (add_library):
  Cannot generate a safe runtime search path for target ndrCycles because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libtbbmalloc.so.2] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /media/colin/ssd/apps/HdCycles/deps/USD-19.11-build/lib
    runtime library [libtbb.so.2] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /media/colin/ssd/apps/HdCycles/deps/USD-19.11-build/lib

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  cmake/macros/Public.cmake:288 (_pxr_library)
  cmake/macros/Public.cmake:327 (pxr_library)
  plugin/ndrCycles/CMakeLists.txt:30 (pxr_plugin)


CMake Warning at cmake/macros/Private.cmake:1130 (add_library):
  Cannot generate a safe runtime search path for target hdCycles because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libtbbmalloc.so.2] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /media/colin/ssd/apps/HdCycles/deps/USD-19.11-build/lib
    runtime library [libtbb.so.2] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /media/colin/ssd/apps/HdCycles/deps/USD-19.11-build/lib

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  cmake/macros/Public.cmake:288 (_pxr_library)
  cmake/macros/Public.cmake:327 (pxr_library)
  plugin/hdCycles/CMakeLists.txt:30 (pxr_plugin)


-- Generating done

and the build of hdCycles and ndrcycles plugins does not finish.

Any idea what my problem might be ?
Thanks a lot.

(full terminal output attached)
terminal.txt

Would be nice for development iteration time if cmake install wasn't required to have files placed on disk in a structure that could be loaded. Especially in Visual Studio where Install is an additional command must be run.

This could be fixed relatively easily by configuring the pluginfo into a resource folder.

Install would still work, but wouldn't be as necessary.

Allow arbitrary AOV's from Cycles render.

This will also likely require custom usdCycles schema.

It seems like instancing code is not working with Kitchen Set. We should re-visit the code.

Would it be possible to provide pre-built binaries for releases?

If there is some interest, I might be able to start creating a small Github Actions CI pipeline to get started. Actions is free for open source repos.

Time varying attributes - transforms, positions, normals or others we will need in the future - are sampled inconsistently and I think they should go behind the same interface similarly to HdCyclesSetTransform .

• You make no assumptions about the samples/times are received
• You approximate the input using a (configurable) number of samples which linearly interpolates them and formats them as Cycles like.

IMHO, this is something that should go inside Cycles and exposed through something like set_timevarying_attributes(times, samples).

I would say this has less priority than making the Sync process more parallel.

I'm trying to build this and can't seem to get past this error
I built cycles separately and USD and those work, not sure why is failing to build USD when I run your build script, well cmake,
Am I missing something here?

This is on Windows

Thanks

`Adding boost_python dependencies: headers
CMake Error at E:/apps/USD/lib/cmake/Boost-1.70.0/BoostConfig.cmake:95 (find_package):
Could not find a package configuration file provided by "boost_thread"
(requested version 1.70.0) with any of the following names:

boost_threadConfig.cmake
boost_thread-config.cmake`

Resizing the houdini viewport typically causes the previous frame to be rendered stretched (nearest neighbor) before the new frame begins to be blit.

The stretched image can be replaced by a solid background or similar in here

I made a more general issue cause I this is going to take some time to get working

after a while I got cmake to generate a solution but now I have ton of linking errors, mostly I think are coming from OIIO
my cmake command got really complicated also, maybe I am doing something wrong

cmake -DUSD_ROOT="P:/HDCycles/USD" -DCYCLES_ROOT="P:/HDCycles/cycles" -DCYCLES_LIBRARY_DIR="P:/HDCycles/cycles/build/lib/Release" -DCYCLES_INCLUDE_DIRS="P:/HDCycles/cycles/src" -DBOOST_ROOT="E:/apps/boost_1_65_1/lib64-msvc-14.1" -DBOOST_LIBRARYDIR="E:/apps/boost_1_65_1/lib64-msvc-14.1" -DOPENJPEG_LIBRARY="P:/HDCycles/lib/win64_vc15/openjpeg/lib/openjp2.lib" -DOPENJPEG_INCLUDE_DIR="P:/HDCycles/lib/win64_vc15/openjpeg/include" -DJPEG_LIBRARY="P:/HDCycles/lib/win64_vc15/jpeg/lib/libjpeg.lib" -DJPEG_INCLUDE_DIR="P:/HDCycles/lib/win64_vc15/jpeg/include" -DPNG_LIBRARY="P:/HDCycles/lib/win64_vc15/png/lib/libpng.lib" -DPNG_PNG_INCLUDE_DIR="P:/HDCycles/lib/win64_vc15/png/include" -DTIFF_LIBRARY="P:/HDCycles/lib/win64_vc15/tiff/lib/libtiff.lib" -DTIFF_INCLUDE_DIR="P:/HDCycles/lib/win64_vc15/tiff/include" -DOIIO_BASE_DIR="P:/HDCycles/lib/win64_vc15/OpenImageIO" -DOIIO_INCLUDE_DIRS="P:/HDCycles/lib/win64_vc15/OpenImageIO/include" -DOIIO_LIBRARIES="P:/HDCycles/lib/win64_vc15/OpenImageIO/lib/OpenImageIO.lib" -DOPENVDB_INCLUDE_DIR="P:/HDCycles/lib/win64_vc15/openvdb/include" -DOPENVDB_LIBRARY="P:/HDCycles/lib/win64_vc15/openvdb/lib/openvdb.lib" -DCYCLES_LIBRARIES="P:/HDCycles/cycles/build/lib/Release/cycles_render.lib" ..

after that a solution is generated and I get all this linking errors

6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: static char const * __cdecl Imf_2_4::TypedAttribute<double>::staticTypeName(void)" (?staticTypeName@?$TypedAttribute@N@Imf_2_4@@SAPEBDXZ) referenced in function "public: virtual char const * __cdecl Imf_2_4::TypedAttribute<double>::typeName(void)const " (?typeName@?$TypedAttribute@N@Imf_2_4@@UEBAPEBDXZ) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: __cdecl Imf_2_4::OutputPart::OutputPart(class Imf_2_4::MultiPartOutputFile &,int)" (??0OutputPart@Imf_2_4@@QEAA@AEAVMultiPartOutputFile@1@H@Z) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_1::OpenEXROutput::open(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class OpenImageIO_v2_1::ImageSpec const &,enum OpenImageIO_v2_1::ImageOutput::OpenMode)" (?open@OpenEXROutput@OpenImageIO_v2_1@@UEAA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBVImageSpec@2@W4OpenMode@ImageOutput@2@@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: void __cdecl Imf_2_4::OutputPart::setFrameBuffer(class Imf_2_4::FrameBuffer const &)" (?setFrameBuffer@OutputPart@Imf_2_4@@QEAAXAEBVFrameBuffer@2@@Z) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_1::OpenEXROutput::write_scanline(int,int,struct OpenImageIO_v2_1::TypeDesc,void const *,__int64)" (?write_scanline@OpenEXROutput@OpenImageIO_v2_1@@UEAA_NHHUTypeDesc@2@PEBX_J@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: void __cdecl Imf_2_4::OutputPart::writePixels(int)" (?writePixels@OutputPart@Imf_2_4@@QEAAXH@Z) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_1::OpenEXROutput::write_scanline(int,int,struct OpenImageIO_v2_1::TypeDesc,void const *,__int64)" (?write_scanline@OpenEXROutput@OpenImageIO_v2_1@@UEAA_NHHUTypeDesc@2@PEBX_J@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: static char const * __cdecl Imf_2_4::TypedAttribute<class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > >::staticTypeName(void)" (?staticTypeName@?$TypedAttribute@V?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Imf_2_4@@SAPEBDXZ) referenced in function "public: virtual char const * __cdecl Imf_2_4::TypedAttribute<class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > >::typeName(void)const " (?typeName@?$TypedAttribute@V?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Imf_2_4@@UEBAPEBDXZ) 6>OpenImageIO.lib(exroutput.obj) : error LNK2001: unresolved external symbol "public: virtual void __cdecl Imf_2_4::TypedAttribute<class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > >::writeValueTo(class Imf_2_4::OStream &,int)const " (?writeValueTo@?$TypedAttribute@V?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Imf_2_4@@UEBAXAEAVOStream@2@H@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2001: unresolved external symbol "public: virtual void __cdecl Imf_2_4::TypedAttribute<class std::vector<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::allocator<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > >::readValueFrom(class Imf_2_4::IStream &,int,int)" (?readValueFrom@?$TypedAttribute@V?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@@Imf_2_4@@UEAAXAEAVIStream@2@HH@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: __cdecl Imf_2_4::TiledOutputPart::TiledOutputPart(class Imf_2_4::MultiPartOutputFile &,int)" (??0TiledOutputPart@Imf_2_4@@QEAA@AEAVMultiPartOutputFile@1@H@Z) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_1::OpenEXROutput::open(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class OpenImageIO_v2_1::ImageSpec const &,enum OpenImageIO_v2_1::ImageOutput::OpenMode)" (?open@OpenEXROutput@OpenImageIO_v2_1@@UEAA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBVImageSpec@2@W4OpenMode@ImageOutput@2@@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: void __cdecl Imf_2_4::TiledOutputPart::setFrameBuffer(class Imf_2_4::FrameBuffer const &)" (?setFrameBuffer@TiledOutputPart@Imf_2_4@@QEAAXAEBVFrameBuffer@2@@Z) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_1::OpenEXROutput::write_tiles(int,int,int,int,int,int,struct OpenImageIO_v2_1::TypeDesc,void const *,__int64,__int64,__int64)" (?write_tiles@OpenEXROutput@OpenImageIO_v2_1@@UEAA_NHHHHHHUTypeDesc@2@PEBX_J22@Z) 6>OpenImageIO.lib(exroutput.obj) : error LNK2019: unresolved external symbol "public: void __cdecl Imf_2_4::TiledOutputPart::writeTiles(int,int,int,int,int,int)" (?writeTiles@TiledOutputPart@Imf_2_4@@QEAAXHHHHHH@Z) referenced in function "public: virtual bool __cdecl OpenImageIO_v2_1::OpenEXROutput::write_tiles(int,int,int,int,int,int,struct OpenImageIO_v2_1::TypeDesc,void const *,__int64,__int64,__int64)" (?write_tiles@OpenEXROutput@OpenImageIO_v2_1@@UEAA_NHHHHHHUTypeDesc@2@PEBX_J22@Z) 6>OpenImageIO.lib(imagebufalgo_xform.obj) : error LNK2019: unresolved external symbol "public: virtual __cdecl Iex_2_4::MathExc::~MathExc(void)" (??1MathExc@Iex_2_4@@UEAA@XZ) referenced in function "public: virtual void * __cdecl Iex_2_4::MathExc::scalar deleting destructor'(unsigned int)" (??_GMathExc@Iex_2_4@@UEAAPEAXI@Z)
6>OpenImageIO.lib(texturesys.obj) : error LNK2001: unresolved external symbol "public: virtual __cdecl Iex_2_4::MathExc::~MathExc(void)" (??1MathExc@Iex_2_4@@UEAA@XZ)
6>OpenImageIO.lib(imagebufalgo_xform.obj) : error LNK2019: unresolved external symbol "public: __cdecl Imath_2_4::SingMatrixExc::SingMatrixExc(char const *)" (??0SingMatrixExc@Imath_2_4@@qeaa@PEBD@Z) referenced in function "public: class Imath_2_4::Matrix33 __cdecl Imath_2_4::Matrix33::inverse(bool)const " (?inverse@?$Matrix33@M@Imath_2_4@@qeba?AV12@_N@Z)
6>OpenImageIO.lib(texturesys.obj) : error LNK2001: unresolved external symbol "public: __cdecl Imath_2_4::SingMatrixExc::SingMatrixExc(char const *)" (??0SingMatrixExc@Imath_2_4@@qeaa@PEBD@Z)
6>OpenImageIO.lib(imagebufalgo_xform.obj) : error LNK2019: unresolved external symbol "public: virtual __cdecl Imath_2_4::SingMatrixExc::~SingMatrixExc(void)" (??1SingMatrixExc@Imath_2_4@@UEAA@XZ) referenced in function "public: virtual void * __cdecl Imath_2_4::SingMatrixExc::scalar deleting destructor'(unsigned int)" (??_GSingMatrixExc@Imath_2_4@@UEAAPEAXI@Z) 6>OpenImageIO.lib(texturesys.obj) : error LNK2001: unresolved external symbol "public: virtual __cdecl Imath_2_4::SingMatrixExc::~SingMatrixExc(void)" (??1SingMatrixExc@Imath_2_4@@UEAA@XZ) 6>P:\HDCycles\hdcycles\build\plugin\hdCycles\Release\hdCycles.dll : fatal error LNK1120: 217 unresolved externals 6>Done building project "hdCycles.vcxproj" -- FAILED. 7>------ Build started: Project: ALL_BUILD, Configuration: Release x64 ------ 7>Building Custom Rule P:/HDCycles/hdcycles/CMakeLists.txt ========== Build: 6 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

just a small sample, will add the oiio libs manually in VS but I'm thinking I might be complicating this too much because I never compile stuff on windows

thanks for any pointers 😆 pointers!!

Here comes the bug reports 🐛
Loading an hdri in the dome light is offset by -90 degrees in the X axis

Unknown if this works with the USD/Hydra pardigm. It seems like we can support it through render settings and render products. But could produce strange results for interactive renders in Houdini.

Started some work here: https://github.com/tangent-opensource/hdcycles/tree/feature/baking

I've added the appropriate schema to usdCycles for the next release. No harm in adding it for future use. But if this is deemed impossible, we should probably remove it

Thought I'd log it here as an issue:

The current blitting code has a few issues, notably it looks as though there are too many branch checks at the pixel-level where we could refactor the branches at the whole image/tile level and win back performance, as these checks are mostly for determining conversion to/from types that don't change per-pixel on an image.
https://github.com/tangent-opensource/hdcycles/blob/main/plugin/hdCycles/renderBuffer.cpp#L32

The other issue is that currently I think single channel buffers are not blitting right, this is a screenshot of the depth pass at the screen edge (using BlitTile function):

Cheers

The motion blur code in HdCyclesMesh uses a fixed number of motion steps HD_CYCLES_MOTION_STEPS for both transformation and deformation blur. Deformation blur is also always turned on which could results in additional copies of the mesh as the points are not tested to be time varying before they are sampled and copied to the Cycles mesh. The code mentions that it depends on the Schema PR, maybe we can wait for that to clear up the logic.

Changing it requires a bit of refactoring. Are there possible complications to changing it?

Hey guys,

I finally got to compile hdCycles on Windows, it's pretty sweet, and seems pretty responsive already ! I was wondering where the schema's were ? The link on the build instructions points to a usdCycles github repo, but that looks like a dead link.

Thanks !

The world grid overlay in Houdini overlaps the rendering output. I would guess the depth buffer needs to accessible to Houdini to correctly compose the two images.
There also seems to be some weird transparency going on, unsure if it's caused by the grid overlay though.

Would be nice to fix, though not an high priority.

Hi,

I am trying to run hdCycles under Ubuntu20.04 with USD20.08 and the current version of cycles (master branch).
Everything compiles without any problems but when I try to activate hdCycles in usdview I get the following error:

'Failed to load plugin 'hdCycles': /home/sherholz/USD20.08-local/plugin/usd/hdCycles.so: undefined symbol: _ZN3ccl9BVHParams15best_bvh_layoutENS_15KernelBVHLayoutEi in '/home/sherholz/USD20.08-local/plugin/usd/hdCycles.so''

As described in the documentation I compiled cycles with the:

-DCMAKE_POSITION_INDEPENDENT_CODE=ON

option turned on.
Plotting the linking command for hdCycles it looks like the corresponding cycles libraries are linked correctly:

[ 72%] Linking CXX shared library hdCycles.so
cd /home/sherholz/Develop/hdcycles/build/plugin/hdCycles && /usr/bin/cmake -E cmake_link_script CMakeFiles/hdCycles.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -std=c++11 -Wall -Wno-deprecated -Wno-deprecated-declarations -Wno-unused-local-typedefs -O3 -DNDEBUG -shared -Wl,-soname,hdCycles.so -o hdCycles.so CMakeFiles/hdCycles.dir/Mikktspace/mikktspace.c.o CMakeFiles/hdCycles.dir/basisCurves.cpp.o CMakeFiles/hdCycles.dir/camera.cpp.o CMakeFiles/hdCycles.dir/instancer.cpp.o CMakeFiles/hdCycles.dir/light.cpp.o CMakeFiles/hdCycles.dir/material.cpp.o CMakeFiles/hdCycles.dir/mesh.cpp.o CMakeFiles/hdCycles.dir/points.cpp.o CMakeFiles/hdCycles.dir/renderDelegate.cpp.o CMakeFiles/hdCycles.dir/rendererPlugin.cpp.o CMakeFiles/hdCycles.dir/renderPass.cpp.o CMakeFiles/hdCycles.dir/renderParam.cpp.o CMakeFiles/hdCycles.dir/config.cpp.o CMakeFiles/hdCycles.dir/renderBuffer.cpp.o CMakeFiles/hdCycles.dir/utils.cpp.o -Wl,-rpath,/home/sherholz/USD20.08-local/lib::::::::::::::::::...
...
...
/home/sherholz/Develop/cycles/build/lib/libcycles_bvh.a /home/sherholz/Develop/cycles/build/lib/libcycles_device.a /home/sherholz/Develop/cycles/build/lib/libcycles_graph.a /home/sherholz/Develop/cycles/build/lib/libcycles_kernel.a /home/sherholz/Develop/cycles/build/lib/libcycles_render.a /home/sherholz/Develop/cycles/build/lib/libcycles_subd.a /home/sherholz/Develop/cycles/build/lib/libcycles_util.a /home/sherholz/Develop/cycles/build/lib/libextern_clew.a /home/sherholz/Develop/cycles/build/lib/libextern_cuew.a /home/sherholz/Develop/cycles/build/lib/libextern_numaapi.a
...
...

Any ideas or am I missing something essential?

This is primarily needed in the new hair rendering workflow. We won't necessarily add support for old curves in this issue.

Because of the restriction of Cycles, we cannot have vertex varying attributes on Curves (ccl::Hair). For now we will grab the value from the root. It is preferable to use Uniform varying primvars for Curves

When no widths are applied, the curve renders incorrectly

When using a render settings node with at least session:samples and background:transparent set, houdini becomes pretty unusable.

This could be related to render stats.

Need to link against OSL libs

In hdcycles symbol visibility is controlled by custom HdCycles definitions. We should rely on the original HD_API.

Currently, each primitive locks the scene mutex during the Sync method to write new values, making primitive syncing pretty much sequential. I can think of two ways to optimize it:

1. Minimize the time spent in the lock for each primitive. Instead of reading, processing and writing the primitive data inside the lock, we could separate the reading/processing to be thread free and lock only when updating the Cycles geometry buffers.
2. Provide further synchronization mechanism to guarantee that committing resources to the device has finished before new primitives are being synced.

The former seems to most reasonable solution, there are lots of edge cases for 2., especially when running on top of "opaque" execution engine.

To provide evidence of the problem... Scrolling quickly through the usdview timeline without scene locks for each primitive Sync can result in the previous frame still committing resources (as it runs in a separate session thread) while new primitives are being synced causing data races and exceptions during Session::update_scene .

It's not something of the highest priority, but we should probably look to start the discussion.

Houdini viewport sometimes crashes on resizing, this is because the display buffer is internally resized by cycles while the pixels are copied.

Accessing the display buffer needs to follow the same synchronization pattern used internally by the Cycles session.
Fixed currently in this branch, will create a PR after a bit more testing.

The following white papers are required to be implemented into the core of USD to allow proper support for this:

• http://graphics.pixar.com/usd/docs/Adapting-UsdLux-to-the-Needs-of-Renderers.html
• http://graphics.pixar.com/usd/docs/Generalizing-Connectable-Nodes-Beyond-UsdShade.html

Scene parameters are not supporting texture limits yet.

In Cycles, ATTR_STD_FACE_NORMAL is not used for shading, the only way to specify face normals is to enable the geometric normal to be used through the smooth boolean. Alternatively, you can use the same custom normal for each corner in a triangle through ATTR_STD_CORNER_NORMAL but it requires 3x the memory.

We currently use corner normal to better comply with USD's uniform interpolation.

Did I misunderstand something in the Cycles code? How common is this use case, does it justify requiring support for custom face normals?