Aelib: a shelf of Houdini SOP assets shipped as a Houdini package

A library of Houdini assets, not a plugin with new nodes

Aelib is described as a library of Digital Assets, Tools and Scripts for SideFX Houdini, and that phrasing sets expectations. It is not a new render engine, not a solver with a new algorithm, and not a wrapper around an external application. It is a shelf of things an artist would otherwise build for themselves: nodes that create geometry, deform it, modify point and primitive topology, work on curves, read and write files, run simulations, and provide general utility behaviour. The intended user is a Houdini artist or technical director who works in SOPs and wants a starting point rather than a blank node graph. The primary language of the repository is Python, which matches the scripting side of the collection, and the licence is LGPL-3.0, a copyleft licence that matters if you intend to redistribute a modified version rather than just use the assets in your own scenes.

About 100 SOP HDAs grouped into eight categories

The otls folder holds approximately 100 SOP level HDAs, which are Houdini Digital Assets, and they appear in the aelib tab submenu. The README sorts them into eight named sections, and the sorting is by what the node does to geometry rather than by pipeline stage. Creators are geometry creation SOPs that usually need no input geometry. Deformers modify geometry positions. Modify nodes involve creating or destroying points and primitives and require input geometry. Curves covers a variety of tools acting on polyline curves. IO is for reading or writing files to disk. Solvers covers simulations and feedback loops. Utility holds general purpose tools and miscellaneous items. Extensions are similar to existing Houdini or third party SOPs but with extra functionality. The distinction between Modify and Extensions is the one to read twice, because Extensions explicitly overlap with what Houdini already ships.

A shelf, VEX includes, wrangle presets and bundled Python

The HDA collection is only part of the package. Aelib also includes a shelf containing macros and useful Python scripts, several VEX include files adding a range of new functions, a VEXpressions.txt file which adds presets to wrangles, and bundled Python libraries required for a small number of SOP nodes. That last group explains the repository layout, which carries separate directories for Python 3.9, 3.10 and 3.11 under python3.9libs, python3.10libs and python3.11libs. Houdini ships its own Python version per release, so shipping one library directory per interpreter version is the way to keep the bundled code importable across the Houdini versions a studio might have installed. The VEXpressions.txt file is the mechanism behind the wrangle presets: it is a plain text file of expressions that the Houdini interface picks up, so a new preset is a text edit rather than a node build. The toolbar and scripts directories add the interface elements and the shelf macros.

Installing it as a Houdini package

Installation is a file operation, and the README lays it out as a numbered list rather than a command. You download and extract the repository and move it to any location, then create a folder called packages in your Houdini home directory if it does not exist already. The example given for that home directory is a path under a user's documents for houdini18.0, which shows that the location is version specific. Next you copy the Aelib.json file into the packages folder, and then you edit the json file to point to the Aelib parent directory, which the README identifies as the AELIB line. The reason for that edit is that the package file has to reference wherever you put the library on disk, and since the instructions let you choose any location, the path cannot be known in advance. The README points to the SideFX documentation on plugin package files for the details of how that mechanism works. There is no installer script and no compilation step in the instructions, because the assets are already built.

Learning from the hip files and the per-node help cards

The usage guidance is split between example scenes and node level documentation. The examples directory contains hip files demonstrating usage of many of the Aelib SOPs, and the listing shows how large that set is, with files for an accumulation solver, an activation solver, an arc creator, an attribute chop, an attribute contour, a capsule, a chaotic attractor, a clip, a colour correct, a curve blender and a curve cutter among the visible names. A hip file is a saved Houdini scene, so each example is a working graph rather than a screenshot, which is the difference between seeing a node and seeing how it is wired. The second layer is that each node includes a help card detailing its inputs, parameters and behaviour, and many parameters include a rollover tooltip. The help card is the actual specification of the node, since the README does not publish a manual for the collection. That is also the boundary of the documentation: anything a node does that is not visible in its inputs, parameters or tooltip is not written down in the repository.

Archived HDAs and a release history that lags the commits

The library manages its own history. The README states that HDAs are periodically archived from the main library as they are superseded by new Aelib nodes or built-in Houdini nodes, and that they are kept in an archive folder inside otls. In practice this means a scene that referenced a node years ago can still find it, but the current tab shows the replacement, and the replacement may be a node that Houdini now ships itself. The repository layout also includes a gallery directory and an icons directory used by the interface. On the release side the record is sparse: tags exist for v1.2 on 2024-08-03, v1.1 on 2022-12-22 and v1.0 on 2020-12-03, while the repository is not archived and the last push was on 2026-09-30. The gap between the last tag and the last push tells you the collection keeps changing between releases, so pinning a scene to a specific Aelib version is a decision you have to make deliberately.

qLib as the reference point, and what Aelib adds on top

The README states plainly that this library has been heavily inspired by qLib, and that qLib is an incredible resource which the author highly recommends installing and exploring. That is the closest thing to an alternative in the documentation, and the difference in approach is worth stating: qLib is a separate project with its own nodes and its own conventions, while Aelib is delivered as a Houdini package with its own tab submenu, shelf, VEX includes and wrangle presets. An artist who already has qLib installed has overlapping tools, and the question is whether the overlap justifies a second library on the shelf, particularly given that the Extensions category is defined precisely as nodes similar to existing Houdini or third party SOPs. Development is supported through a Patreon subscription offered in the README, which tells you the project expects unfunded time from its author. The LGPL-3.0 licence requires that modified versions stay under the same terms, so if you plan to fork the assets for a studio library, that obligation travels with the code.

Editorial conclusion

Aelib fits a Houdini artist who wants a shelf of ready-made SOP nodes, VEX helpers and wrangle presets without writing them, and who is comfortable editing a package JSON file. It does not fit a pipeline that needs a pinned, versioned node set with a support contract, since the last release was v1.2 on 2024-08-03 even though the repository was pushed on 2026-09-30. Verify first that the AELIB path inside Aelib.json points at the directory you actually copied, then open a node from the aelib tab and read its help card, because behaviour beyond the documented inputs and parameters is not written down anywhere else.

Frequently asked questions

Official sources

1. Aeoll/Aelib on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases