Explorations into the compatibility between IFC5's IFCX format and OpenUSD, using Houdini LOPs as the primary working environment. These tools do not require IfcOpenShell, Bonsai, or any Python IFC library — just Houdini and the data files.
The core questions being investigated: What is the role of USD in IFC's future? What is the role of IFC in USD's future?
The verbosity of these documents is a compound problem, for which I apologize. In the era of Claude Code, I accept its usefulness as an assistant but believe that the responsibility of authorship is on the human responsible for publishing — and I'm afraid my own verbosity is almost as bad as my assistant's.
Direction, project management, testing, and editing are all done by myself, Nathaniel Edmunds, but much of the analysis and almost all of the coding keystrokes are LLM-generated. I am a learner, as I believe we all are, and need a certain amount of engagement and testing in order to validate and invalidate hypotheses; these tools serve that purpose. I acknowledge the carbon costs that come with this new layer of digital infrastructure and only make use of it under the analysis that if we can put it to effective enough use that we may be able to leverage it against the problems it contributes to.
The starting point: early explorations into whether IFCX files can be imported into a USD stage, worked with in Houdini, and exported back to IFCX without meaningful data loss. The answer is broadly yes, with known caveats documented in the folder README.
ifcx_usd_lops_scene_importer_v5.py— reads an IFCX (IFC5 JSON) file and builds a USD stage inside Houdini LOPs, preserving spatial hierarchy, geometry, materials, and IFC metadata. Can also run standalone withusd-coreinstalled.usd_ifcx_lops_authoring_v2.py— the reverse writer: walks a USD stage and writes a valid IFCX JSON file targeting IFC5 alpha schema conventions. Frozen as the canonical diff oracle for the AESOP pipeline — do not modify.ifcx_usd_roundtrip_analyser.py— validation tool that compares an original IFCX file against a round-tripped version, reporting UUID coverage, attribute key losses, geometry counts, and IFC class distributions.hello-back.ifcx— reference output:hello-wall.ifcxtaken through the importer → Houdini LOPs → exporter round-trip. Useful as a fixed diff baseline.
The active pipeline for importing legacy IFC4 (and IFC2X3) files into a USD stage and writing them out as IFCX for inspection in the IFC5 alpha viewer. "Daytripping" is deliberate — this is a one-way trip into the IFCX/USD ecosystem, not a round-trip.
The two co-versioned scripts implement the AESOP schema: a disciplined set of
customData dictionaries and ifc:* custom attributes that give every prim a
structured IFC identity. Three production-scale BIM models have been taken through
this pipeline (residential to 14,000+ element commercial).
bonsai_to_aesop_v074.py— Bonsai IFC→USD exporter (Houdini Python LOP). Reads IFC data from a Bonsai-populated Blender scene and writes a layered USDA output: one file per storey plus shared_materials.usda,_types.usda,_spaces.usda, and_assemblies.usda, all composed byIfcProject.usda.aesop_ifcx_v074.py— AESOP USD→IFCX writer (Houdini Python LOP). Walks a USDA stage and emits a valid IFCX JSON file. Handles Y-up→Z-up coordinate correction for downstream IFC tools.AESOP_known_issues.md— register of conscious tradeoffs and known limitations with status, impact, mitigation, and future path for each.
See the folder README for full documentation of the AESOP schema, scene graph structure, and current development status.
USD-native parametric authoring scripts: building elements authored directly in
Houdini LOPs without an IFC source file, using the same AESOP schema as the
IFC4-LOPs Daytripping pipeline. These serve as both a proof-of-concept for
original IFCX content creation and as a test bed for schema design decisions.
aesops_hello-all.py— parametric wall with two windows, matching the buildingSMARThello-wall.ifcxreference dimensions. Demonstrates the full v07.4 prim structure:def Xform (kind=component)element roots, typedmesh/andcrv/child Scopes,customData = { dictionary ifc = { ... } }, dual-write inlineifc:*attributes, TypeLibrary withinstanceable = trueprototypes, and the completegroup → componentmodel hierarchy.AESOps_roadmap.md— milestone tracking for the parametric authoring work.
The three folders represent three entry points into the same destination:
| Folder | Entry point | Direction |
|---|---|---|
IFCX-LOPs Roundtripping/ |
Native IFCX (IFC5 JSON) via Houdini LOPs | IFCX ↔ USD |
IFC4-LOPs Daytripping/ |
Legacy IFC4 / IFC2X3 via Bonsai + Houdini | IFC4 → USD → IFCX |
AESOps Parametric IFCX in USD/ |
USD-first native authoring | USD → IFCX |
All three target the same coordinate convention: Y-up, metersPerUnit = 1.0,
consistent with the USD default and Houdini Solaris.