modify existing node (pythonically)

[SElsner]

Hi,

what is the best practice to extend a node for example adding a tab with custom parms (buttons etc...)

1) For HDAs, I can do this via the type properties dialog. Extending the mantra node for example, changes are of course saved on the local OPlibdriver.otl and not on a central lib in $HSITE. I do not want to copy the modified local one there because every time the mantra node gets an update I would have to redo everything. And this only works for HDAs.

2) On a sphere node (non-HDA) I cannot edit operator types, but the Parameter Interface. But how is this saved?

3) monkey patch hou.Node.createNode with something like:

Code:

def customCreateNode(*args, **kwargs):
    # create node then do something with it like attaching new parms
    pass

hou.Node.createNode = customCreateNode

This is how it works in Nuke but its giving me errors I have to investigate...

4) regular callback (I could not find in the docs)

5) Other solution?

Cheers

Sebastian

[graham]

Monkey patching is definitely not a good idea. In the case of adding extra parameters and such, the best thing to do would be to use the nodes creation script. You can write a .cmd or .py creation script named after your operator type name and place it in scripts/optable and whenever a node of that type is created, the script will run.

For example, I have a script that sets the group name parameter on Group SOPs to be an opname() expression whenever I create a Group SOP. I can do that by creating a $HOME/scripts/sop/group.py file and adding a line of Python to set the parameter to my choice of values. This script could do other things such as adding parameters.

It is important to note that if you are attempting to write a script for a regular Houdini operator, that operator may already have a script that is run located in the Houdini installation directory. Generally it is a good idea to ensure that that script will be run after yours is run, unless you want to completely change the behavior. If there was a script in $HFS that was run when a Group SOP was created, as the last line in my above group.py I would add hou.hscript("source group.cmd") to tell Houdini to run the first instance of group.cmd, which would be the one in HFS.

[SElsner]

Thanks Graham, this is exactly what I wanted! Your example worked perfectly.

But trying this with a mantra node failed. I tried the paths below and all failed:

$HOME/scripts/rop/idf.py

$HOME/scripts/rop/mantra.py

$HOME/scripts/out/ifd.py

$HOME/scripts/out/mantra.py

$HOME/scripts/hda/ifd.py

$HOME/scripts/hda/mantra.py

I guess this is because its an HDA. How would I go about that?

Cheers

Sebastian

[rdg]

Last time I checked ( ~2009 ) SESI told me the render nodes don't follow an traditional HDA workflow and hence such scripts don't work.

It's like: your creation scripts work but then SOHO kicks in and modifies the node on the fly - depending on you settings like renderer and such.

Might be possible this changed, but to me it looked like this is pretty much it.

Thanks Graham, this is exactly what I wanted! Your example worked perfectly.

But trying this with a mantra node failed. I tried the paths below and all failed:

$HOME/scripts/rop/idf.py

$HOME/scripts/rop/mantra.py

$HOME/scripts/out/ifd.py

$HOME/scripts/out/mantra.py

$HOME/scripts/hda/ifd.py

$HOME/scripts/hda/mantra.py

I guess this is because its an HDA. How would I go about that?

Cheers

Sebastian

[SElsner]

Ok thanks, will bug support then. Not too important though, I have found an alternative way to do stuff. I have to admit a lot of things are very well thought through (like pythonrc, which I love!), where others (like this) feel strange...

Last time I checked ( ~2009 ) SESI told me the render nodes don't follow an traditional HDA workflow and hence such scripts don't work.

It's like: your creation scripts work but then SOHO kicks in and modifies the node on the fly - depending on you settings like renderer and such.

Might be possible this changed, but to me it looked like this is pretty much it.

[graham]

The issue here isn't actually about ROPs. The problem is that Houdini does not run these create scripts for digital assets. I guess that since assets can have their OnCreated sections they don't need to run their named py/cmd file. Since the Mantra ROP is actually an asset, ifd.[py/cmd] never gets called. Submitting an RFE for the ability to.

Also, in the case of ROP nodes, scripts should be placed in scripts/out. For example, scripts/out/geometry.py will be run properly upon creation since it is not a digital asset.

[rdg]

GeometryROP is a rather lame example as it's very basic

Not really in a position to provide extensive testing, but:

Eg setting AOV planes and properties via scripts/out/ifd.py/ifd.cmd were blown away by the soho part.

The issue here isn't actually about ROPs. The problem is that Houdini does not run these create scripts for digital assets. I guess that since assets can have their OnCreated sections they don't need to run their named py/cmd file. Since the Mantra ROP is actually an asset, ifd.[py/cmd] never gets called. Submitting an RFE for the ability to.

Also, in the case of ROP nodes, scripts should be placed in scripts/out. For example, scripts/out/geometry.py will be run properly upon creation since it is not a digital asset.