What the project audit checks
Houdini $JOB folder structure checker
A clean project starts with a consistent $JOB folder tree. Hive scans your Houdini project and checks it against a standard structure, so caches, HDAs, renders and exports always land where the next artist and the render farm expect them.
It validates the folders a Houdini pipeline relies on - geo, sim, cache, render, hda, otls, scripts, tex, usd, abc, fbx, comp - and flags files that drifted into the wrong place. A recommended layout looks like this:
$JOB/
geo/ cached geometry (.bgeo.sc)
sim/ simulation caches
cache/ misc caches (flip, pyro)
render/ Mantra / Karma output
hda/ digital assets in use
otls/ legacy .otl libraries
scripts/ python / hscript
tex/ textures
usd/ USD stages and layers
abc/ Alembic exchange
fbx/ FBX / engine exchange
comp/ comp output
Need to create a clean tree from scratch? The free Houdini VEX Lab includes a Houdini $JOB project folder generator; use Hive to audit an existing project against it. Read the $JOB folder structure guide →
Houdini HDA / OTL versioning audit
Digital assets are where a Houdini project quietly rots. Hive inventories every HDA and OTL a project references and flags the version problems that break scenes on another machine: duplicate HDA versions, old .otl libraries still loaded, missing referenced asset libraries, artist-local HDAs that only exist on one box, and inconsistent namespace or version naming.
The result is a portability report: you know a scene will open with the right asset definitions before you hand it over, not after a collaborator opens it to a wall of unknown-operator errors. See the HDA versioning checklist →
Houdini cache naming validator
SideFX's own File Cache documentation warns that constructed file paths can collide when node names are not meaningful or unique. Hive checks your cache names for exactly that risk across .bgeo, .bgeo.sc, .vdb, .abc and .usd outputs.
It flags sim and geo caches with missing version tokens, names that will collide, and outputs that skip your shot / asset / task convention, so two caches never overwrite each other and every file says what it is. Consistent cache naming is the difference between a re-cache and a clean reuse. Read about geo, sim, VDB and USD cache naming →
Houdini to Unreal / Unity handoff checker
Assets that are clean in Houdini can still break in an engine. Hive checks the mesh, texture, USD and cache exports headed for a game engine and flags names that do not match Unreal or Unity conventions before they land in the project.
That covers Houdini to Unreal naming (SM_/T_/M_ prefixes, folder structure), Houdini to Unity export structure, USD export naming and VDB/cache delivery checks - so a Houdini Engine handoff opens tidy in the engine instead of as a pile of MyGeo1 imports. Houdini to Unreal checklist → · Houdini to Unity checklist →
Houdini cache & sim disk report
Cache sprawl, not project files, is what fills a studio's storage. Hive groups your geo, VDB and sim caches into sequences and version families and ranks them by disk usage, so the biggest offenders surface in seconds. It flags stale (superseded) versions you can archive, missing frames from a sim or render that didn't finish, and totals disk per cache - reading file names and sizes only, nothing opened.
Turn "the drive is full again" into a five-minute triage: keep the current version, archive the dead ones, reclaim the space. See the cache & sim disk report →
Houdini USD (.usda) dependency checker
A USD stage is a web of sublayers, references and payloads pointing at other files - and one wrong path opens it broken. Because .usda is plain-text USD, Hive resolves it in your browser without opening Houdini or USD: every sublayer, reference, payload and asset path, each marked portable or absolute, with resolve status against the scanned folder.
It then builds a collect-files list - every layer and asset the stage needs - so a Solaris handoff arrives complete instead of full of missing references. Read about the USD dependency checker →
houdini.env & packages checker
Why won't your HDA or tool load? It almost always starts in houdini.env or a package JSON. Hive parses both and flags the config mistakes that break a setup: a HOUDINI_PATH set without the & token (which drops Houdini's defaults), unresolved paths, duplicate or disabled packages, and absolute local paths that won't move to another machine.
The payoff is a reproducible studio setup - onboarding a new artist or render node becomes "make it pass the check". Paste a houdini.env or scan a workstation folder. See the houdini.env & packages checker →
