patarI guess it was, especially when it had people with a smaller sense of entitlement
i guess this forum is not as helpful as it used to…
Found 128 posts.
Search results Show results as topic list.
Technical Discussion » Compiling the Pixar USD Houdini plugin on Windows
- Infernalspawn
- 229 posts
- Offline
Technical Discussion » Soho & Progress Bar
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Compiling the Pixar USD Houdini plugin on Windows
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Compiling the Pixar USD Houdini plugin on Windows
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Rib - Partitioning
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Matching Mantra motion blur with Vray motion blur ?
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » HDK plugin loading troubleshooting
- Infernalspawn
- 229 posts
- Offline
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 ?
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 ?
Technical Discussion » Can not render
- Infernalspawn
- 229 posts
- Offline
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
Seb
Technical Discussion » HDK plugin loading troubleshooting
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Nearest unique/exclusive point using VEX?
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Nearest unique/exclusive point using VEX?
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » view HDK documentation offline?
- Infernalspawn
- 229 posts
- Offline
Technical Discussion » OTL initialization script problem
- Infernalspawn
- 229 posts
- Offline
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
Seb
Technical Discussion » FEM solver copy issue
- Infernalspawn
- 229 posts
- Offline
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.
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.
Technical Discussion » dynamic weighbridge
- Infernalspawn
- 229 posts
- Offline
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
it also seems to give a ‘better’ (imho) result if you switch the rbd solver from bullet to ‘rbd’
Cheers
Seb
Technical Discussion » PARTICLES INITIAL STATE+SHAKE OFF
- Infernalspawn
- 229 posts
- Offline
you could calculate the velocity for each point, and from the velocity the acceleration.
and than have the acceleration drive the emission.
Seb
and than have the acceleration drive the emission.
Seb
Technical Discussion » Custom VEX built-in functions
- Infernalspawn
- 229 posts
- Offline
can you try if adding this line into your wrangler works?
#include </path/to/vexfunctions.vfl>
Seb
#include </path/to/vexfunctions.vfl>
Seb
Technical Discussion » Flip fluid with RBD
- Infernalspawn
- 229 posts
- Offline
Technical Discussion » HDK check if a point already exists
- Infernalspawn
- 229 posts
- Offline
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
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
Technical Discussion » Calling dso-declared functions from a vfl
- Infernalspawn
- 229 posts
- Offline
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
check the post from symek here http://forums.odforce.net/topic/17495-debugging-vexdso/#entry106118 [forums.odforce.net]
hope that helps
-
- Quick Links