Stalkerx777

import subprocess subprocess.Popen(['gplay', '/path/to/your/geometry.$F4.bgeo']) gplay must be in PATH, otherwise, specify a full path to it ($HFS/bin/gplay)

Untested, off the top of my head: node = hou.node('your_node') ptg = node.parmTemplateGroup() for i, file_path in enumerate(paths): pt = hou.StringParmTemplate('file%d' % i, 'File %d' %i, 1, file_path) ptg.addParmTemplate(pt) node.setParmTemplate(ptg) Or you could multi-parm block: hou.FolderParmTemplate( ... folder_type=MultiparmBlock)

Unfortunately, this is not possible at this moment. It could be quite useful, there were a few times when I wished this feature existed.

The menu script gets evaluated every time and so if you have an inconsistency between users/machines, you have to deal with it at the script level. There are also two types of menu: a string type menu and an ordered menu. I believe if you set it to a string type it will preserve its value.

Here's a simpler way: QPushButton.setCheckable(True) QPushButton.isCheked()

Hi, Yes, the ui module contains UI related stuff and is not available in Hython. You have few other options: 1. Use OpenGL ROP (probably the best option) http://www.sidefx.com/docs/houdini/nodes/out/opengl.html 2. Call Hscript http://www.sidefx.com/docs/houdini/commands/viewwrite.html Cheers

CMake generates this .proto file at build time. This recently introduced feature allows you (optionally) decouple parameter interface code from the main code. Again, it's not required to do it that way, unless you have special intentions like supporting compiled blocks feature for example or adding a "verb" (see docs) to your plugin. Now, if you absolutely necessary to use SCons, AND you have a code which uses this new paradigm (like SOP_Star.C) take a look at CMakeLists.txt file, you'll see houdini_generate_proto_headers function, which lives in toolkit/cmake/HoudiniConfig.cmake file. Implement it in your SCons script if you want. Cheers.

https://www.youtube.com/watch?v=JHjm-zfP6sM ... Display Options -> Apply Operation To All Split Views ... Select objects, enter the rotate tool, right click on the manipulator in the viewport -> Global Control ... Path Tool. Although it's very clumsy. ... Help->Example Files->Python Panel Examples->Viewport Color Editor.

Using eventCallback is not the right way, the right way would be submitting a bug report since your code is totally fine and should work.

geo = hou.pwd().geometry() for f in random_file_list: geo.loadFromFile(f)

Ok, this was a nice learning project, a lot of things can be improved, but i'm done with it and i'll share the source code, as i promised. Hope this will be useful for learning purpose. Happy New Year! YouTube Source code

If you're talking about the procedural shader, it should be available within the SHOP context (or the new material context?). Try the SOP version for start. Compile the plugin. The latest compiled version available by the link above is for H16.0. Put the file in here: ~/Library/Preferences/houdini/X.X/dso/ Open the Terminal (http://www.sidefx.com/docs/houdini/basics/config_env.html) Set env variable HOUDINI_DSO_ERROR=2 and run Houdini. If there is a problem with loading the plugin you'll get the message printed out. Cheers.

It's pretty uncommon task to create a node inside thousands of other nodes. The issue easily might be nothing to do with your Python code or HDA itself but simply the Houdini bottleneck. What I would try: Profile your code with cProfile. This might give you an idea what takes time. Performance monitor doesn't help you in this case. You might be querying some Houdini parameter or geometry which makes Houdini cook it. Run your script in Hython instead. Try to do this in Hscript, although it's very unlikely you see any difference. Ask SideFx for support if you have a commercial license. Go crazy and write it in HDK

Vice versa. You attach the debugger to a running process. But as I said before, Houdini is not a process you want Python debugger attach to. Python interpreter is running inside Houdini process so the only option you have for real debugging is using a remote debugger. Maybe someone here could share if they have such experience, I haven't been able to set it up in Houdini.

Debugging and communicating with an application via a port is completely different things. You can do a socket to socket communication in Houdini via openport command or use Houdini's hrpyc Python server. For debugging, since you're running PyDev you should be able to use PyDev remote python debugger. I've had a few attempts to make it work but no luck.

It's a coincidence that I'm working on the tools that require unique node identifiers. Unluckily Houdini doesn't provide us with a persistent UID which would be saved in a Hip file, only in the duration of the session, which is kinda useless in my opinion. Despite the fact that I don't like Maya, there is a unique ID attached to each Maya node and this guarantees that knowing the UID you can always retrieve the node. So in Houdini you can't rely on the node names since they inconsistent. What I ended up with is that I'm generating a UID by myself for every node I'm creating in the script. import hashlib, time def generate_uid(node): hash = hashlib.md5() hash.update(node.path() + str(time.time())) node.setUserData('uid', hash.hexdigest()[:10]) # To get the value: node.userData.get('uid') And there you go, you have a UID system in Houdini.

http://www.sidefx.com/docs/houdini/hom/rpc.html Note: hrpc module lives in $HH/python2.7libs and it depends on some other rpc bits which are somewhere in $HFS/python/lib/site-packages

Starting from version 16 Houdini has been switched to Qt5, which means it ships with the libraries so you don't need to use system's ones. from hutil.Qt import QtCore, QtGui, QtWidgets

Congrats! And thanks for such an amazing resource.

There are some complexities with Qt bindings at present. There are Python2 and Python3 branches, and PySide, PySide2, PyQt4, PyQt5 bindings. Back then when only Python2 and Qt4 existed, everything was simple: you either go with PySide or PyQt4. Now it's more complicated UNLESS you compile the bindings yourself. So If you want PySide2 for Python2 on windows you have to compile it yourself. Same for PyQt5. We are pretty stuck with Python2 for at least until 2020 (see http://www.vfxplatform.com/) Another quick solution is to install Python3 and PyQt5 (pip3 install pyqt5), and then use houtil.Qt wrapper: from hutil.Qt import QtWidgets, QtCore But why do we need to install Python3 and PyQt5 then? Well, just to be able to use PyCharm features! In PyCharm type this: from hutil.Qt import QtWidgets, QtCore if False: from PyQt5 import QtWidgets, QtCore You trick PyCharm to use PyQt5 libraries for autocompletion. It's a very quick and not so reliable solution because PyQt5 and PySide2 are different, as well as Python2 and Python3 Note that you can use https://github.com/mottosso/Qt.py (hutil.Qt is basically the same) which abstracts the bindings problem and your code will use whatever library is available at that time. But you won't have PyCharm completion which is sad. So the take away is: for serious development with PyCharm + Houdini, you want to compile PySide2 bindings. P.S. quite a long post Maybe someone finds it useful. I'm a long time PyCharm user and still haven't found the working solution for Houdini and Qt development that works on all platforms.

PySide2 libraries are located in ....Houdini 16.0.705\python27\lib\site-packages-ui-forced ... something like that, don't remember exact folder name.

That's pretty old tutorials and many things have changed since then. To add a spare parameter: ptg = node.parmTemplateGroup() parm = hou.FloatParmTemplate('foo', 1) ptg.addParmTemplate(parm) node.setParmTemplateGroup(ptg) http://www.sidefx.com/docs/houdini/hom/hou/ParmTemplateGroup

HScript chrefit command

Yes, see Geometry Data parameter type and a new Stash SOP

No, nothing you can do about it. OS constantly sends all sorts of events to Houdini application, and since the latter waits while you editing code, Windows assumes that your application experiencing problems