Infernalspawn

Infernalspawn

About Me

Connect

LOCATION
Not Specified
WEBSITE

Houdini Skills

Availability

Not Specified

Recent Forum Posts

Compiling the Pixar USD Houdini plugin on Windows Nov. 1, 2018, 6:29 p.m.

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 Oct. 22, 2018, 3:56 p.m.

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 Sept. 7, 2018, 5:29 a.m.

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