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

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

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

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

Hi,

has anyone found a way to generate a rib from a single SOP - Node,
but instead of having just a single Geometry-Object in the rib, having multiple ones, e.g. defined through a group or a attribute.

a bit like the partition-sop but on rib-gen time.

Cheers!
Seb

i'm not sure if it is possible to get a 100% match.
tried it with mantra and prman and it never worked 100%

the route we went were either:
–> creating a deep shadow map from other renderer
–> accessing this dsm inside the mantra-shader and use this as hold-out

or you write out deep data (exr2) from mantra and vray and deep comp them
that should remove the need of matching mblur for holdout reasons

sorry mate, but you're infos are very sparse, it would be the same as if i would ask someone why my computer is not working.

are you on linux/osx/win ?
where is your plugin installed to ? is this in the DSO - search path ?
do you have dependencies to external libraries other than houdini-libs ?


etc… etc..

what have you tried ? and what did not work ?

not sure about your mantra-node and about Indie, but could it be that your mantra node is generating a IFD file when you press the render button ?


Seb

what kind of plugin is it ?
a SOP node ? a VEX expression ?

with sop nodes you could do a
'dsoinfo -q -s' to check for loaded sop plugins

for vex and mantra the procedure is different.

Seb

The general advantage of vex is its SIMD structure.
All points are processed in parallel, and you have no way to access the results of the vex-calculation of a neighbouring particle in the same vex sop.

This makes it hard to solve the problem you want to solve, as another point may already have claimed the closest point to your current point.

Therefore making a list of closest points and storing them in a array on a point is something that can be done in vex as this is can be done in parallel.
The next step could be done in python, as you have access to all the points at once and their lists of closest points.

The problem could be, depending on how long your list of stored points is
You might end up with points that have no ‘buddy’ as all points in their lists were claimed by other points.
Then you could either increase the list size or, rerunn the list generation on the points that have an not yet found their buddy.


Cheers Seb

Its hard to do in vex, you can doit using a combination of vex and python.

Via vex you search a list of closest points, in python you do the checking which points are already in use.

I have written a sop node (c++)hat does what you want i think.
Have a look here https://gitorious.org/buddy-sop/buddy-sop [gitorious.org]


Cheers Seb

you can run a doxygen on the houdini-includes yourself and your pretty much covered

you can add a OnCreated.py script into the /scripts folder and do some checking in there, if the created node kwargs is of type explodedView and run your code.


Seb

not sure what you want to do to be honest.

if you want to emit more than one fem object, the emission frame on the node seems to be set to the frame you want to emit an object.

you have to set the force-feedback on the flipsolver to something else than zero, … i've set it to 1.

it also seems to give a ‘better’ (imho) result if you switch the rbd solver from bullet to ‘rbd’


Cheers
Seb

you could calculate the velocity for each point, and from the velocity the acceleration.

and than have the acceleration drive the emission.

Seb

can you try if adding this line into your wrangler works?

#include </path/to/vexfunctions.vfl>

Seb

have you tried increase the feedback-scale on the flip solver ?

what graham said .

1) fill your existing points into the point-tree
2) ask the point tree to give you the next point based on your coordinate
3) check if that point has the same location

Seb

have you checked if the vexdso file is loaded correctly ?

check the post from symek here http://forums.odforce.net/topic/17495-debugging-vexdso/#entry106118 [forums.odforce.net]

hope that helps