Ok, some progress was made. I have got it so far that via ‘hython’ the compiled nodes (usdcamera, usdimport, usdunpack, …) can be created.
However houdini itself does not start due to a ‘This Application has requested the Runtime to terminate in a unusal way. Please contact the application’s support team for more information' with a error message
–> ‘Fatal Python error: PyThreadState_Get: no current thread’.
Why this error is happening in the UI and not in hython, i dont know.
I hope the hive-mind can help figure that out.
here are the steps: 1st & 2nd, cmake/modules/FindHoudini.cmake (FindHoudini.diff)
(same as before) 3rd Part, third_party/houdini/lib/gusd/CMakeLists.txt (houdini_CMakeLists.diff)
(same as before) 4th Part third_party/houdini/CMakeLists.txt (houdini_gusd_CMakeLists.diff)
- for the building of the houdini-plugins some flags where missing, neccessary for building on windows explicitly5th Part, third_party/houdini/lib/gusd/defaultArray.h (defaultArray.diff)
- the GusdDefaultArray is a Template, and does not need to be _dllexport(ed) as it is header-only, hence removing the GUSD_API6th Part, third_party/houdini/lib/gusd/xformWrapper.h (xformWrapper.diff):
- some methods need to be made available when linking hence adding GUSD_API for _dllexport7th Part: third_party/houdini/lib/gusd/wrapStageEdit.cpp (wrapStageEdit.diff)
- thanks to Liam on usd-interest for finding the solution to the getPointer() problem (https://stackoverflow.com/questions/38261530/unresolved-external-symbols-since-visual-studio-2015-update-3-boost-python-link
- adding 2 explicit conversion to pointer () - methods 8th Part: third_party/houdini/lib/gusd/stageEdit.h (stageEddit.diff)
- changes in wrapStageEdit.cpp, lead to some challenges as the GusdStageEdit - class is abstract due to some pure-virtual methods ( operator==, GetHash),
- i am not sure if there is a different/better solution than to actually implement these functions with some dummy code, but that is what seemed to have worked for me.9th Part: … libraries
- the whole USD project uses & generates a bunch of different .dll, one needs to make sure that all of them are available when houdini starts.
- for me that ment that all USD - lib-folders are added the %PATH% (%USD_ROOT%\lib & %USD_ROOT%\third_party\houdini\lib)
- adding the usd-python-libs to %PYTHONPATH% (%USD_ROOT%\lib\python)
- as well as making sure houdini finds all the bits and pieces (otls, .dlls etc) adding (%USD_ROOT%\third_party\houdini) to %HOUDINI_PATH%
- and updating %HOUDINI_DSO_PATH% to (@/dso_^;@/dso;@/plugin) - so it finds the OP_gusd.dll in the /plugin
and not to forget directories to the third-party libs you might be using (glew32.dll, tbb.dll, boost_filesystem, boost_python, boost_regex, boost_system, ….) in the %PATH%
… lets hope this helps someone so we can make some new steps