For more concrete information about namespaces and versions, see creating and versioning digital assets.

• 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 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 sundae::copy. This keeps it separate from the built-in copy node, as well as Joe’s Geometry Hut’s joesgeohut::copy node.

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. It also protects against SideFX someday adding a new factory node that happens to have the same name you chose.

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, copy, new_copy, 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 acme::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::2, myasset::2.1, myasset::19.1.3, but not myasset::2a or myasset::alpha.

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 general form of an asset’s internal name is

[‹namespace›::]‹node_name›[::‹version›].

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 Object/geo, Sop/copy, Dop/popsolver). To use namespaced names with these commands, use the form [‹namespace›::]‹node_category›/‹node_name›[::‹version›]. For example, acme::Sop/copy::2.0.

When you refer to node types in scripts, you can use a “fully qualified” name (for example acme::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_HIERARCHY environment 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 HOUDINI_OPNAMESPACE_HIERARCHY contains…

  acme bacon
  

  Then if Houdini knows about assets named vines, bacon::vines, and acme::vines, and you use the command…

  opadd vines
  

  …Houdini will use acme::vines because it is earliest in the HOUDINI_OPNAMESPACE_HIERARCHY list.

  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.0 to the list would make Houdini use that for an ambiguous vines reference, even if com.sundae::vines::2.0 is available.

  You can use wildcards (* and ?) in the names in the HOUDINI_OPNAMESPACE_HIERARCHY list.

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 exact_type_name argument.

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 (Object/geo) network.

This may be useful in reducing clutter in the ⇥ Tab menu by restricting the contexts in which a very specialized asset appear.