I realize that this is a year late, and you've probably discovered the answer to this by now, but from what I understand you have two options. If the character is only doing rigid transforms, then you can set up your hierarchy so that each limb is a separate object that can then have transformations applied to it.
However if you are doing deformations then it is my understanding that only option is to override the entire cache with another cache containing the animated deformations.
Found 183 posts.
Search results Show results as topic list.
Solaris » Character anim transforms to Solaris like Alembic Layering
-
- NFX
- 183 posts
- Offline
Solaris » How to render Pyro in Solaris with Arnold?
-
- NFX
- 183 posts
- Offline
That was the trick. Thanks! To bad that the SOP Import and SOP Create lops don't work for this.
Solaris » How to render Pyro in Solaris with Arnold?
-
- NFX
- 183 posts
- Offline
I've been having a hard time figure out how to work with volumes in Solaris, especially when it comes to rendering them via the Arnold Hydra plugin. I've figured out how to shade and render them for the normal Arnold IPR, but I can't get them to even show up in the Arnold Solaris viewport. Anyone have examples of the proper workflow for this?
As a side-note, I found other people with the issue on the Autodesk forums but they seem to think it's a Houdini or environment issue. However we're a shop with a pretty solid Houdini environment setup and are using 18.5 so I doubt that's it.
https://answers.arnoldrenderer.com/questions/25664/how-to-render-vdb-volumes-in-solaris.html [answers.arnoldrenderer.com]
As a side-note, I found other people with the issue on the Autodesk forums but they seem to think it's a Houdini or environment issue. However we're a shop with a pretty solid Houdini environment setup and are using 18.5 so I doubt that's it.
https://answers.arnoldrenderer.com/questions/25664/how-to-render-vdb-volumes-in-solaris.html [answers.arnoldrenderer.com]
Technical Discussion » Compiling Houdini 17 USD tools on Windows
-
- NFX
- 183 posts
- Offline
One of the features that I was looking forward to in Houdini 17 was their new USD tools. While they've seemed to have rolled back the official release of them to later, I notice that they have included some convenient files for compiling the USD files on linux. Unfortunately I am on Windows. Anyone had any success building these tools on Windows?
Technical Discussion » Growing Curves in Wire Solver
-
- NFX
- 183 posts
- Offline
Lol. I did think about that. I figured that it may be good to know how to do it with the current solvers though just in case it lacks some specific functionality I need.
Technical Discussion » Growing Curves in Wire Solver
-
- NFX
- 183 posts
- Offline
So I am working on a growing tree animation and am wanting to use a wire solver at each step of growing the tree to calculate the bending of the branches due to gravity as the branch grows longer. This means that I need to continually append vertexes to the ends of existing polywires as a branch grows and generate new polywires as new branches are formed. I've been able to get a test working with a wire solver feeding into a pop solver with a sop solver hooked up to it's post solve, however I feel there is a more direct method to doing this that I am missing. Any ideas?
Technical Discussion » documentation for toolutils
-
- NFX
- 183 posts
- Offline
Technical Discussion » Compiling the Pixar USD Houdini plugin on Windows
-
- NFX
- 183 posts
- Offline
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.
find_path(HOUDINI_LIB_DIRS libHoudiniGEO.so HINTS "${HOUDINI_ROOT}" "$ENV{HOUDINI_ROOT}" "${HOUDINI_BASE_DIR}" PATH_SUFFIXES dsolib/ DOC "Houdini Development Kit Library Path" )
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.
Technical Discussion » Custom code in .hip file throw errors before startup scripts have had a chance to add needed libraries to the Python Path.
-
- NFX
- 183 posts
- Offline
Technical Discussion » Custom code in .hip file throw errors before startup scripts have had a chance to add needed libraries to the Python Path.
-
- NFX
- 183 posts
- Offline
Well that was a detailed response jsmake 
Thanks graham, I was wondering if that could be used that way. I would really love to keep the ability to launch Houdini directly from the file.

