osm2cdr.com

Alembic (.abc) format: VFX baked geometry standard — export OSM city scenes for rendering

2026-03-2112 min read
3dvfxmeshanimationaswfbaked-cache
Export formats: ALEMBIC

Alembic is a VFX format with a very narrow and very powerful specialization: "baked" geometry cached frame by frame for handoff from department to department inside a film or series production pipeline. An .abc file stores already-computed vertex positions for every frame of animation — no rig, no skinning, no procedural setups. That means the render farm gets a "dumb" but absolutely deterministic cache: no Maya node, no Houdini graph, no script is needed to reproduce exactly the geometry the director approved at dailies. A joint development of Sony Pictures Imageworks and Industrial Light & Magic (Lucasfilm), announced at SIGGRAPH 2010 and released as version 1.0 on August 9, 2011, Alembic has been under the Academy Software Foundation (ASWF) since 2018 — alongside OpenColorIO, OpenVDB, and OpenEXR. On osm2cdr.ru alembic_exporter.py takes buildings from PostGIS via Building3DExporter, extrudes them by real heights, and writes .abc through PyAlembic SDK with the Ogawa backend — a ready-to-use VFX-scene cache for a large city.

Map generation of Samara city center

History: Sony Imageworks + ILM + ASWF

By 2009 every major VFX studio had its own geometry cache format: Sony Pictures Imageworks had .gto, ILM had .geo, Pixar and DreamWorks had internal solutions. All these formats solved the same job — "bake" animated character or simulation geometry into a file that gets handed to the render department. The render artist shouldn't see the rig, shouldn't re-run the simulation — they just have final vertex positions per frame and their job is to set the camera, lights, materials and press render.

Sony Imageworks and ILM decided to join forces and produce an open-source common format. The Alembic project was announced at SIGGRAPH 2010 in a panel session. The chief architects came from Sony Imageworks (with openEXR-style openness experience) and ILM (production-grade tooling experience). Version 1.0 shipped on GitHub on August 9, 2011, under a BSD license.

Industry adoption was fast: Pixar added Alembic export to the RenderMan-to-Maya pipeline by 2012, DreamWorks Animation, Animal Logic, Weta Digital, MPC — all took the format as a standard exchange between Maya, Houdini, Katana, and Nuke. By 2015 every mainstream DCC package (Maya, Houdini, 3ds Max, Cinema 4D, Blender, Modo) had native Alembic import/export.

In 2018 the Academy Software Foundation (ASWF) — a non-profit under The Linux Foundation founded by the Academy of Motion Picture Arts and Sciences — accepted Alembic into its project portfolio alongside OpenColorIO, OpenVDB, and OpenEXR. That locked in long-term support from a studio-sponsored organization (Disney, Sony, DreamWorks, Netflix, Apple, Amazon, Autodesk, NVIDIA, AMD, Epic Games).

HDF5 → Ogawa: the internal backend

Alembic has a two-layer architecture: the top layer is an API (C++ library libAlembic); the bottom is the backend storage. Originally in version 1.0 (2011) the backend was one — HDF5 (Hierarchical Data Format 5), a scientific binary format from NCSA widely used in physics and climatology. HDF5 gave proven structure and a tooling ecosystem, but had issues: a heavy dependency, slow random access on large files, lock contention in parallel writes.

In version 1.5.0 (December 2013) Sony Imageworks shipped Ogawa — a custom backend designed specifically for film I/O. Ogawa is optimized for two operations: sequential write of large geometry volumes (cache write) and random read by frame range (rendering a chosen range). Ogawa's advantages over HDF5:

  • 4–25x faster on read (random access)
  • 15–25x smaller memory footprint at load time
  • Simple self-contained C++ code with no external deps (HDF5 is ~500K lines of C)
  • Smaller file sizes (~10–20% more compact for typical VFX scenes)

Since version 1.5.0, Ogawa is default. HDF5 remains available for legacy compatibility — old .abc files from 2011–2013 still read. Modern exports (Maya 2018+, Houdini 16+, Blender 2.8+) always write Ogawa.

The PyAlembic SDK we use in alembic_exporter.py wraps the C++ library and automatically picks Ogawa via OArchive(filename, "myArchive", Alembic.AbcCoreOgawa.WriteArchive()).

What's inside .abc: scene-graph, baked-only

Alembic's structure is a hierarchical scene-graph, like USD or a Maya scene, but with a critical restriction: everything is "baked." Supported node types:

  • Xform — transforms (translate/rotate/scale per frame)
  • PolyMesh — polygonal mesh (vertices, normals, UVs, vertex colors, per-frame velocities)
  • SubD — subdivision surface (control cage + subdiv level)
  • Curves — curves (hair, fur, paths)
  • Points — particle cache (positions, velocities, IDs)
  • NuPatch — NURBS patches
  • Camera — camera (focal length, aperture, focus distance per frame)
  • Light — light (since 1.7.0, limited support)

