A Sane Houdini Project Folder Structure ($JOB)
Houdini will happily let you save your .hip file to the desktop, cache to a random scratch folder, and reference textures by absolute path. It will also happily break the moment anyone else opens the scene. A consistent project structure built around $JOB is the cheapest insurance a Houdini studio can buy. Here is a layout that scales.
Why $JOB matters
$JOB is the environment variable Houdini uses to locate your project root. If you reference everything relative to $JOB rather than hard-coding C:\Users\you\... paths, the project becomes portable: it can move to another artist, another machine, or the render farm without a single broken reference. Absolute paths are the number one cause of "it works on my machine" in Houdini.
A standard structure
There is no single official layout, but most studios converge on something like this under the project root:
/hip- scene files (your.hipsaves)/geo- cached geometry (.bgeo.sc,.abc)/sim- simulation caches/render- rendered frames and AOVs/comp- files for or from compositing/tex- textures and source maps/abc- Alembic exchange caches/scripts- tool and pipeline scripts/flipor/desk- scratch and personal work, kept out of the shared areas
The exact names matter less than the fact that everyone uses the same ones. Pick a convention, write it down, and make it the default for every new job.
Naming inside the folders
A tidy folder full of files called test, test2, and final_FINAL is not tidy. Inside each folder, name caches and renders with the element and a version token, for example smoke_v003.$F4.bgeo.sc. Consistent names make it obvious what a file is, which version it belongs to, and which frame it represents. Our asset naming guide goes deeper on this.
Versioning
Version your caches and renders explicitly with a padded token like v001, and bump it rather than overwriting. Disk is cheap; a lost cache the night before a deadline is not. Keep the version in the filename so it survives being copied, moved, or handed to someone else.
Caches and geometry
Cache to $JOB/geo and $JOB/sim, never to a local scratch path you will forget. Use frame padding ($F4) so sequences sort correctly, and keep heavy sims separate from light geo so backups and cleanups are easy to reason about.
Handing off to Unreal or Unity
When your Houdini work feeds a game engine, a clean structure pays off twice. Export exchange formats (Alembic, FBX, USD) to a predictable folder, name them to match the engine's expectations, and keep a clear boundary between "working" caches and "delivery" exports. A messy Houdini project becomes a messy Unreal import; a tidy one drops straight in.
Enforcing it
Conventions that live only in someone's head do not survive a busy week. Put the structure in a project template, generate it automatically for every new job, and check it periodically. Our free Houdini VEX Lab includes a $JOB structure generator, and Hive, our Houdini Studio Hub, scans a project and flags naming and structure problems before they spread. Set the standard once and let tooling keep everyone honest.
Standardising your Houdini pipeline?
Hive, our Houdini Studio Hub, scans a project, validates naming and checks your $JOB structure automatically.
See Hive