View in #houdini on Slack
@KFriez: I had an optimization/ best practices question for you all, so I’ve found that the more complexity I add to a network the more cumbersome it becomes to make changes to it in some cases. In the case of an HDA, would it be possible to set global variables like say attribute names (ie. Shakiness) as a detail attribute on say the top node of your HDA, and then reference that name in vex or in subsequent python nodes with an expression like $Shakiness so that you could changes to naming conventions, info, etc. without having to hunt through a bunch of nodes?
@Martin_Baadsgaard: I just have a number of null nodes named “CTRL_something” and diligently promote parameters to them, but that is because our detail attributes are slowly filling with the parameters that need to travel through our entire TOP graph
~But I think the idea is good, it also makes it easier if using compile nodes~
Scratch that second comment because that was giving me trouble recently
@KFriez: Ideally I’m trying to centralize it as much as possible onto one node or possibly even the scripts tab on the hda itself. On nodes further downstream I’m referring to my python script node via details(’…/scriptNode’) and then the name of the attribute (ie. ‘Shakiness’), but if that name changes then that node won’t behave as expected. Hence why I was wondering if it would be possible to turn those attributes into expressions that I could access anywhere within the hda, so that nodes that refer to those detail attributes wouldn’t have to be tinkered with as often?
@laidlawfx: Global Variables are really good for this type of workflow. Say for instance on project load each project has a different world scale, world name, project directory etc. You can set them on launch with say 456.py into the Local Houdini Session based on a database entry, or local file. Alternatively set it in the Alias/Variables for the scene session. This way on the top of each node you can have a tab with these internal channel references, so you can either manually override them for the node, but by default they can reference the global variables.
By doing this at the global houdini session as opposed to a detail attribute it works regardless of which object you are in, and in your source repository or database you can have a central place for these variables. Especially if they are needed, or pulled from other sources/applications. This allows for maximum scalability. Details are great for per object overrides, but what I suspect is you need more of a session like override.
Check out these help pages :
I should note it’s more useful to have these type of variables set in your startup scripts, than setting them manually. You can use a node or an pane that does global variable initialization. They key reason is A a new scene you don’t want to forget one key variable. B for farm automation such as top batches. C the .hip gets saved with these variables so if you just launch the scene it will get saved, possibly in a bad state.