When implementing a custom Python Processor or Scheduler spare parameters can be added to a node. We can then save that as a Python script and the new parameters are saved in the “templateBody” function.
It seems that folder objects are ignored when writing this out so when I use the node described by my custom script the folder structure I had is gone. Has anyone had any success getting the “Save To Python Script” button to remember parameters within folders? Wondering if this might need an RFE
Preserving Parameter Interface for Custom TOPs
1534 2 1- matt_t
- Member
- 14 posts
- Joined: Oct. 2015
- Offline
- tpetrick
- Staff
- 600 posts
- Joined: May 2014
- Offline
When you save the node to a stand alone Python file, it's saved as a plain PDG node. That node will work outside of TOPs when used with the pure Python PDG graph constructs. It has a much smaller number of parameter types than Houdini, and doesn't save layout information. TOPs is able to load in those basic definitions, but they are not the same as assets with regular Houdini parm interfaces.
Instead of saving the file to a script, you can choose the Save to HDA button instead. That will create an HDA with the PDG node callback hooks embedded in the script section. Alternatively, you can create your own TOP asset from the basic definition. Right mouse click an instance of the node with the auto-created parm interface and select “Create Digital Asset”. You can then use the regular Houdini parm interface to custom the parameter types and layout for the node. That's the work flow used to create all of the built-in TOP nodes.
Instead of saving the file to a script, you can choose the Save to HDA button instead. That will create an HDA with the PDG node callback hooks embedded in the script section. Alternatively, you can create your own TOP asset from the basic definition. Right mouse click an instance of the node with the auto-created parm interface and select “Create Digital Asset”. You can then use the regular Houdini parm interface to custom the parameter types and layout for the node. That's the work flow used to create all of the built-in TOP nodes.
Edited by tpetrick - July 22, 2020 17:52:34
- matt_t
- Member
- 14 posts
- Joined: Oct. 2015
- Offline
Thanks for getting back to me on this. I guess the process for creating a Custom HDA from a Python TOP must also go through the script method as it loses the layout as well. I'd be interested to know why pure PDG doesn't support these other parameter layout types - is that a conscious limitation or something that could be changing in the future?
My original train of thought was to allow TOPs to be constructed purely with Python (including the interface) in an external location, installed and then loaded at runtime through registerTypes. I suppose the solution here would be to define the parameter interface for the node through an HDA and then attach additional Python functionality from the external files through the HDA's Python module.
Cheers!
My original train of thought was to allow TOPs to be constructed purely with Python (including the interface) in an external location, installed and then loaded at runtime through registerTypes. I suppose the solution here would be to define the parameter interface for the node through an HDA and then attach additional Python functionality from the external files through the HDA's Python module.
Cheers!
Matt Traynar
Lead Software Developer @ MPC
Lead Software Developer @ MPC
-
- Quick Links