|On this page|
When you add or change the functionality of an asset, you don’t always want every existing instance of the asset to be upgraded. For example, the new version might work differently, and you don’t want finished shots to suddenly render differently. Or the new version might have a different interface that would break channel references in previous scene files.
The solution is to add a version to the asset. This lets previous versions of the asset co-exist with the current version.
When you name digital assets, there is a risk that someday Side Effects, or a subcontractor, or a third party vendor, will use the same name, causing a conflict.
You can guard against this by including a namespace in the name of the asset.
Namespaces and versioning were introduced in Houdini 12.
The version string allows you to create multiple independent versions of an asset without having to change the "main name" (that is, without having to have nodes named,
newer_copy, and so on). If Sasha wants to completely change the interface and/or implementation of her
copy asset, she can create an asset named
com.sade::copy::2.0. 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::19.1.3, but not
When multiple definitions of an asset with the same name are available, Houdini will automatically make only the latest version available in the user interface.
The operator type properties window for an asset contains a Version field. This field is left over from previous versions of Houdini where it functioned more as an annotation. It has no relation to the
::version part of the node type name.
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.)
For example, Sasha’s Unbelievably Natural Discount Animation Emporium might produce a surface node for copying geometry, and name it
com.sundae::copy. This keeps it separate from the built-in
copy node, as well as Joe’s Geometry Hut’s
This is useful for creating assets you might want to distribute to other users. It is also useful to allow separate artists in the same facility to create their own assets without having to worry about name clashes when their assets are used together later.
A useful convention to ensure you use a unique namespace name is to reverse the DNS address of your website. For example, if Ada’s Houdini appreciation website is at
houdini.bacon.org, she would use
org.bacon.houdini as the namespace for her assets. You can use additional conventions, such as adding the name of the asset creator, for example
The parts of an asset name
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.
Some scripting commands require the node category and node name together (for example
Dop/popsolver). To use namespaced names with these commands, use the form
[namespace::]node_category/node_name[::version]. For example,
Specify the namespace and/or version of an asset
When you create a digital asset from a node (using > Create Digital Asset on a node in the network editor), you can include a namespace and/or version as part of the asset name in the Operator Name field of the "Create New Digital Asset" dialog box.
Create a new version of an asset
Prefer an old version of an asset in the user interface
Show all old versions as well as current versions in the user interface
Referencing node types in scripts
When you refer to node types in scripts, you can use a "fully qualified" name (for example
com.sundae::vines::2.0) to refer to a specific node and version exactly, or use an "ambiguous" reference (for example,
vines) and have Houdini infer which node you want. Ambiguous references are often useful when you always want to use the latest version of an asset, or want to allow the user to prefer another asset in a different namespace without having to change all your scripts.
In cases where an ambiguous name could refer to several nodes, Houdini uses the following rules to select one.
If you don’t specify a version number, Houdini selects the node with the highest version number. A node that was created without a "version" part on the end of its name is always considered to be the lowest version.
Houdini selects nodes that are limited to the current scope before nodes that are not scoped.
Houdini selects nodes created without a namespace before nodes that have a namespace.
Houdini always prefers names or namespaces listed in the
HOUDINI_OPNAMESPACE_HIERARCHYenvironment variable. You can set this variable to a space-separated list of namespace names and/or node names to control ambiguous name resolution. Namespaces appearing first in the list are used before namespaces later in the list, or not in the list at all.
For example, if your
Then if Houdini knows about assets named
com.sundae::vines, and you use the command…
…Houdini will use
com.sundae::vinesbecause it is earliest in the
You can add a fully-qualified name to the list to make it take precedence even over a later version. For example, adding
com.sundae::vines::1.0to the list would make Houdini use that for an ambiguous
vinesreference, even if
You can use wildcards (
?) in the names in the
To unambiguously refer to a node without a namespace part in its name, use
::node_name. For example,
::copy. To unambiguously refer to a node without a version part in its name, use
node_name::. For example,
Some scripting commands/methods have an explicit option to disable namespace resolution and
HOUDINI_OPNAMESPACE_HIERARCHY. For example, opadd has a
-e option to require an exact operator name. Similarly, hou.Node.createNode() has an
You can specify in an asset’s name that it is only valid within a certain type of sub-network, using the form
[Node_category/node_name::]node_spec. For example, if you have an asset
com.example::mysop, you can specify that it is only valid within a SOP Solver DOP by naming it
Dop/sopsolver::com.example::mysop. This would prevent users from adding the asset inside a Geometry object (
This may be useful in reducing clutter in the ⇥ Tab menu by restricting the contexts in which a very specialized asset appear.