HDAs or OTLs?
Updated: Apr 12
A question I sometimes encounter is people asking "What's the difference between HDAs and OTLs?"
Let's look at what the acronyms stand for:
OTL: Operator Type Library
OTL stands for "Operator Type Library". An "Operator Type" is just Houdini's technical term for its internal representation of a Digital Asset. So the term "OTL" is synonymous to "Digital Asset Library".
Since a digital asset file on disk can potentially store multiple digital assets, my convention is to use OTL to refer to the files on disk in recognition that a library is something that can store many items. For this reason, I also prefer to use "otl" as the file extension. Even though Houdini lets you save digital assets with either an "otl" or "hda" extension.
HDA: Houdini Digital Asset
So what about the HDA acronym? I use HDA to describe the digital asset itself as an abtract concept.
So I would be comfortable with a statement saying something like: "an OTL file can contain multiple HDAs", for example.
You may have your own interpretation. That's fine. Use what works for you. For me, this way of thinking about it is used as a way to attempt to maintain consistency within the pipeline and in the naming of files and variables in my code.
If you want some historical insight, check out this 2015 post on OdForce.net.
Multiple HDAs Per OTL?
One final point. Despite OTLs being capable of holding multiple HDAs, it's a common convention to only ever have a single HDA stored within an OTL file
There are times where I've broken this rule as a convenience factor when working outside of a structured pipeline, as it can be useful when the HDAs are related or have some sort of dependency on each other.
However, if you're working in a strict pipeline under version control and trying to coordinate multiple people working on different Digital Assets simultaneously, having more than one HDA in an OTL can cause a lot of unwanted added complications. Worth avoiding!
Following further discussion on Twitter about the topic of having multiple HDAs in a single OTL file, some other points came up which I thought I'd add back into this post for completeness.
Houdini requires you to specify which HDAs to install based on an OTL's filename. This means that if you have multiple HDAs in a single OTL file, you are forced to install all of them at once, or none at all. Sometimes this isn't a bad thing, for example, if there's an HDA which uses another HDA inside it. In that situation it can make sense to bundle them up together, but only if the other issues mentioned in this post don't factor in to cause issues.
But by keeping your HDAs in separate OTL files, you have complete control over which definitions are installed at any one time.
Automated HDA Management
If you are developing a Python based tool/UI to manage your HDAs and OTLs, allowing multiple HDAs in a single file increases the complexity significantly. Particularly if you are putting in place some sort of publishing system where write access is limited to one person at a time.
In the course of writing such a tool, you'll find that you need to write a layer of logic to deal with publishing HDAs based on the file that they're contained within. If you have one HDA per OTL, that's easy. Having multiple HDAs per OTL, complicates the logic because your user's expectation and mental-model of the situation is focussed on the concept of managing individal HDA nodes inside Houdini, not on the file they're contained within.
You'll find that it also complicates the user experience, because the user needs to understand that publishing one HDA will potentially publish other HDAs as well. If you choose to expose your functionality via a right-click context menu then these subtleties can be hard to express clearly. I'm certainly not saying that it can't be done, but I would imagine it would add a significant amount of development time to make it work well. Even if you're putting together a full-blown PyQt based Python Panel, you can expect it to increase the complexity of your design.
In summary, often the simplest approach is best. Yes, it can occasionally be convenient to have multiple HDAs in a single file, but it's best avoided when working in a larger studio environment where publishing and automation may be needed.