Are you juggling multiple file formats in Houdini and not sure which one fits your workflow?
Maybe you’ve exported a heavy scene as Alembic only to face missing attributes on import. Or you used BGEO caching and still saw slow viewport playback.
And what about USD? That format promises scene layering and collaboration, but when should you integrate it?
These frustrations can slow you down and add complexity to your pipeline.
This guide cuts through the jargon. You’ll understand format differences, performance impacts, and the ideal use case for each file type.
What do BGEO, Alembic (.abc) and USD (.usd/.usdc/.usda) actually represent in Houdini?
The three formats—BGEO, Alembic and USD—aren’t just file extensions; they embody distinct caching and interchange philosophies. Houdini’s native BGEO is optimized for procedural workflows, Alembic focuses on baked geometry and transform hierarchies, and USD extends into full scene graphs with layering, variants and instancing.
BGEO is Houdini’s binary geometry cache format. When you drop down a File SOP or use ROP Geometry Output, BGEO stores point positions, primitives and all attribute data exactly as Houdini represents it in memory. It preserves custom attributes, packed primitives and procedural groupings, making it ideal for mid-pipeline caching of SOP networks. Sequence files (.bgeo.sc) or compressed (.bgeo.gz) reduce I/O overhead.
Alembic (.abc) is an open-source format designed for robust interchange of baked geometry and transform hierarchies. Using the Alembic ROP or Alembic SOP, Houdini serializes per-frame vertex positions and object xforms, but flattens procedural dependencies. It excels when sending animated props to Maya, Katana or C4D without Houdini-specific attributes. Alembic archives support hierarchical scene axes and are lightweight on custom attribute encoding.
USD (.usd/.usdc/.usda) stands for Universal Scene Description and represents a holistic scene graph. In Solaris LOPs, USD layers carry geometry payloads, materials, lights and cameras with non-destructive overrides. You can reference external files, create variant sets for model versions and leverage instancing at immense scale. USD’s ability to compose layers makes it the go-to for lookdev, shot assembly and multi-department pipelines.
How do BGEOs work and when should you cache to .bgeo / .bgeo.sc?
The BGEO format is Houdini’s native geometry container, representing GU_Detail in a serialized form. Each file stores points, primitives and arbitrary attributes exactly as Houdini would in memory. It preserves topology, custom attributes and packed primitives without conversion, ensuring a lossless round-trip within SOP networks and across Houdini sessions.
Files with the .bgeo extension are uncompressed, while .bgeo.sc applies on-the-fly compression (Snappy by default). Compression reduces disk footprint and often improves I/O throughput by trading minimal CPU decompression overhead for faster read/write speeds. Both formats support sequence naming conventions (e.g., geo.$F.bgeo.sc) for frame-by-frame caching.
- Use .bgeo when disk space isn’t a concern and you need instant load without decompression overhead.
- Use .bgeo.sc for large point clouds, particle sims or dense volumes where compressed storage speeds up scene loading.
- Switch to .bgeo.gz or custom schemes if cross-app compatibility or maximum compression ratios matter more than speed.
Typically, cache to BGEOs whenever you need to freeze a procedural chain before an expensive operation—fracturing networks, pyro preprocessing or curve generation. Drop a File Cache SOP at key SOP nodes to bake out geometry, then disable upstream cook patterns. This isolates sections, speeds up viewport feedback and enables reproducible results.
Remember that BGEOs are Houdini-specific. For asset handoff or render pipelines using other DCCs, convert to ALEMBIC or USD. Reserve BGEO caching for internal performance and iterative workflows, not for long-term interchange.
When is Alembic the right choice for caches and interchange (and what to watch for)?
Alembic shines when you need a robust, baked-geometry cache format for both Houdini and other DCC tools. It stores vertex and transform data across time-samples, preserving topology as well as UVs, normals and custom attributes. Unlike BGEO, it’s universally recognized—ideal for handing off rigid-body sims, character rigs or particle snapshots to Maya, Blender or rendering farms without losing per-frame detail.
- Fluid or pyro sim exports where per-point velocity or temperature fields must travel intact.
- Rigid-body and destruction caches shared between artists on different platforms.
- Crowd and hair/foliage sims requiring high-fidelity interpolation on import.
- Game-engine exports that consume Alembic geometry for in-engine playback or baking.
When authoring in Houdini, use the Alembic ROP or Alembic Archive SOP to control time-samples and partitioning. Limit subframe samples to what the renderer or engine needs—over-sampling inflates file size. Pack geometry into packed primitives before export to reduce overhead when dealing with thousands of objects in a single .abc file.
Watch out for attribute mismatches on import: Alembic won’t always preserve packed-primitive metadata unless you explicitly promote it to vertex or primitive attributes. Versions must match; Houdini’s importer can drop unknown data from newer .abc versions. Finally, plan your file structure: splitting by frame ranges or object groups prevents single-file bottlenecks and improves streaming performance in production pipelines.
When to use USD in Houdini pipelines — Solaris/LOPs, scene assembly and lookdev
Within Houdini’s Solaris/LOPs context, adopting USD transforms scene management. By leveraging USD layering and composition, artists assemble modular shots from referenced assets. Solaris’s node-based approach ensures non-destructive overrides, metadata propagation, and direct interoperability with other DCC apps via Universal Scene Description.
During scene assembly, import base geometry USDs with the USD Import LOP, then reference multiple shots or props. Use layer stacks to override transforms, variant sets for LODs or shot-specific changes, and the Merge LOP to build a unified stage. This approach eases shot updates: replace a single prim reference to propagate changes automatically.
- Reference LOP: link external USD files
- Edit LOP: apply non-destructive overrides
- Variant LOP: switch between model versions or LODs
- Material Library LOP: define shared shader networks
For lookdev, Solaris lets you assign shading networks via Material Library LOP and Assign Material nodes, leveraging UsdShade definitions. Previews update in real time using Karma or Hydra delegates, streamlining shader feedback. Final renders remain in USD, preserving layer integrity and ensuring consistent results across shots and departments.
How to choose between BGEO, Alembic and USD for common production scenarios
Deciding between BGEO, Alembic and USD depends on factors like data complexity, collaboration needs and downstream tools. In Houdini, each format shines in different stages—simulation caching, cross-app exchange or scene assembly. Understanding these roles optimizes performance and streamlines team workflows.
For high-density simulations (fluids, pyro, grains), BGEO files through a File SOP or Geometry ROP offer the fastest read/write speeds. They support native attributes, packing workflows and versioned caches. Use BGEO when you need incremental updates, attribute retention and minimal conversion overhead.
When exchanging animated or deforming geometry with other DCCs or renderers, choose Alembic. Its topology-blending, time samples and wide application support make it ideal for character caches or crowd exports. In Houdini, the Alembic ROP lets you bake transforms and point caches in one step, ensuring reliable playback in Maya, Katana or Unreal.
For large-scale shot assembly, lookdev or lighting teams, adopt USD via Solaris. USD’s layer system, variants and references enable non-destructive overrides and instancing across shots. Use the USD ROP in Solaris to publish assets with live updates, and manage complex hierarchies with Hydra-powered viewers.
| Scenario | Recommended | Key Benefit |
|---|---|---|
| High-density sim caching | BGEO | Fast I/O, attribute-rich |
| Cross-app geometry exchange | Alembic | Topology baking, broad support |
| Shot assembly & lookdev | USD | Layering, variants, instancing |
| Crowd/animation pipelines | Alembic or USD | Cache blendshapes vs hierarchical |
In summary, use BGEO for internal caching in procedural networks, Alembic for reliable data exchange, and USD for scalable scene management. Matching format to task reduces conversion steps, preserves attributes and leverages Houdini’s full procedural power.
Practical export/import and optimization tips for each format
Compression, single-file vs sequence and data layout (bgeo.sc, Alembic Ogawa, USD layers)
Deciding between a single archive and a per-frame sequence influences I/O patterns and cache performance. In Houdini, a one-file export can simplify management but may spike memory when loading. Conversely, frame sequences allow on-demand streaming and parallel write operations.
- Use bgeo.sc for on-disk compression of SOP-level caches; it applies run-length encoding per attribute and reduces file size.
- Prefer Alembic Ogawa backend over HDF5 for high-frequency reads; Ogawa stores data in smaller binary blobs optimized for random access.
- Leverage USD layering by splitting assets into a root layers, reference layers and overrides; this minimizes payload size and enables non-destructive edits.
For large-scale shots, writing out frame sequences reduces peak memory usage and allows Houdini’s geometry cache to stream only needed frames, improving viewport interactivity and render farm throughput.
Common pitfalls and fixes: missing attributes, motion blur velocities, topology changes and instancing
When sending caches between departments, it’s common to lose custom primvars or velocity channels if they aren’t explicitly promoted. Houdini’s default ROP Geometry only exports position, normals, UVs and a limited set of primvars unless you override the “Export Attributes” list.
- Enable “Export Velocity” or add your own “v” and “accel” attrs in the Geometry ROP to preserve motion blur data for renders.
- Use a Sort SOP or Name SOP before Alembic export to lock down point and primitive order, preventing mismatches when topology drifts.
- For USD instancing, pack points in SOPs and export via the USD ROP’s point instancer schema; ensure each prototype’s path is unique to maintain correct instancing.
To mitigate topology changes breaking deformation caches, either bake per-frame geometry to disk or drive deformation through point-level attributes (e.g., “rest” position). Consistent attribute naming and explicit layer references ensure reliable cross-department pipelines.