On this page |
Overview ¶
About .hda
files
¶
Houdini stores digital assets in .hda
files.
The .hda
file format is a binary archive format which stores a hierarchy of data about one or more assets, including the asset’s node type definition, metadata, shelf tools associated with the node type, and binary blobs (called “sections” or “extra files”), such as Help files, icons, and textures.
(.otl
(operator type library) is the old extension for these files, which still works. You may still have files with this extension in your path. The new “official” extension is .hda
(Houdini digital asset). For backwards compatibility, these files are still located in an otls
directory on the Houdini path.)
In general we recommend that you store one asset (node type) per .hda
file. This allows maximum flexibility for you to install one asset and not another. It also makes it easy to see which assets are/will be installed by what files are on the path. However, an .hda
file can contain any number of assets. This can also be useful, for example to share a library of all the necessary assets for a studio or project as one file.
Expanded directories ¶
Because .hda
is a binary format (and not a standard format like .zip
), it’s hard to get information about the contents just by looking at the file. This utility lets you pull information out of the archive file into forms that are easier to work with. It can print metadata from an .hda
file, merge existing libraries, or convert .hda
files into an “expanded” directory form.
An “expanded” asset library contains files with metadata about the library itself, and separate subdirectories for each asset in the library. The subdirectories contain files with asset metadata, the node definition, and the contents of sections (“extra files”).
You can install assets from an expanded directory directly in Houdini (without having to convert back to an .hda
file first) if the directory is in HOUDINI_PATH/otls
with an .hda
or .otl
extension.
The expanded directory format is useful for the following:
-
Storing asset definitions in version control. Since most of the contents of a library expand to plain text, version control systems can show changes to the asset as diffs.
-
Making batch and/or scripted changes to assets.
For example, a studio could implement the following custom asset workflow:
-
Asset authors save assets in expanded format. The expanded assets are tracked with version control.
-
Test scripts can check the contents of the saved assets by inspecting the expanded files, without needing to run Houdini.
-
A script could using this
-m
or-M
options to merge all the expanded “source” assets to a.hda
file of all the studio’s custom assets to share with users.
Tips and notes ¶
-
Remember that the expand/collapse usages always have the directory first and the
.hda
file second. This may be the opposite of what you might expect in the expand case. -
You can also merge libraries, convert
.hda
files to unpacked directories, and unpacked directories to.hda
files, in Houdini’s Asset Manager user interface.In Houdini’s main menus, choose Assets ▸ Asset Manager. Right-click an asset library in the list of installed libraries and choose Convert to unpacked format (or Convert to packed format).
This converts the files/directories “in place” (that is, it replaces a file with an expanded directory with the same name, or a directory with an
.hda
extension with a file). -
The three expansion options (
-x
,-X
, or-t
) treat the binary node definition contents differently. You need to use the corresponding option (-c
,-C
, or-l
respectively) to “collapse” the resulting directories back into a file.If you don’t know how a particular directory was expanded, you can look for the presence or absence of two files.
-
If a subdirectory contains
Contents.gz
, the directory was expanded with-x
, and you can collapse it with-X
. -
If a subdirectory contains
Contents.mime
, the directory was expanded with-t
, and you can collapse it with-l
. -
Otherwise, the directory was expanded with
-X
, and you can collapse it with-C
.
-
General arguments ¶
-h
Prints the help information.
-a
When used with an option that writes an .hda
file, this sets the contents of the file’s Author field. If you don’t supply this argument, the command uses your username.
Printing info ¶
hotl [-B|-V] ‹testgeo.hda›
Prints out metadata about the node types in the library (referred to as “operators” in the output). For example:
Operator type library: testgeo.hda Operator: mygeo Label: My Geo Path: oplib:/Object/mygeo?Object/mygeo Icon: OBJ_geo Table: Object License: Extra: User: Inputs: 0 to 0 Subnet: false Python: false Empty: false Modified: Mon Jul 12 13:21:01 2021
If the file contains multiple node types, it prints the fields of each node type separated by a blank line.
You can use the following options to modify the output:
-B
Prints only the full name of each node type, instead of each asset’s metadata.
For example:
Object/mygeo Object/testgeo
This can be useful for listing all the available assets in a file without needing to run Houdini, such as in a test script or asset management system.
-V
As part of printing each asset’s metadata, prints the names of the sections (extra files) associated with the asset. For example:
Operator type library: testgeo.hda Operator: mygeo Label: My Geo Path: oplib:/Object/mygeo?Object/mygeo Icon: OBJ_geo Table: Object License: Extra: User: Inputs: 0 to 0 Subnet: false Python: false Empty: false Modified: Mon Jul 12 13:21:01 2021 Sections: DialogScript CreateScript TypePropertiesOptions Help Tools.shelf ExtraFileOptions InternalFileOptions Contents.gz
This can be useful for finding assets that have (or don’t have) a certain section.
Convert an .hda
file to a directory of files
¶
hotl -x|-X|-t ‹directory› ‹hdafile›
Expands the contents of the ‹hdafile› into a tree of files under ‹directory›.
The different options control how the node definition is expanded.
-x
Expand the metadata and sections for each asset into separate subdirectories, but do not expand the node definition data. The node definition data is kept in a compressed Contents.gz
file in each asset subdirectory.
-X
Expand the metadata and sections for each asset into separate subdirectories, and decompresses the node definition files into a Contents.dir
subdirectory instead of leaving them in them Contents.gz
archive.
This option saves binary sections of the node definition into separate files. Contrast with -t
below.
-t
Expand the metadata and sections for each asset into separate subdirectories, and expands the node definition files into a Contents.dir
subdirectory.
This option saves binary sections of the node definition into a single MIME-encoded Contents.mime
file.
Tip
This option may be better for storing asset libraries in version control systems (such a Subversion and Git). The raw node definition files produced by -X
can look like text but actually contain arbitrary binary data, which may confuse version control systems.
If you use -t
, you can pass an additional option:
-p
Include timestamps (saved inside the .hda
file) for each section in the MIME file.
Convert an expanded directory back into an .hda
file
¶
hotl -C|-C|-l [-b] ‹directory› ‹hdafile›
Combines the files under the ‹directory› into a new archive ‹hdafile›.
The different options for collapsing a directory correspond to how the directory was originally expanded (see above).
-c
The opposite of -x
. Looks for a Contents.gz
file in each asset’s subdirectory, and uses that as the node definition.
-C
The opposite of -X
. Looks for individual files in a Contents.dir
directory in each asset’s subdirectory, and combines them into the node definition.
-l
The opposite of -t
. Looks for individual files in a Contents.dir
directory with a Contents.mime
file containing the binary sections.
When collapsing a directory into a file, you can also use the following option:
-b
Create a backup copy of the output .hda
file.
Merge asset libraries ¶
hotl <-m|-M> [-e] ‹source_hda›... ‹dest_hda›
Copies the contents of one or more “source” libraries into the “destination” library. Each “library” can be an .hda
file or expanded directory.
The different options control how to merge node types with the same name:
-m
Keeps node types with duplicate names. When installed in Houdini, one of the node types will override the other, based on Houdini’s asset name resolution rules.
-M
Node type definitions from later “source” files overwrite node types with the same name from earlier source files.
You can also use the following options:
-e
Do not copy over empty shelf tools sections.
--chmod arg
After merging, change the file permissions on the destination file (in UNIX).