Houdini - intro to HDA
The notes below are based on info found in the Houdini docs as well as other sources.
The general form of an asset’s internal name is
The namespace and version are both optional. You can have a name with both a namespace and a version, or just a namespace, or just a version, or neither.
asset name & scripting
Some scripting commands require the node category and node name together (for example Object/geo, Sop/copy, Dop/popsolver). To use namespaced names with these commands, use the form [namespace::]node_category/node_name[::version] For example, com.sundae::Sop/copy::2.0
The namespace identifier lets you name your assets without worrying about using the same name as a built-in Houdini node or as a third-party asset you might use someday. (Note that this only applies to the internal name of the node… you can always use any string you want for the human readable label that appears in the user interface.)
A useful convention to ensure you use a unique namespace name is to reverse the DNS address of your website. For example, if the creator´s website is at houdini.bacon.org, they would use org.bacon.houdini as the namespace for their assets.
The version string allows you to create multiple independent versions of an asset without having to change the “main name”.
Instances of the old version will still work and use the old implementation, while users placing a new node will get the latest version.
The version can only contain numbers and periods (.). For example, myasset::2, myasset::2.1, myasset::19.1.3, but not myasset::2a or myasset::alpha.
2 types of versioning
Houdini supports two different but compatible systems for versioning assets, supporting different use cases:
You can incorporate the version number as part of the asset’s internal name. For example, mynode::2.0. This makes each version an entirely different asset. This allows different versions to exist in the same scene file simultaneously. When the user creates a node, they get the new version, but existing nodes use the older version and continue to work in the old way without changes.
- + You can make large-scale changes to how the node works, how it interprets inputs, its parameter interface, and so on, without breaking anything.
- + You don’t need to manually update old nodes.
- - There is no provision to upgrade old nodes automatically.
You can use the Version field in the asset definition. This was the historical versioning solution before namespaces were added. It is retained for cases where it’s still useful. If an asset instance loads and notices the asset’s version string has changed since the scene file was saved, it will run an upgrade handler script (if it exists). The script can edit the node instance to transform it into the new version.
- This can be useful if you usually make minor, backwards-compatible changes to an asset rather than big breaking changes, especially new parameters. It is mostly useful in a studio environment, where a TD does the work so the artists’ tools are automatically upgraded.
- + You can automatically upgrade existing assets with new (backwards-compatible) features.
- - You need to manually update the upgrade script and script the work of changing an old instance into a new instance, every time you update the asset. You may need to maintain the ability for the script to upgrade one of several old versions to the latest edition (for example, the script might need to be able to update any of version 1, 2, or 3 to version 4).
* Select the nodes * press **Shift C** to create a subnet * RMB click on the subnet > **Create Digital Asset**