IFC, GLB and OBJ exports

The three model exports preserve different truths. IFC keeps walls, openings, doors, windows, spaces, storeys and their relationships editable in BIM software. GLB keeps the live viewer's meshes, PBR materials and authored appearance compact enough for the web. OBJ keeps widely importable mesh geometry when the receiving application understands neither of those formats.

From JavaScript

import { compile, exportGlb, exportIfc, exportObj, parseNdjson } from 'bimtex';

const { entities } = parseNdjson(source);
const compiled = compile(entities);

const ifc = exportIfc(compiled, { fileName: 'clinic.ifc' }); // string
const glb = await exportGlb(compiled);                        // Uint8Array
const obj = await exportObj(compiled);                        // string

In Node, all three values can go straight to fs.writeFileSync(). IFC export keeps the compiler's zero-dependency path. GLB and OBJ use the package's optional pinned three dependency; installations made with npm install --omit=optional need npm i three before calling it.

From the CLI

npx bimtex clinic.ndjson --ifc --glb --obj -o issued/

That command compiles once, then writes the normal SVG sheet set beside clinic.ifc, clinic.glb, clinic.obj and diagnostics.json. Adding --only plan keeps only the selected drawings without changing any model export.

What IFC4 contains

The first IFC contract covers the architectural building subset:

Every IFC object, relationship and property set gets a deterministic, 22-character IFC GlobalId. Its original id and type also live as typed values in Pset_Bimtex; host, level, material and room use are included when known. Re-exporting the same model preserves those identities without matching geometry.

Mapped objects also receive the relevant IFC common property set: building, storey, space, wall, door, window, slab and roof common sets are supported. Reference carries the bimtex id, while IsExternal is included where the compiler can determine it. The exporter does not guess fire ratings, load-bearing status or other properties that were never authored.

Walls, doors, windows, slabs and roofs have one IfcMaterial association. Openings and spaces do not: an opening is a subtraction feature, not a physical material-bearing product. This IFC material support preserves identity and category, not render appearance or layered construction. Use GLB for PBR colours, transparency and textures.

The exporter enforces a single spatial parent for each site, building, storey and space, a single storey container for every physical product, and complete void/fill relationships for openings, doors and windows. Unsupported entity types are omitted rather than mislabelled as generic BIM objects. IFC import is not shipped yet.

What GLB contains

GLB serialises the same complete scene as the Three.js viewer, including site geometry and supported authored looks. bimtex's z-up axes are carried into glTF's Y-up convention by one document transform. Mesh node extras retain eid and kind; roof nodes retain the roof and plane ids, which lets a viewer select semantic objects without parsing display names.

GLB is the delivery format for Three.js, WebGPU viewers and sharing. IFC is the handoff format when the next person needs to keep authoring the building.

What OBJ contains

OBJ exports the same scene geometry in metre-based, z-up coordinates. Object names carry bimtex entity ids, and instanced arrays or procedural roof parts are expanded so no occurrence silently disappears. The header records the units and axes because Wavefront OBJ has no standard field for either.

OBJ is deliberately geometry-only. It emits no MTL sidecar, PBR appearance, scene hierarchy or BIM relationships. Prefer GLB anywhere it is accepted; choose OBJ when a mesh editor or visualisation tool needs the broadest simple fallback. All three are complementary outputs, not conversions of one another.