gemeinwert
BIM CVP

gemeinwert  /  wiki  /  model  /  usd

USD — Universal Scene Description

OpenUSD is a scene-graph and composition system born at Pixar for film, now the emerging interchange layer for large 3D scenes in AEC. It is the geometry and visualisation companion to IFC — not a replacement for IFC's building semantics.

In one sentence

USD describes what a scene looks like and how scenes compose; IFC describes what a building is. IFC 5 brings them together by adopting USD for the geometry and serialisation layer.

Where it comes from

Universal Scene Description was developed by Pixar and open-sourced in 2016. In 2023 it moved under the Alliance for OpenUSD (AOUSD) (Pixar, Adobe, Apple, Autodesk, NVIDIA and others) to drive a vendor-neutral specification. Its strength is not a single geometry kernel but composition: assembling huge scenes from many independently authored, referenceable, override-able layers — exactly the problem a multi-discipline building model has.

The concepts that matter

ConceptWhat it is
StageThe composed, final scene a tool actually sees — the result of evaluating all layers.
LayerA single .usd file contributing data. Layers stack and override like non-destructive edits.
Prim"Primitive" — a node in the scene graph (a mesh, an xform, a light, a discipline subtree).
Composition arcssublayers, references, payloads, variants, inherits — the rules that merge layers into a stage.
PayloadA deferred reference: heavy geometry loads only on demand. Essential for site-scale models.
Variant setSwitchable options inside one prim (design option, LOD, construction phase).

The practical consequence: an architecture layer, a structure layer and an MEP layer can each be authored separately and composed into one coordinated stage without flattening — conceptually close to how a federated IFC model is assembled, but with a strong override and variant system.

File formats

ExtensionFormatFor
.usdaASCII textHuman-readable, diffable, good for small layers and review.
.usdcBinary "crate"Compact, fast to load. Default for heavy geometry.
.usdEither of the aboveGeneric extension; container can be ASCII or binary.
.usdzUncompressed ZIP packageSingle-file delivery bundling stage + textures. The shareable artefact.

USD vs IFC — not a competition

TopicIFCUSD
Primary purposeBuilding semantics — what objects are and how they relateScene composition — geometry, look, assembly at scale
StrengthTyped entities, property sets, classification, life-cycle dataHuge scenes, non-destructive layers, variants, real-time visualisation
WeaknessHeavy for pure visualisation / DCC pipelinesNo native construction semantics (no IfcWall, no Pset, no IDS)
GovernancebuildingSMART / ISO 16739-1Alliance for OpenUSD (AOUSD)
Role hereSource of truth for building dataGeometry / serialisation layer, esp. under IFC 5

The IFC 5 connection

IFC 5 (in development, alpha — do not specify in tenders) is the key reason USD belongs in a BIM wiki. The IFC 5 direction adopts USD as the geometry and scene-composition substrate while keeping the building semantics as an IFC schema on top, with a JSON-based serialisation. Read it as: USD for the scene, IFC for the meaning. This validates treating USD and IFC as complementary layers rather than rivals — and it means a long-lived CDE should leave room for a USD-backed schema target without abandoning today's IFC 4.3.2.0 foundation.

Tooling (2026, indicative)

ToolUSD role
usdview / usdcat (OpenUSD)Reference viewer and inspector, ground truth for composition
NVIDIA OmniverseUSD-native collaboration and real-time aggregation
BlenderUSD import/export, growing layer support
Autodesk (Revit/3ds Max ecosystem)USD export paths, AOUSD member
Apple Quick Look.usdz AR preview on iOS/macOS

Mapping to signed events

BIM-CVP treats a USD deliverable exactly like an IFC deliverable: a signed file container with a metadata event, not a stream of prims. Millions of prims as individual events would be unusable and semantically pointless — USD is already a complete self-contained scene. 

kind:1063  NIP-94 File metadata
  tags: [
    ["url",   "https://blossom.example/<sha256>"],
    ["m",     "model/vnd.usdz+zip"],          # or model/vnd.usd
    ["x",     "<sha256>"],
    ["size",  "<bytes>"],
    ["schema",         "USDZ"],               # USD, USDC, USDA
    ["authoring-tool", "Omniverse"],          # Blender, …
    ["discipline",     "coordination"],       # architecture, mep, …
    ["iso19650-state", "Shared"],             # WIP / Shared / Published / Archive
    ["a",              "<project-ref>"]
  ]
  content: { stage_name, prim_count, notes }

kind:30904  File reference (parameterised replaceable)
  d: <file-guid>
  Links the NIP-94 event, adds project-specific fields
  (replacement version, stage, paired IFC file-guid)

Where a USD scene is the visualisation twin of an IFC model, the kind:30904 reference carries the paired IFC file-guid so the semantic model and its scene stay provably linked by hash and signature.

Practical pitfalls

  • Treating USD as a BIM model. It has no IfcWall, no property sets, no IDS binding. Use it for geometry/coordination/visualisation, keep IFC as the data source of truth.
  • Specifying IFC 5 / USD in a tender today. IFC 5 is alpha. Stable exchange stays on IFC 4.3.2.0.
  • Broken payloads on transfer. Layers with external references/payloads break if assets are not packaged — deliver .usdz for hand-off, keep layered .usd for authoring.
  • Unit and up-axis mismatch. USD scenes carry metersPerUnit and upAxis metadata; agree them in the BAP or coordination drifts silently.

Read on

Sources