Each node may be time-varying: every frame or sub-frame (for motion blur) stores new samples. A PolyMesh, for instance, may have fixed topology (constant vertex count, only positions change) or changing topology (variable vertex count — for a destruction FX shot).

What is not and cannot be in Alembic: - Rigs (joints, skin clusters, deformers, IK chains) — authoring data, baked into vertex positions - Constraints, expressions, procedural setups - Materials — Alembic is geometry-only (materials are assigned in the renderer) - Animation curves (FCurves) — only final per-frame values

This is a fundamental architectural decision: Alembic is a cache, not a scene description. Compare with USD, which is a full authoring and scene composition layer.

Map generation of Kazan city center

Strengths and weaknesses

Strengths. Industry-standard in film VFX — every studio from Pixar to Weta uses Alembic for cross-department handoff. The Ogawa backend gives high performance: a million polygons reads in seconds, not minutes. Cross-DCC: Maya → Houdini → Katana → Nuke without geometry loss. Self-contained — doesn't need a rig or procedural setup to reproduce. ASWF stewardship — long-term support guarantee. BSD license — no royalties. Supports fixed and changing topology — works for character animation and destruction sims alike. Time-varying samples with motion blur support.

Weaknesses. Not an authoring format — you can't edit an Alembic, you regenerate it from the source DCC. Geometry-only — materials and lights live separately. Files can be huge: one million polygons × 240 frames × 4 bytes per coordinate = gigabytes. No built-in compression (external pipeline tools exist but aren't in the spec). Limited game-engine support: Unreal Engine 5 imports Alembic for groom (hair) and cinematic alembic mesh, but that's not the main use case. Not for real-time / web — the format is too heavy; convert to glTF or USD.

Alembic vs FBX vs USD vs COLLADA

VFX 3D formats are not one market but several distinct usages:

  • Alembic (.abc) — baked geometry cache only. For cross-department handoff inside VFX/animation pipelines. No rig, no automation.
  • FBX (.fbx) — full DCC scene: rig, skin, animation curves, materials. For game engines (Unity, Unreal) and cross-DCC authoring. Closed-source Autodesk format.
  • USD (.usd/.usda/.usdc/.usdz) — Pixar's 2016 scene composition layer. Describes assembly, references, variants, materials, layers. For managing large pipeline assemblies.
  • COLLADA (.dae) — Khronos's 2004 XML 3D exchange. Was popular for cross-tool exchange before glTF and USD arrived. Largely legacy now.

In a modern film/animation pipeline they work together: USD assembles the scene (which characters, which props, which layers), Alembic caches the animated geometry of each, FBX delivers to game engines (trailers, in-engine cinematics).

Use cases

VFX artist on a Marvel film. An animator in Maya assembles a city chase: the hero flies between buildings. The buildings are an OSM export of New York to Alembic with each building's real height (that's our use case). The animator references the .abc, sets a camera path, bakes the hero's rig to its own .abc, hands everything to Houdini for FX sims (façade destruction, debris) and to Katana for final RenderMan rendering.

Large-scale city model artist for a blockbuster. Films like Inception, Blade Runner 2049, and Tenet contain massive destruction or flythrough city scenes. The city geometry is usually built procedurally in Houdini, but it's sometimes faster to grab OSM data via osm2cdr, import it as Alembic, and use it as a foundation for further customization.

Heritage 3D studio. Photogrammetry-scanning a historical city center (old Prague, Carthage, Rome) produces millions of polygons. Converting to Alembic lets that geometry move into VR walkthroughs with baked geometry, without live streaming.

FX artist, cloth/smoke simulation over a city. Houdini simulates explosion smoke over a city, or cloth wrapping buildings. The result — meshed simulation in Alembic with changing topology. Handed off to the render artist for final pass.

Architectural visualization for film. An architecture studio produces viz for a documentary about a city's future. The scene — a 50-year-ahead concept project. Buildings export as Alembic for later compositing with the real city in After Effects.

Software for Alembic

Autodesk Maya. Paid DCC from Autodesk. Native Alembic since 2014 via AbcExport / AbcImport plugins (built-in). The most mature workflow: rigged character → Cache Selection → Export Alembic → ready .abc for downstream.

SideFX Houdini. Paid (Houdini FX) or free (Houdini Apprentice — non-commercial). Native support through Alembic ROP (write) and Alembic SOP (read). Houdini is the leader for complex Alembic workflows, especially FX (destruction, fluids).

Foundry Katana. Paid. Industry-standard lighting and rendering pipeline for film. Alembic is the primary geometry input format in Katana via the Alembic_In node. Pairs with RenderMan, Arnold, V-Ray.

Autodesk 3ds Max. Paid. Alembic support through built-in importer/exporter since 2017. Used in architectural visualization and motion graphics.

