A Houdini Digital Asset (HDA, saved in a .hda or older .otl library) is reusable and powerful - until two versions collide, a definition goes missing, or nobody knows which copy is current. Versioning is what keeps that from happening.
Use the namespace and version system
Houdini has built-in versioning through the node type name: namespace::name::version. An asset named mystudio::rock::2.0 is a distinct type from mystudio::rock::1.0, so scenes built on version 1 keep working while new work uses version 2. Use it deliberately:
- Namespace your assets (studio, show or artist) so they never clash with third-party HDAs.
- Bump the version when you change behaviour, not for every tiny tweak, so version numbers stay meaningful.
- Keep old versions installable so existing shots do not break when a new version ships.
Keep definitions with the project
An HDA that lives in one artist's home directory or a personal otls folder is a scene that opens with a missing-asset error for everyone else. Store shared definitions in $JOB/otls/ (or your facility asset library) so the definition travels with the project. When a .hip references an HDA, the definition should always be somewhere the whole team resolves.
The versioning checklist
- Namespaced type names. Every studio HDA uses a
namespace::name::versionpattern. - Definitions in $JOB/otls. No shared asset depends on a local or home-directory library.
- No duplicate definitions. The same asset is not defined in two libraries with different contents.
- No orphaned assets. Every HDA referenced by a scene has a definition that resolves; every definition shipped is actually used.
- Locked or embedded where needed. Assets a shot depends on are embedded or locked so they cannot silently change.
- Version history is legible. Version numbers reflect real changes, so rolling back is a decision, not archaeology.
Audit HDA versions automatically
Tracking this by hand across a project full of assets is exactly the kind of thing that slips. Hive scans a project in your browser and reports HDA and OTL definitions, their versions, duplicates across libraries, and orphaned or unresolved references - so you know the asset picture before a scene lands on someone else's machine. It pairs with the full project audit for a complete pre-handoff pass.
Frequently asked questions
How does Houdini version HDAs?
Through the node type name pattern namespace::name::version. Bumping the version creates a distinct type, so old scenes keep working while new work uses the new version.
Where should HDA definitions live?
In a shared location that travels with the project, such as $JOB/otls, so scenes resolve the definition for the whole team instead of a single artist home directory.
What is an orphaned HDA?
An HDA referenced by a scene with no resolvable definition, or a shipped definition nothing uses. Both cause confusion and missing-asset errors; Hive flags them.