qLib: the VFX asset library Houdini studios share

A shared toolbox rather than a plugin marketplace

qLib is a digital asset library for SideFX's Houdini, and the README describes it as a collection of tools designed to work flawlessly with each other and with Houdini's native toolset. That phrasing is the design brief. This is not a directory of unrelated utilities, it is a coherent set that assumes the other tools exist, and the stated aim is that a tool should not look or feel like an in-house hack. The people behind it are the reason to pay attention, since the project is developed by VFX professionals from several studios working on feature films, game cinematics and commercials, which means the tools are exercised on production work rather than written for a showpiece. The library is hosted at qlab.github.io/qLib, the source sits in the qLab organisation on GitHub, and the project also has a presence on Facebook for announcements and a summary of highlights.

Backwards compatibility, VEX performance and a consistent interface

Three priorities are named explicitly, and they tell you what a studio library is for. The first is backwards compatibility, stated as old scenes will not break over time, which is a remarkable thing to promise for a toolset that artists build scenes inside. The second is performance, with the note that the project presses for VEX and multithreading as much as possible, so the heavy lifting happens in compiled code or across cores rather than in interpreted Python. The third is usability, with the goal that the tools avoid the in-house look and feel, so that a node built with qLib is indistinguishable from one built with the stock toolset. Those three together describe a library optimised for a shared pipeline over several years rather than for a single delivery. The licensing follows the same practicality, with the project described as open source software under the New BSD license.

What is actually in the collection

The tools list is broader than the name suggests. There is generation, manipulation and visualisation of geometry attributes and groups, and boundary geometry generation and manipulation. There is a complete deformer suite, and the phrase complete matters, because it is implemented through a common deformer framework, so the deformer nodes share a structure and behave the same way. There are reimplemented high-performance versions of certain original Houdini operators, which is the VEX and multithreading priority made concrete. Then there is the layer that makes a library usable day to day, workflow-related tools, a large collection of gallery items in the form of node and subnet presets, shelf tools, colour schemes and extra menu items, and finally a set of experimental extras. The gallery is the part an artist touches most, since a preset is one click rather than a network to assemble.

Getting it into Houdini 17.5 and later

The quick install is a download, an extract and a move into the Houdini preferences folder in your home directory, followed by appending the contents of the provided houdini.env template to your own houdini.env, or using a package JSON file instead. The archive for the latest version is a single download:

https://github.com/qLab/qLib/archive/master.zip

The fuller method applies to Houdini 17.5 or higher and is the plugin method. You create a folder called packages in your Houdini preferences folder in your home directory, you copy the qLib_linux.json file, or the qLib_windows.json file, into that packages folder, and then you edit the JSON file to point at the extracted qLib folder, which is the path on the QLIB line. The README notes that the package requires Houdini 17.5.321 or higher for it to work, which is the kind of small version floor that decides whether the plugin method is available to you. For older Houdini versions the route is different, with houdini.env templates for Windows and Linux that can be appended to your own houdini.env file in the HoudiniXX.X folder in your home directory.

If you have a package manager, ignore the environment files

There is a section in the installation notes aimed specifically at larger studios, and it is the one to read first in that context. If you are installing at a large facility with a package management system, the instruction is not to rely on houdini.env files, but to use your package manager to set up environment variables. The reason is structural rather than stylistic, because a houdini.env file is a text file appended to by hand on each artist's machine, which is exactly the kind of state a package management system exists to eliminate, and appending the same block to a file on hundreds of workstations by hand is how configurations drift. A facility that distributes software already has a mechanism for setting environment variables, and the library fits into it as a package rather than as a text fragment. It is also a small signal about the audience, since the documentation distinguishes between a single artist installing from an archive and a facility installing through its own tooling.

The repository is a Houdini package, not a Python project

The top level of the repository shows what kind of thing this is. There are menu definition files, MainMenuCommon.xml, OPmenu.xml, PARMmenu.xml and NetworkViewMenu.xml, an OPcustomize directory, an OTL.sh script, a VEXpressions.txt file, and a qLib_package.json that matches the package file used in the plugin method. There are directories for the assets themselves, otls, and for the Python parts, python2.7libs and python_panels, which tells you that the library still ships code for the older Python version Houdini used. There is a gallery directory for the presets, a help directory for the documentation, toolbar and config directories, scripts, bin, a theme file for node colours, and viewer_states for saved viewport setups. Alongside them sit houdini.env_linux and houdini.env_windows, the two files you append for older Houdini, and CHANGES.sh as the changelog. The primary language is listed as Python, but the substance is Houdini assets, which is why the installation instructions talk about preferences folders rather than package managers.

Scene files that show the tools in context

A directory of .hip scene files documents the library the way documentation usually cannot, since each one is a working network rather than a description of one. The files cover the breadth of the collection, with aim_ql_OBJ for aiming, apply_xform_ql_SOP for transforms, attr_visualize_ql_SOP and attrib_grow_ql_SOP, attrib_ramp_ql_SOP and attrib_shape_ql_SOP for attribute work, bend_ql_SOP, bounds_ql_SOP and box_ql_SOP for geometry, camera_frustrum_ql_SOP and camera_plane_ql_SOP, clip_by_bounds_ql_SOP, curve_extend_ql_SOP, deform_by_surface_ql_SOP and deform_by_tetra_ql_SOP, displacebydelta_ql_SOP, force_visualizer_ql_DOP, group_by_percent_ql_SOP and group_visualize_ql_SOP, noise_ql_SOP, occlusion_ql_SOP, optransform_ql_VOP and path_deform_ql_SOP. There are also an experimental folder and a graveyard folder, which is a nice touch of honesty about what the maintainers consider unfinished or abandoned. On the state of the project, the last push was on 2026-10-08 and the repository is not archived, but the only listed release is v0.2.75 from 2019-04-29, tagged as a rolling release for testing the release mechanism, so the tags stopped long before the commits did. Help lives in the help cards attached to every asset, the issue tracker takes bug reports and feature requests, and there is a Google Group for discussion.

Editorial conclusion

qLib fits a studio or a pipeline team running Houdini across many artists, where the value of a shared library is that everybody builds the same kind of geometry, and it fits a facility that has already decided how it distributes software. It is the wrong choice for a single artist who only needs a couple of deformer nodes, since the library is large and the installation expects a facility shaped environment, and it is a poor fit if your pipeline is not Houdini at all. Before you install it, read the note for facilities, because the recommended path there is your own package manager rather than the bundled environment files, and check the compatibility promise against the Houdini version your studio runs, since the package method needs 17.5.321 or higher.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qLab/qLib on GitHub
4. README
5. Releases