Thanks graham, I was wondering if that could be used that way. I would really love to keep the ability to launch Houdini directly from the file.
Technical Discussion » Custom code in .hip file throw errors before startup scripts have had a chance to add needed libraries to the Python Path.
-
- NFX
- 183 posts
- Offline
The title says it all. I have a .hip file containing nodes with code that relies on external libraries to run. In my 123.py and 456.py files I handle loading the needed libraries into the environment, however since the scene file will load into memory before the startup scripts run, I get a bunch of nasty errors. The scene will still work fine once the UI opens up, but the errors tend to scare the artists.
The only way I know to work around this is to either permanently add the libraries to the system environment, or launch Houdini from a script that initialized the environment beforehand.
The problem with approach 1 is that IT doesn't want me screwing around with the system environment.
The problem with approach 2 is that I can't figure out how to do this and still allow artists to open files via double-clicking the .hip.
Any ideas? Perhaps just letting the error's happen is the lesser evil?
The only way I know to work around this is to either permanently add the libraries to the system environment, or launch Houdini from a script that initialized the environment beforehand.
The problem with approach 1 is that IT doesn't want me screwing around with the system environment.
The problem with approach 2 is that I can't figure out how to do this and still allow artists to open files via double-clicking the .hip.
Any ideas? Perhaps just letting the error's happen is the lesser evil?
Technical Discussion » Packaging external Python code into HDA
-
- NFX
- 183 posts
- Offline
My studio is currently trying to setup our pipeline to handle outsourcing projects to freelancers and wants to be able to share the Houdini files we create. The big problem is we've developed lots of custom HDAs that run on lots of custom code.
In house these nodes execute python functions defined in external files on our server, this keeps everything nice and centralized for easy maintenance. However this raises some obvious issues if we expect someone to use the file out of house as the referenced libraries will no longer be available.
My initial thoughts on how to solve this is to create a tool that loads any code that the asset relies on into the HDA perhaps as an extra file or as part of the hdaModule. The main issue with this being, that doing so would probably break how the code was referenced (hdaModule vs import this.package.here as module).
Anyone have any ideas on how to best do this?
In house these nodes execute python functions defined in external files on our server, this keeps everything nice and centralized for easy maintenance. However this raises some obvious issues if we expect someone to use the file out of house as the referenced libraries will no longer be available.
My initial thoughts on how to solve this is to create a tool that loads any code that the asset relies on into the HDA perhaps as an extra file or as part of the hdaModule. The main issue with this being, that doing so would probably break how the code was referenced (hdaModule vs import this.package.here as module).
Anyone have any ideas on how to best do this?
Technical Discussion » houdini Submit to Deadline
-
- NFX
- 183 posts
- Offline
Q1: Zero means that it will not use limits. So having that as the default is usually fine if you don't have specific limits you want to use.
Not entirely sure about Q2 and Q3, although I suspect ‘ignore inputs’ means that nodes connected to the ROP you are rendering are ignored.
A possible reason why the IFDs are not working is that you are using $HIPNAME in the file path. Deadline usually creates a temp version of your hip file and gives it a weird name, so that is probably throwing it off. Also if your farm renders the ifd on a machine running one OS and then renders out the image on a machine running a different OS, that can cause a whole host of issues as well.
Not entirely sure about Q2 and Q3, although I suspect ‘ignore inputs’ means that nodes connected to the ROP you are rendering are ignored.
A possible reason why the IFDs are not working is that you are using $HIPNAME in the file path. Deadline usually creates a temp version of your hip file and gives it a weird name, so that is probably throwing it off. Also if your farm renders the ifd on a machine running one OS and then renders out the image on a machine running a different OS, that can cause a whole host of issues as well.
Houdini for Realtime » Procedural Hair Cards HDA BETA RELEASE
-
- NFX
- 183 posts
- Offline
Technical Discussion » Correct method to launch a PyQt/PySide widget from the shelf
-
- NFX
- 183 posts
- Offline
Despite parenting my window to the Houdini Qt session, in my tests I was still having problems with python deleting my references. Rvinluan's solution of creating an instance of the widget and adding it to the hou.session fixed the problem.
Technical Discussion » Problem with Custom Shelf Tool Python Window
-
- NFX
- 183 posts
- Offline
Both of these solutions work like a charm. I didn't know you could dynamically declare variables in hou.session like this (though in retrospect this totally makes sense). I'll have to remember that trick for the future.
Technical Discussion » Correct method to launch a PyQt/PySide widget from the shelf
-
- NFX
- 183 posts
- Offline
I am having this issue in H16. The window opens properly if I define the class inside the shelf tool's scripting window, but if I try to store it in an external file and then import it as a module into the shelf tool then the window just opens and then closes.
I tried fixing this by parenting the window to the houdini session as shown in the documentation, but then I start getting “RuntimeError: Internal C++ object (PySide.QtGui.QListWidget) already deleted.”.
Unless someone knows a work around, it seems like storing your python windows externally is a no go.
SOLVED:
Rvinluan gives a good workaround in this thread [www.sidefx.com].
I tried fixing this by parenting the window to the houdini session as shown in the documentation, but then I start getting “RuntimeError: Internal C++ object (PySide.QtGui.QListWidget) already deleted.”.
Unless someone knows a work around, it seems like storing your python windows externally is a no go.
SOLVED:
Rvinluan gives a good workaround in this thread [www.sidefx.com].
Edited by NFX - March 29, 2018 15:40:18
Technical Discussion » Problem with Custom Shelf Tool Python Window
-
- NFX
- 183 posts
- Offline
So here is the sample code I promised. After further testing it, the problem definitely has to do with parenting the window to Houdini's mainQtWindow. The .ui file that the code is reading in is just a button and a qlineedit inside a horizontal layout. This script is being run via a shelf tool.
Just to reiterate, if I click the button on this example I get aerror. Which seems odd since the whole point of parenting the window to Houdini is to avoid references being deleted.
If I get rid of theline then it runs, but only if the class is defined inside the tool's script window. If I move the class into an external file and then load it as a module, then the window is deleted as soon as it's made. My guess is that this is due to its references being cleaned up since it is not parented to Houdini's Qt session.
Is there a way to work around this?
import os from PySide import QtCore from PySide import QtGui from PySide import QtUiTools class TweakedDemo(QtGui.QWidget): def __init__(self, parent=None): super(TweakedDemo, self).__init__(parent) loader = QtUiTools.QUiLoader() gui_path = os.path.join(os.getenv('HIP'),'testGui.ui') self.gui = loader.load(gui_path) self.setGeometry(500, 300, 250, 110) self.setWindowTitle('Tweaked Demo') button = self.gui.findChild(QtGui.QPushButton, "button") self.field = self.gui.findChild(QtGui.QLineEdit, "textField") self.connect(button, QtCore.SIGNAL('clicked()'), self.changeText) vbox = QtGui.QVBoxLayout() vbox.addWidget(self.gui) self.setLayout(vbox) def changeText(self): self.field.setText('Hello World') def closeEvent(self, event): self.setParent(None) dialog = TweakedDemo() dialog.setParent(hou.ui.mainQtWindow(), QtCore.Qt.Window) dialog.show()
Just to reiterate, if I click the button on this example I get a
RuntimeError: Internal C++ object (PySide.QtGui.QListWidget) already deleted.
If I get rid of the
dialog.setParent(hou.ui.mainQtWindow(), QtCore.Qt.Window)
Is there a way to work around this?
Edited by NFX - March 29, 2018 13:44:40
Technical Discussion » Problem with Custom Shelf Tool Python Window
-
- NFX
- 183 posts
- Offline
I am trying to write a python window that launches when a shelf tool button is pressed. I have been able to launch the window, however it seems that all the references to my widgets break once the window is initialized. Callbacks and anything that happens afterwards result in a “RuntimeError: Internal C++ object (PySide.QtGui.QListWidget) already deleted.” I'm guessing that this has something to do with Houdini's event loop?
I will try to post some example code tomorrow, but I just wanted to post this and see if anyone had any ideas.
I will try to post some example code tomorrow, but I just wanted to post this and see if anyone had any ideas.
Technical Discussion » PySide2 not found on Windows
-
- NFX
- 183 posts
- Offline
Well what do you know, it is the Qt4 build…
That would explain why the folder at %HFS%/python27/lib/site-packages-ui-forced was labelled PySide rather than PySide2.
I didn't know there was even an option to get a different version.
If I want to build a tool that works on both builds of houdini, what would be the right way of testing which PySide to use? A set of try: except: import statements?
That would explain why the folder at %HFS%/python27/lib/site-packages-ui-forced was labelled PySide rather than PySide2.
I didn't know there was even an option to get a different version.
If I want to build a tool that works on both builds of houdini, what would be the right way of testing which PySide to use? A set of try: except: import statements?
Edited by NFX - March 23, 2018 11:42:06
-
- Quick Links