Config that breaks setup, caught early

houdini.env & Packages Checker

"It works on my machine" almost always starts in houdini.env or a package JSON. Here are the config mistakes that stop HDAs and tools loading - and how a checker catches them so a studio setup stays reproducible.

A Houdini setup lives in two files most artists never look at: houdini.env and the JSON files under packages/. Get them wrong and HDAs vanish, shelf tools disappear, and a scene that opened yesterday opens with unknown-operator errors today. The mistakes are few, well known, and easy to check for.

Why env and package config breaks a setup

Houdini's modern way to add HDAs, plugins and tools is the package system - small JSON files that set environment variables and extend HOUDINI_PATH - with houdini.env still in play for per-user variables. It is flexible, but nothing validates it: a typo, a stale path or a missing token fails silently at launch, and the artist just notices something is "gone". When every workstation edits these by hand, they drift apart, and "reproducible studio setup" quietly becomes a myth. A checker turns those silent failures into a list you can fix.

The mistakes that stop things loading

What a clean config looks like

A well-formed HOUDINI_PATH keeps the defaults and uses portable, resolvable roots:

# houdini.env
HOUDINI_PATH = "$JOB/hda;$STUDIO_TOOLS/houdini;&"

The trailing & preserves Houdini's defaults, the entries are variables rather than hard-coded drives, and each one resolves. A package JSON does the same job declaratively, which is why studios prefer it - but it needs the same discipline, and that is what the checker enforces across every file at once.

Keep every workstation reproducible

The value is not one fixed config - it is knowing every machine matches. Run the checker against a workstation's setup (or paste a config from another box) and you get a single report of every env/package problem, so onboarding a new artist or a render node is "make it pass the check" instead of an afternoon of guessing. It pairs naturally with a standard $JOB folder structure and a clean HDA versioning setup, so where HDAs live and how they load both stay predictable.

Run the checker in your browser

Hive parses houdini.env and your packages/*.json locally - scan a project or workstation folder (Chrome or Edge via the File System Access API, or drag and drop), or simply paste a houdini.env. Nothing is uploaded and nothing runs Houdini; it just reads the config and reports the missing &, unresolved paths, duplicates, disabled packages and absolute paths. It is one card in the full project audit.

Frequently asked questions

Why won't my HDA or package load in Houdini?

The usual causes are a HOUDINI_PATH set without the & token (which drops Houdini's own defaults), a path in houdini.env or a package that doesn't resolve, a package that's disabled or duplicated, or an absolute local path that doesn't exist on this machine. Hive checks houdini.env and your packages for exactly these.

What does the & mean in HOUDINI_PATH?

The & is a placeholder for Houdini's default search paths. If you set HOUDINI_PATH to your own folders without appending &, you replace the defaults instead of adding to them, and core Houdini assets and tools stop loading. Hive flags any HOUDINI_PATH set without the & token.

Can I paste a houdini.env instead of scanning a folder?

Yes. Hive accepts a pasted houdini.env as well as a scanned project, so you can check a config from another machine without moving files. It parses locally in your browser and nothing is uploaded.

Start your free trial