Maxon Cinema 4D. Paid. Native Alembic support. Popular in motion graphics and MoGraph scenes.

Blender. Free open source. Full Alembic import/export through Cycles/Eevee renderers. Workflow: File → Import → Alembic (.abc). Used in indie VFX and educational contexts.

Pixar RenderMan. Paid (free for non-commercial). Native Alembic reading via RiArchive or RiPolygon calls. Used in RIS rendering pipelines for feature films.

Chaos V-Ray, Autodesk Arnold, Redshift, OctaneRender. Every mainstream production renderer reads Alembic natively or via DCC plugins.

Unreal Engine 5. Imports Alembic for grooms (Hair/Fur via UAlembicImportFactory) and cinematic-quality geometry cache (since UE 4.27+). Not for game runtime use — only for cinematics.

PyAlembic SDK. Free, open source. Python bindings to the C++ libAlembic. That's what we use in alembic_exporter.py to write .abc files from PostGIS data.

Pipeline in OSM2CDR

Our alembic_exporter.py inherits from Building3DExporter (like stl_exporter.py, obj_exporter.py, gltf_exporter.py). Pipeline:

  1. Layer load. PostGIS returns buildings as WKB via ST_AsBinary, skipping GeoJSON parsing. That gives 10–50x speedup on large bboxes (the WKB fast-path in layer_builder.py).
  2. Calculate building height. Each building gets a real height by these rules:
  3. height tag (meters) — priority 1
  4. building:levels × 3.0 m — priority 2
  5. Type-based fallback: apartments → 15 m, house → 5 m, skyscraper → 100 m, default 6 m
  6. Extrusion. Every OSM polygon becomes a prism via trimesh.creation.extrude_polygon. We get a mesh with triangulated top and bottom faces plus side walls.
  7. Build the Alembic scene-graph. Create OArchive with the Ogawa backend. The root is an OObject called osm_city. Inside — OPolyMesh per building (or a single merged mesh for the whole bbox when merge_buildings=true).
  8. Set sample. For each OPolyMesh we set one sample (static, not animated) via OPolyMeshSchema::Sample with face-counts, face-indices, and vertex positions.
  9. Hierarchy. Buildings are grouped under OXform nodes by district (if the PostGIS query returned admin_level=10), which simplifies selection in Houdini/Maya.
  10. Write. PyAlembic writes the final .abc. The archive closes automatically on del archive.

Coordinates in Alembic are meters (metric), Y-up by default (like Maya), which matters: our Building3DExporter emits Z-up (geo standard), and we apply axis conversion on write. When importing into Houdini, apply a Y→Z swap in Alembic SOP parameters if you need to return to geo orientation.

Although Alembic is designed for animated caches, our export is single-frame static. That's a valid use case: a VFX artist often wants "a city as background" — static, but in a pipeline-friendly format. If animated city becomes a need (e.g., time-of-day shifts with real building changes), we'll add multi-sample support via a frames=240 parameter.

Map generation of Moscow city center

FAQ

Can I edit an Alembic file? No. Alembic is a cache, not an authoring format. If you need to change geometry — regenerate from the source DCC (Maya, Houdini) or use procedural re-export. Inside Houdini you can load .abc via SOP, modify procedurally, and write a new .abc — but that's not editing, that's creating a new cache.

Ogawa or HDF5? Always Ogawa for new files. HDF5 is legacy for compatibility with 2011–2013 pipelines. PyAlembic writes Ogawa by default — we don't override. If you bump into an .abc with HDF5 backend, the Alembic SDK reads it transparently, but performance is 4–25x lower.

Is there a smaller alternative for web or AR? Yes — glTF (.glb) for real-time/web and USD (.usdz) for Apple AR Quick Look. Alembic is too heavy for web: gigabyte-scale files, complex C++ library. For web visualization of an OSM city, use our glTF export.

Will Alembic work in Unreal Engine for game runtime? No, not for runtime. UE5 imports Alembic for cinematic mesh cache (sequences in Sequencer) and for grooms — but game-runtime geometry must be Static Mesh / Skeletal Mesh, not Alembic. For real-time city rendering in UE, use FBX/glTF.

Maximum area for Alembic export? On osm2cdr.ru — 100 km² for basic tier, unlimited for pro/enterprise. Practically, exporting a large city (all of Moscow, ~2500 km²) produces a 5–15 GB file — fine for a VFX pipeline, but requires terminal-based download via CLI / API, not a browser.

Sources

Related articles

FBX (Filmbox) format: industry-standard 3D pipeline — export OSM 3D buildings to FBXUSD (Universal Scene Description) — Pixar Standard for VFX, Apple AR and NVIDIA OmniverseCOLLADA (DAE) — Khronos XML Standard for 3D Scene Exchange
← All articles