Infernalspawn

Infernalspawn

About Me

Connect

LOCATION
Not Specified
ウェブサイト

Houdini Engine

Availability

Not Specified

Recent Forum Posts

Compiling the Pixar USD Houdini plugin on Windows 2018年11月1日18:29

patar
i guess this forum is not as helpful as it used to…
I guess it was, especially when it had people with a smaller sense of entitlement

Soho & Progress Bar 2018年10月22日15:56

Hi,

i could not find anything regarding soho-writer & progress bars for an individual process ?
Is there a way to report the progress via the soho-code ?

My soho-node does some complex move & verify operations and it would be cool to let the user know what the process did not just hang

Cheers
Seb

Compiling the Pixar USD Houdini plugin on Windows 2018年9月7日5:29

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 explicitly

5th 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_API

6th Part, third_party/houdini/lib/gusd/xformWrapper.h (xformWrapper.diff):
- some methods need to be made available when linking hence adding GUSD_API for _dllexport

7th 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

Seb