Houclip Tool for Houdini

Last updated on: 30 May, 2023

Summary: A program for managing an easily accessible repository of saved Houdini networks and code snippets using dmenu or rofi. Your handy Houdini multi-clipboard.

Tool Description

Houclip demonstration video.

One of the greatest advantages of Houdini over other DCC tools, are its Digital Assets (HDAs) which allow for creation of reusable encapsulated and standalone tools made of operators networks.

Still, preparation of HDAs is time-consuming. It requires from artists a lot of planning ahead, design its parameter interface, and test the asset thoroughly with different input parameter settings. If all you want is to create a reusable network configurations which you will use in designing other assets, the endeavor of encapsulating each one of them into an HDA might be an overkill.

Houclip tries to address this by managing a local repository of so-called “snippets”. A “snippet” in Houclip terms is anything from a single operator to a large network of nodes, or a text (like source code) copied from Houdini, the Internet, or any other source. Snippets are stored in a local or remote repository and can be easily accessed by their description (which also acts as their name) and tags at any time. Once retrieved from repository, they can be pasted in Houdini network editor or a text field using the standard CTRL v hotkey.

A detailed description on how to use the tool, as well as requirements and installation instructions are available in the README file of the Houclip Github repo.

If you want to know how the package works from the technical side, continue reading this post. Otherwise, you can download Houclip from GitHub by following the link below.

Anatomy of a “Snippet”

There are two kinds of snippets that the program uses:

  1. Operator snippets.
  2. Code snippets.

Regardless of its type, each snippet is constituted of several attributes and a file. Attributes are stored in .csv files named after node type category name of their origin, or a user-selected language in case of code snippets. Currently, the latter is hardcoded and limited to HScript, Python and VEX.

A single snippet definition in a .csv file is as follows:

{description};{tags};{category};{prefix};{uuid1}
  • Description is a string of any length that uniquely identifies a snippet. If two snippets have the same description, only the first one on the list will be retrievable. As of Houclip 0.5.1, there are no safeguards against adding snippets with the same description, so keep this in mind.
  • Tags are optional comma-separated values. They should not contain a whitespace, as any whitespace will be automatically removed.
  • Category is Houdini’s node type category name of the first node in the selection, when the snippet was added.
  • Prefix is the original prefix of a file that Houdini exported to $HOUDINI_TEMP. More on this in a moment.
  • UUID1 is a time and host-dependent identifier of the snippet, which acts as a filename of the actual snippet stored in a subdirectory within the Houclip repository.

The second part that constitutes a snippet, is its main file. It is stored in a directory named after snippet’s node type category name or a user-selected programming language (in case of code snippets). When a network, or even a single operator, is copied to clipboard in Houdini, the program creates a .cpio file in $HOUDINI_TEMP and names it according to {prefix}_copy.cpio pattern.

Prefix depends on Houdini context which an operator was copied from, and uses all upper case characters. However, some prefixes vastly differ from their type categories. Here’s a listing of PREFIXES dictionary, which translates type categories into prefixes and demonstrates those differences. The value of None was arbitrarily assigned to type categories that are either deprecated (like VopNet), or are impossible to reach with Houdini GUI (like Director, which is a / network path in Houdini).

# Node type category name to prefix.
PREFIXES = {
    'Chop': 'CHOP',
    'ChopNet': 'CHOPNET',
    'Cop2': 'COP2',
    'CopNet': 'IMG',
    'Director': None,
    'Dop': 'DOP',
    'Driver': 'ROP',
    'Lop': 'LOP',
    'Manager': None,
    'Object': 'OBJ',
    'Shop': 'SHOP',
    'Sop': 'SOP',
    'Top': 'TOP',
    'TopNet': 'TOPNET',
    'Vop': 'VOP',
    'VopNet': None,
}

Original snippet prefixes have to be stored in .csv files in order to reconstruct the Houdini clipboard file, so that once a snippet is fetched from repository into $HOUDINI_TEMP file, it can be pasted back into a proper context.

Code snippets on the other hand don’t use prefixes. Instead, they rely on a separate tuple1:

LANGUAGES = ('HScript', 'Python', 'VEX')

File Formats

There are two main differences in how Houclip handles operator and code snippets. During opadd operation, a .cpio file that is being archived is compressed with gzip. Code snippet files on the other hand are stored in plain-text format.

In case of emergency, if for some reason you’re unable to fetch a snippet using one of Houclip’s main interfaces, you can always do so by accessing those files directly. It’s just a matter of finding the proper UUID, or in the worst case, going through all files from a given category one-by-one.

Repository Hierarchy

Repository resides in a path defined in houclip.conf and has two levels. The root contains .csv files for each category or programming language, while the second level (subdirectories) is a place where the actual snippet files reside in. Here’s an example of a repository populated with snippets from various categories:

# ~/.local/share
▶ tree houclip
houclip
├── Chop
├── Chop.csv
├── ChopNet
├── ChopNet.csv
├── Cop2
│   └── b4997e08fbcc11ed8b1f50465d72ea7c
├── Cop2.csv
├── CopNet
├── CopNet.csv
(...)
├── Python
│   ├── 6093dbd4fc8d11ed8b1f50465d72ea7c
│   ├── 8dd2e410fe2111ed8b1f50465d72ea7c
│   └── ca8f55ccfc8d11ed8b1f50465d72ea7c
(...)
├── Sop
│   ├── 0bb2a2bafc0811ed8b1f50465d72ea7c
│   ├── 1524ebdefbcf11ed8b1f50465d72ea7c
│   ├── 503be342fbcc11ed8b1f50465d72ea7c
│   ├── 593b4820fbcc11ed8b1f50465d72ea7c
│   ├── 67819b94fd3611ed8b1f50465d72ea7c
│   ├── 69d869a8fd5011ed8b1f50465d72ea7c
│   ├── 6e981a54fbcc11ed8b1f50465d72ea7c
│   (...) 
├── Sop.csv
(...)

20 directories, 40 files

By default, the repository is located in ~/.local/share/houclip, as per XDG Base Directory Specification2, but you can use any other location that you have write (if you want to store snippets there) or read access to (if you just want to fetch snippets). Now, I haven’t tested this, but if you have CIFS or NFS path mounted on, or virtually any other network drive, it should work as well. So technically, depending on how you access network resources, Houclip repository location should not be limited to just local drives.

Have fun snipping.


  1. In a future version of Houclip I intend to externalize this to houclip.conf file, so that the list of languages can be defined according to one’s needs. ↩︎

  2. Well, sort of, because ideally and for full compliance with XDG, the program should expand the $XDG_DATA_HOME envar. I guess I should implement this. ↩︎