A single pyro shot can leave hundreds of gigabytes of .bgeo.sc, .vdb and sim caches behind - most of it superseded the moment the next version is written. Multiply that across a show and cache sprawl, not project files, is what fills a studio's storage. A disk report tells you where it all went.
Why cache sprawl kills studio storage
Houdini caches are large, sequential and versioned by re-caching. Every time an FX artist tweaks a sim and re-caches, a whole new frame range lands on disk beside the old one, and nothing deletes the previous version. There is no built-in "you have 40 dead versions of this cache" warning. Over a few weeks a shared drive fills with old v001 and v002 ranges nobody will ever load again, plus half-finished caches from crashed jobs. The renders folder never shrinks on its own - someone has to look.
Grouping caches into sequences and version families
Raw file listings are useless here: a single 240-frame VDB cache is 240 files, and a report that lists them individually hides the shape of the problem. The fix is to group. Hive parses every cache name into a sequence (one base name plus a frame range, collapsed into a single row) and then groups sequences that share a base name into a version family - SHOT010_pyro_v001, v002, v003 become one family with three versions. Now you can see, per cache, how much disk each version holds and which is current.
A cache like this:
$JOB/sim/pyro/SHOT010_pyro_v003.0001.vdb ... .0240.vdbcollapses to one line - SHOT010_pyro v003, 240 frames, 86 GB - inside a family that also holds v001 and v002. That is the unit you actually make decisions about.
What the report surfaces
- Disk usage per cache. Every sequence and family totalled, so you know the real cost of each cache rather than a per-file blur.
- Biggest offenders. Families ranked by size - the handful of caches holding most of your storage, which is almost always where the reclaimable space lives.
- Stale / superseded versions. Any version older than the newest in its family, flagged as archivable once the current one is approved. Deleting dead versions is the fastest way to get a drive back.
- Missing frames. Gaps in a sequence's frame range - a sim or render that did not finish - so you re-cache the broken one instead of shipping a hole.
- Cache type breakdown. Geo (
.bgeo/.bgeo.sc), VDB volumes and simulation caches split out, so you can see whether it is geometry or heavy sim data filling the drive.
From report to reclaimed space
The workflow is simple: scan, sort by biggest offender, and for each large family keep the current version plus maybe one fallback, then archive or delete the superseded ones. A report that groups by version family turns "the drive is full again" into a five-minute triage. Pair it with a clean cache naming convention so versions are unambiguous in the first place, and a standard $JOB folder structure so caches live where the report expects them.
Run the disk report in your browser
Hive scans your project folder locally - Chrome or Edge via the File System Access API, or drag and drop - and reads only file names and sizes to build the report. Nothing is opened and nothing is uploaded; a .vdb is never parsed, just measured. Point it at a shot, get the version families and offenders in seconds, and export the list for the person who does the cleanup. It is one part of the full project audit.
Frequently asked questions
How do I find what's eating disk in a Houdini project?
Hive groups every geo, VDB and sim cache into sequences and version families and ranks them by disk usage, so the biggest offenders surface immediately. It reads file names and sizes only - nothing is opened - and the scan runs locally in your browser.
What is a stale or superseded cache version?
When a File Cache is re-cached to v002, v003 and so on, the earlier versions usually stay on disk. Any version older than the newest in its family is superseded - safe to archive or delete once the current version is approved. Hive lists these so you can reclaim the space they hold.
Can it detect missing frames in a cache sequence?
Yes. Hive reconstructs each cache sequence from its frame padding and flags gaps - missing frames that mean a render or sim did not finish - without opening a single file.