Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


graham last won the day on May 11

graham had the most liked content!

Community Reputation

135 Excellent


About graham

  • Rank
    Houdini Master
  • Birthday 01/09/1985

Contact Methods

  • Website URL

Personal Information

  • Name
  • Location
    Culver City, CA

Recent Profile Visitors

7,893 profile views
  1. You are defining the function in a node but are then trying to refer to it as if it was stored in hou.session. If you either remove the hou.session prefix and call it directly, or put the code in the Python Source Editor and call it like that then it would work
  2. It's possible to drag cameras and lights onto the viewport and it will cause the viewer to look through them. It's also possible to write a shelf tool type thing and assign a hotkey to it to cause the active viewer to look through a selected camera/light.
  3. Editable nodes are stored in their own string section called EditableNodes as a space separated list of relative paths so you can basically just construct your string and add/set the contents of that section to it. hou.HDADefinition.addSection("EditableNodes", "foo bar/hello")
  4. The issue is that the parent node is in fact /obj/example. In the case of Houdini the parent node is the node that contains an operator, not an input node. Since the parent is an Object it fails because there is no xform node at the object level. As you mentioned the multiple nodes in the SOP level are a result of the node cooking multiple times, most likely when MMB on it for errors, etc.
  5. The +/x buttons in the lower left hand side just add/remove entries from the jump.pref file (usually located in $HOME/houdiniX.Y/) so you can basically copy/move that file (or create your own) and put it somewhere everyone can see and they will pick up the bookmarks.
  6. In the case of something like that (and if say modifying more than one parameter, or the ones on digital assets) you'll want to use the hou.ParmTemplateGroup from the node like as follows: >>> hou.parm('/out/mantra1/vm_variable_plane1').description() 'VEX Variable' >>> ptg = hou.node('/out/mantra1').parmTemplateGroup() >>> ptg.find("vm_variable_plane#") <hou.StringParmTemplate name='vm_variable_plane#' label='VEX Variable' length=1 naming_sch >>> pt = ptg.find("vm_variable_plane#") >>> pt.setLabel("This is a test") >>> ptg.replace(pt.name(), pt) >>> hou.node('/out/mantra1').setParmTemplateGroup(ptg) >>> hou.parm('/out/mantra1/vm_variable_plane1').description() 'This is a test'
  7. Disable/Hide When is handled through a parameters ParmTemplate conditionals dict. Consider this example of a button that is disabled/hidden when a toggle ('parm') is not checked: >>> pt=hou.parm('/obj/geo1/null1/parm2').parmTemplate() >>> pt <hou.ButtonParmTemplate name='parm2' label='Label'> >>> pt.conditionals() {parmCondType.DisableWhen: '{ parm == 0 }', parmCondType.HideWhen: '{ parm == 0 }'} >>> pt.setConditional(hou.parmCondType.DisableWhen, "{ parm == 1 }") >>> pt.setConditional(hou.parmCondType.HideWhen, "{ parm == 1 }") >>> pt.conditionals() {parmCondType.DisableWhen: '{ parm == 1 }', parmCondType.HideWhen: '{ parm == 1 }'} >>> n.replaceSpareParmTuple(pt.name(), pt)
  8. The usual method to prevent modifications would be through the use of file permissions on your repository files: A normal tool that artist would be using should be coming to them from a read only file that is created/managed by your tool system. Since the file has no write permissions artists are not able to make changes to it (think SESI otls that exist inside $HFS, you can't modify these by default because they are read only). When you hit your "Modify" button your system would make a local copy of that otl to the users work directory and the file would have write permissions so they'd be able to add/update/remove the contents and parameters. You'd then "Publish" the tool back to your system, removing their local copy and creating a new, read only copy that artists would then pick up.
  9. I would basically just do something with a regex cleanup function that converts anything you can't enter manually into _ like Houdini does. def cleanName(name): return re.sub("[^0-9a-zA-Z\.]+", "_", name)
  10. I found that I had submitted 51276 for this issue 48 months ago! Originally based on
  11. The best way is to find the corresponding node types you want to search for and check for all instances of those types. For example, if your node is a SOP: key = ("io", "caching") all_instances = [] for node_type in hou.sopNodeTypeCategory().nodeTypes().values(): components = node_type.nameComponents() if components[1:3] == key: all_instances.extend(node_type.instances())
  12. Are you on Windows? I recall this being a Windows issue with how it handled args when compiling. I can't remember if there was any solution. Do things work better if you put the prim_group arg in between the detail args?
  13. A friend asked SESI this just yesterday. They said it's missing from the docs (and they will add it). It's done with hou.HDADefinition.save() hou.HDADDefinition.save("blackbox.hda", some_node, compile_contents=True, black_box=True)
  14. I think the quote blocks are all blown out now
  15. We've had random people experience this at work. I think they seemed to have success getting them to show up by removing their $HOME/houdini15.5 preferences folder. Your mileage may vary however.