Jump to content
nrusch

Set parameter defaults for built-in nodes

Recommended Posts

Hey all,

 

I've tried to do my best to dig up previous answers to this question, but so far I've been unsuccessful.

 

What I'd like to do is set default values for some parameters on built-in node types. One good example is the 'vm_image_exr_compression' parameter on the Mantra ROP.

 

Ideally, I would like to set these up in our site 123.py, since it's already being used for other things. I would have expected that the NodeType for the Mantra ROP would provide an interface for accomplishing this, but that doesn't seem to be the case. While I can get the ParmTemplate instances from the NodeType, only a small number are returned, and all of the sub-tabs under the Properties tab seem to be invisible to the template interface.

 

Next, as an alternative solution, I was hoping to install some kind of an onCreate event callback for a NodeType, so that whenever a node of said type were created, I could run some code to set some of its parameter values. However, so far all I've found are the methods for installing callbacks on existing node instances... which doesn't really help me. However, this seems like the kind of thing that must be possible somehow, so I have a feeling I may be looking in the wrong places...

 

So, all of this leaves me with a few questions:

  • Is it possible to set parameter defaults at the NodeType level (NOT the Parm level) programmatically, say, when Houdini starts?
  • If not, is it possible to install an onCreate callback for a NodeType, so that I can run code whenever a node that said type is created?
  • If not, is what I'm trying to do even possible?

I'd like to pull this off as concisely as possible, since my customizations live in a Mercurial repository. Thus, the preset system doesn't really feel like a great option unless I can hand-forge my own sparse preset files (that aren't > 35kb just to define 2 parameter defaults  ;) ) and force them to be applied at startup.

 

Thanks for any insight here.

Share this post


Link to post
Share on other sites

Thanks for the responses.

 

The partial preset tool sounds interesting, but feels a little heavy-handed for the this type of problem, especially given how robust Houdini's Python API is in most areas. I'll certainly take a look at the GitHub repo to see if there are any tricks I can make use of though.

 

Node initialization scripts look like they will allow me to do what I'm after... except that they don't seem to work.

  • I have HOUDINI_PATH set to a series of directories, with the the <INSTALL>/houdini directory at the end.
  • In one of the HOUDINI_PATH directories before the installation directory, I have created `scripts/obj/geo.py`.
  • This script doesn't get executed when I create a Geometry node.

Any idea what could be going on here? I must say I'm a little surprised there isn't a more elegant, contained way of installing creation event callbacks.

 

Thanks

Edited by nrusch

Share this post


Link to post
Share on other sites

There's no such thing as a Geometry SOP. Do you mean Geometry OBJ ?

Share this post


Link to post
Share on other sites

Did you try putting your directory after the default? Just taking a stab in the dark.

Share this post


Link to post
Share on other sites

Yeah, that was one of the first things I tried. Still no dice. I guess maybe I should email support and find out if user initialization scripts are even supposed to work. The .cmd scripts in the install tree obviously work though, since that's how most of the output properties get added to things like Mantra ROPs.

Share this post


Link to post
Share on other sites

I guess maybe I should email support and find out if user initialization scripts are even supposed to work.

Edward gave you an answer with a link to documentation, why do you want to email support?

Must be there is something wrong with your HOUDINI_PATH, or *.py script itself. Try to put this script in $HOME/houdini13.0/scripts/obj/geo.py

 

 

I must say I'm a little surprised there isn't a more elegant, contained way of installing creation event callbacks.

"Elegant" is very subjective. There are other ways, but they much more complex, for example hou.ui.addEventLoopCallback(). Although, you still need 123.py or 456.py to setup this callbacks.

Edited by Stalkerx777
  • Like 1

Share this post


Link to post
Share on other sites

Edward gave you an answer with a link to documentation, why do you want to email support?

Must be there is something wrong with your HOUDINI_PATH, or *.py script itself. Try to put this script in $HOME/houdini13.0/scripts/obj/geo.py

I've already tried this as well, and it does nothing. I would hope that by emailing support, they would be able to tell me if the node initialization script system is actually supposed to work in this version (13.0.509), and if so, be able help me track down the issue or log it as a bug.

 

Right now, the script is trying to print something to sys.__stdout__, as well as touch a file in /tmp. In other words, its only purpose right now is to try and confirm that it's actually running. Is there anyone that is using node initialization scripts and confirm that they do, in fact, work?

 

 

"Elegant" is very subjective. There are other ways, but they much more complex, for example hou.ui.addEventLoopCallback(). Although, you still need 123.py or 456.py to setup this callbacks.

There are many VFX-related packages with encapsulated event or callback systems that allow the registration of callables against various event names or callbacks. Houdini has a pretty robust Python API that has clearly had quite a bit of thought put into it, but it also contains some really strange gaping holes (for example, anything regarding Takes), and the lack of a formal callback system is another one of those.

 

hou.ui.addEventLoopCallback would be a hacky way of trying to do what I want, and would introduce a lot of unnecessary overhead for very little gain. My callback handler would also have no information about what had changed since the last time it had run, so if I were trying to accomplish my original goal (set some parameters to alternate default values when a new node of a given type is created), it would have to query for all nodes of the desired type every time (in other words, "approximately every 50ms") and decide whether to set those parameter values.

Share this post


Link to post
Share on other sites

$HOME/houdini13.0/scripts/obj/geo.py
Works for me without any problem, with H13.0.376 and H13.0.571 Windows 7 x64.

Those are lines in mine geo.py file and it got printed in Python Shell:

print "hello"
print kwargs['node']

Cheers

Share this post


Link to post
Share on other sites

Is there anyone that is using node initialization scripts and confirm that they do, in fact, work?

I can. I wouldn't answer you question if i'm not sure. Have you try more recent build?

 

and the lack of a formal callback system is another one of those.....

  1. hou.ui.addEventLoopCallback
  2. hou.Node.addEventCallback
  3. Event scripts for HDA
  4. Init scripts, mentioned before

Share this post


Link to post
Share on other sites

OK thanks, it's good to know that they do actually work. I'll try to get a more recent build in here before emailing support.

 

 

  1. hou.ui.addEventLoopCallback
  2. hou.Node.addEventCallback
  3. Event scripts for HDA
  4. Init scripts, mentioned before

Sorry, I didn't really flesh that thought out completely. A more accurate statement would have been "...the lack of a unified callback system is another one of those", and your list demonstrates that perfectly. Why is it that I can add a callback to a node instance (which does nothing for me in this case), but not to a NodeType?

 

I'm not interested in arguing this point any further. Allowing callbacks to be registered at the NodeType level would be an improvement, period.

Share this post


Link to post
Share on other sites

could be the reason they don't let you adjust defaults on built-in types is that the defaults have to match the mantra defaults.  SOHO ignores default values to save space (you don't want EVERY possible parm being passed along in an ifd).  but if the default value is not what mantra is expecting, you can find yourself in a world of confusion.  for example, if you change the default value for "allow motion blur" to be true, then SOHO would ignore that flag and never tell mantra to turn on motion blur.  the only way to get SOHO to export that parm to mantra would be to turn it off, which of course would mean no motion blur in your render.  so the toggle in houdini would be broken -- neither state would yield motion blur.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×