Preserving Parameter Interface for Custom TOPs

   1341   2   1
User Avatar
Member
10 posts
Joined: 10月 2015
Offline
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
Matt Traynar

Software Developer @ MPC
User Avatar
スタッフ
585 posts
Joined: 5月 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.
Edited by tpetrick - 2020年7月22日 17:52:34
User Avatar
Member
10 posts
Joined: 10月 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!
Matt Traynar

Software Developer @ MPC
  • Quick Links