So this is probably not the best forum to post this, but I thought I would ask anyway and see if I get any answers. I've been fiddling around with getting USD installed on my home Windows machine (yes I know the windows version is still experimental) and while I am able to get it to build at default settings, I haven't had any luck building it with the Houdini Plugin. Looking into the cmake files for the plugin it seems like the issue is that the file is designed with the Linux install of Houdini in mind (it's looking for .so files, it seems to think the dsolib is in the root install directory…). Currently the line that I think is the biggest culprit is this


I'm no cmake expert, but I think this is using “libHoudiniGEO.so” as a target to build a path to the dso library, not sure if this is a recursive find or if it just searches direct children of the root directory. However, since it seems that libHoudiniGEO.so doesn't exist in the Windows install, this fails. I tried changing it to look for libGEO.a instead since that seemed the most likely Windows equivalent in my mind, but it still failed.

Any one have any success doing this? Any cmake gurus out there? Anyone know what the Windows equivalent of libHoudiniGEO.so is? I've attached USD's FindHoudini.cmake file in case you want the full context without having to go to the git repo.

Did you ever resolve this, it's been a stop gap for my studio as well.

I made some steps using v18.09 and modifying some of the cmake files,

First Part, cmake/modules/FindHoudini.cmake
here it is trying to set the the HOUDINI_LIB_DIR based on where it could find the ‘libHoudiniGEO.so’ somwhere in the ${HOUDINI_ROOT} and a /dsolib folder, this is very much how the houdini structure is in linux

I had to change it so it looks for a ‘libGEO.lib’ inside the ‘custom/houdini/dsolib’ - folder for it to set the HOUDINI_LIB_DIR

Second Part , cmake/modules/FindHoudini.cmake
here It tries to find the houdiniAPPS1, houdiniAPPS2, HOUDINI_OP?, … libraries so the houdini plugins can link against them.
The problem is that libraries with these names do not exist in the windows installation, the are called slightly differently and it seems that you need more than the 15 specified in the FindHoudini.cmake to link with, for windows.
The list of all libraries to link against you can snatch from .cmake files shipped with houdini.

Third Part, third_party/houdini/lib/gusd/CMakeLists.txt
here is where the building and linking happens, and here is where one has to swap the ‘HOUDINI_??_LIBRARY’ - links from linux/osx against the ones for windows.

Forth Part third_party/houdini/CMakeLists.txt
here compiler definitions get set up, this has a lot of the linux flags still in there and none of the windows ones.
I've tried to extract what is needed from houdini from hcustom & the cmake files shipped with houdini.

The attached .diffs contain the changes I had to do, they attempt to leave the Building for Linux untouched, however i did not come around to test them yet.

Up to this point I managed to compile it and the only thing that i have not yet solved is getting the remaining 8 unresolved external symbols fixed (LNK2019, GusdXformWrapper, GusdDefaultArray).

I hope someone can shed some light with this one

Seb

Thanks a lot for the work on the USD for Houdini.
Did you request help in the Usd Google group?
And what about the Github USD page [github.com]?

I will try to help you in the next months

Yeah I'm on the Google group. They aren't much help to Windows Houdini guys it seems, but a recent post said it's possible to compile now that an incompatibility is gone in 16-16.5. Infernalspawn's post is a great help. Hopefully I should be able to crack this soon based on his insights.

eldiren
Yeah I'm on the Google group. They aren't much help to Windows Houdini guys it seems, but a recent post said it's possible to compile now that an incompatibility is gone in 16-16.5. Infernalspawn's post is a great help. Hopefully I should be able to crack this soon based on his insights.

Do you mean this post :
https://groups.google.com/forum/#!topic/usd-interest/23XmMOONKdI

Yes, I am also battling this and had gone down the same path you had (butchering up the cmake files to deal with the differences between a linux and windows houdini install). But it wasn't working, was frustrating and felt like I was trying to force some bastard version of Pixar's linux pipeline into working on windows (even though that's basically what the USD build system is).

I've started down an alternative approach of using Houdini's provided cmake config under the theory that I can build it like a regular plugin and just point it at the compiled usd libraries and then deal with python scripts, etc by hand.

I'm going to continue this on the usd-interest thread since there's more likely to be people that understand the USD cmake setup there.

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

For anyone not following along on usd-interest, we have success: https://groups.google.com/forum/# [groups.google.com]!topic/usd-interest/23XmMOONKdI

why not share the compiled plugins? not everyone is a programmer

+1

patar
why not share the compiled plugins? not everyone is a programmer

i guess this forum is not as helpful as it used to…

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

i would greatly appreciate compiled windows version too

Here's a windows compile of the pixar USD stuff for 17.0.352. stick it on your $HOUDINI_PATH somewhere.

i used this as a helpful guide - https://www.youtube.com/watch?v=3XiGnm6_Jvg&feature=youtu.be [www.youtube.com]
some tweaking of paths was necessary under my setup.

i don't think expecting every one to be able to compile plugins is reasonable. so, to be the change i wanna see in the world, here you go. but i offer no other support

cheers,
chrisg

I'm not sure if this is relevant, but there is now a project in the HDK samples to build the USD plugins which should work on all platforms (see $HFS/toolkit/usd_houdini_plugins).

The source provided there should match the same git version as the libraries shipped with Houdini.

I don't think it helps if you don't have a compiler environment though.

I've done a walk through of how to do this.

USD Houdini plugin Compile Win10 [tinyhawkus.com]



Cheers

Lewie