Comments

• theoryshaw

  March 26

  
  

  AI assisted proposal around prioritizing ifcgit as the differentiator

  Moult — thanks for this writeup. The curl/ffmpeg framing is exactly right and I think the list of issues you've identified is accurate. I want to offer a perspective on how these pieces might be unified around a single strategic thread rather than tackled as parallel workstreams.

  The argument in short: IFC-aware version control is the one differentiator that nobody else is building, that compounds the value of every other improvement on your list, and that addresses a pain point felt not just by developers but by every BIM coordinator, project manager, and contractor in the industry. I think it deserves to be the organizing principle of the roadmap rather than one item among many.

  Why version control is the category nobody owns

  Every other improvement on your list — web performance, TypeScript support, faster loading — is a catch-up game against Web-IFC and IFC Lite. These are important, but IfcOpenShell is playing defense. Version control is different. The proprietary platforms have crude, file-level versioning at best. No open source project has solved it at the semantic level. IfcOpenShell could define this category rather than compete in an existing one.

  IfcGit is already remarkable — nothing else does what it does. But right now it's "git applied to SPF files" rather than "version control that understands IFC." That distinction matters enormously, and closing that gap is what turns a clever tool into an industry-defining one.

  The core technical problem and how to address it

  IfcGit's current fragility stems from SPF's use of sequential step IDs as entity identity. Two authors editing the same model independently produce colliding IDs, and Git has no way to resolve this semantically. The solution is already present in the spec — GlobalIds — but they aren't being used as the primary identity layer for diffing and merging.

  I'd propose tackling this in three stages:

  First, an SPF normalizer that runs on write — sorting entities deterministically by GlobalId, stripping and reassigning step IDs based on that order. This ensures two files with the same logical content produce the same text, dramatically reducing diff noise from ID reassignment. This is achievable relatively quickly and immediately improves the IfcGit experience.

  Second, a custom Git diff driver that parses both versions into object graphs and diffs by GlobalId rather than step ID. Instead of seeing raw SPF line changes, you see: "Wall X had its height changed from 3000mm to 3500mm." Human-readable, semantically meaningful, and buildable as a Git extension today without touching Git itself.

  Third — and this is the hard part — a custom merge driver. A three-way IFC merge would identify the common ancestor, track changes in each branch by GlobalId, auto-merge non-conflicting changes, and flag true semantic conflicts where the same property was changed differently in both branches. The key insight is that most real BIM conflicts are actually auto-resolvable if you understand IFC structure. Two architects editing different rooms rarely touch the same entities.

  How this unifies the rest of the roadmap

  This is where I think the version control thread becomes genuinely powerful — it doesn't compete with the other items on your list, it gives them coherence:

  Instant IFC loading becomes an obvious prerequisite. You can't run diff and merge operations in CI pipelines with 20-second load times. Fixing loading speed stops being "a performance issue" and becomes "the thing that makes version control workflows viable at scale."

  Federation becomes more tractable. If you can diff and merge between models, cross-referencing them is a smaller conceptual step. The version control layer provides the identity and change-tracking infrastructure that federation needs.

  AI and MCP integration becomes genuinely compelling. Agents can propose changes as branches, reviewers can inspect semantic diffs, conflicts can be surfaced for human resolution. This is a much stronger story than "AI can query your model" — it's "AI participates in your design workflow with full auditability."

  Hybrid serialisation can evolve without breaking things. If SPF is normalised on write and the semantic layer is the source of truth, you can experiment with RocksDB or other formats for runtime performance without corrupting git history. The two concerns are cleanly separated.

  The pitch beyond developers

  Your curl/ffmpeg framing is compelling to developers. The version control story is compelling to everyone else. Every AEC professional immediately understands the value of:

  Branches. Merges. Pull requests. Audit trails. Rollbacks. But for your building model, and with full understanding of what actually changed.

  This pulls IfcOpenShell out of the "developer library" category into something with direct organizational relevance — something a BIM manager can explain to a client, something a contractor can point to when a dispute arises over who changed what and when.

  What I'd propose concretely

  Rather than the current roadmap as a parallel set of workstreams, I'd suggest framing development around a single north star: making IfcOpenShell the foundation for a genuinely semantic BIM version control workflow. The immediate priorities become:

  1. SPF normalizer — fast to build, immediately improves IfcGit
  2. Instant IFC loading — prerequisite for everything else at scale
  3. GlobalId-based diff driver — makes version control human-readable
  4. Semantic merge driver — the hard problem, but the one that defines the category
  5. AI/MCP integration built around the version control workflow — the future-facing layer

  Everything else on your list either falls naturally out of this workstream or can be driven by contributors with specific needs rather than requiring core team focus.

  I recognise this is a significant reframing and there's a lot of detail to work through. But I think IfcOpenShell is sitting on something genuinely significant with IfcGit, and the risk is that it stays a footnote while the team spreads energy across too many fronts. The version control story is the one that nobody else is telling — and that nobody else can tell, because nobody else has the foundation you've built.

  Would be very interested in your thoughts, and happy to dig into any of the technical specifics.
  
• theoryshaw

  March 26 edited March 26

  
  

  A follow-up

  
  One more thought to add to the above, and I think it strengthens the case further.

  AEC doesn't just lag — it lags in a predictable pattern

  The construction industry has a well-documented history of adopting technology a decade or two after every other industry, and typically adopting the version that the rest of the world is already moving away from. We got CAD after manufacturing. We got databases after finance. We got cloud collaboration after software development. And critically — we always arrive just in time to adopt the previous generation's solution.

  Version control is following exactly this pattern. Right now the AEC industry is excitedly solving its equivalent of the Centralised Version Control problem — the SVN era. BIM360, ACC, Revit Server, Trimble Connect — these are all variations on the same model: a central server holds the truth, users check out, edit, and commit back. One canonical copy. Locking. Central authority. It's Subversion, dressed up in construction industry clothing, arriving about 15 years late.

  The rest of the software world abandoned this model for a reason. Centralised version control breaks down when teams are distributed, when you need to work offline, when you want to experiment without affecting the main model, when contributors are external, when you need to audit not just what changed but why and by whom across parallel workstreams. These aren't edge cases in AEC — they're the norm. Projects span continents, consultants work offline on site, design options branch in a dozen directions simultaneously, contractors need read access without write authority.

  Git didn't just improve on SVN. It changed the underlying model entirely — from "one truth, centrally held" to "eventually consistent, distributed truth." Every contributor holds a full copy. Branches are cheap. Merging is first-class. The network is optional. Collaboration is asynchronous by default. This is what made open source at scale possible. This is what made modern software development possible.

  AEC needs to leapfrog, not catch up

  The opportunity in front of IfcOpenShell is not to build a better BIM360. It's to skip the centralised era entirely and solve the distributed, eventually-consistent workflow that the industry will inevitably need — before the industry knows it needs it.

  That means:

  • Every stakeholder holds a full, meaningful copy of the model they're responsible for
  • Changes propagate through pull requests and merges, not through central locks
  • Branches represent design options, contractor proposals, regulatory submissions — first class citizens, not workarounds
  • The network is optional — a site engineer can work offline and sync when connected
  • Audit trails are intrinsic, not bolted on
  • Conflict resolution is semantic, not file-level

  This is not a fantasy. It's exactly what Git gave software development, and the AEC industry's data — IFC, with GlobalIds, with a rich semantic schema — is actually better suited to this model than raw source code ever was. Code has no native concept of identity across versions. IFC does. We have a structural advantage that we're not exploiting.

  The window is narrow

  The centralised platforms are well-funded, deeply embedded, and moving fast. If IfcOpenShell spends the next three years closing the performance gap with Web-IFC while BIM360 and its competitors mature their centralised workflows, the industry will standardise on the SVN model and the opportunity to leapfrog closes.

  But if IfcOpenShell ships a genuinely distributed, semantically-aware version control workflow first — even as a rough but working prototype — it establishes the paradigm. Standards bodies, enterprise tools, and eventually the proprietary platforms follow paradigms set by working open source implementations. Git didn't kill SVN through marketing. It killed it by showing a better model in practice.

  IfcOpenShell has everything it needs to do the same thing to the AEC industry's collaboration problem. The question is whether that's the bet we want to make.

  
• brunopostle

  March 26

  @theoryshaw you should feed your bot with the source for ifcmerge, and see what it says - because ifcmerge is a solution to the impracticality of using GUIDs for version control.

  Basically, only some IFC entities have GUIDs, walls do but materials and most other entities don't, so the question "are these two IFC structures equivalent?" is almost impossible to answer. In an Open BIM situation you don't really care because IFC data is only shared as a read-only reference view.

  
• theoryshaw

  March 26 edited March 31

  you should feed your bot with the source for ifcmerge, and see what it says

  
  

  For this response, I used Cluade Code on top of the IfcMerge repo, and fed it our threads up to now.

  brunopostle — fair correction, and having now read the ifcmerge source, the GUID framing in the earlier posts was too simplistic. Let me try to steelman what ifcmerge is actually doing, because I think it's more elegant than the GUID approach I was describing, and it strengthens the broader argument rather than undermining it.

  The GUID approach has the problem you identified

  You're right that GUIDs only exist on "rooted" entities — walls, spaces, objects, relationships. The majority of the IFC graph is anonymous: geometric representations, material definitions, local placements, property sets, geometric contexts. These entities have no stable identity across independent edits, so asking "are these two structures equivalent?" requires graph traversal and heuristic matching that would be slow, brittle, and failure-prone. A GUID-based merge would either miss most of the graph or make expensive guesses about it.

  What ifcmerge actually does — and why it's better

  ifcmerge sidesteps the identity problem entirely by using a different anchor: the SPF numeric ID, under the Native IFC protocol. The protocol's key constraint is ID preservation — entities keep their numeric IDs across saves. Unchanged entities are written back verbatim. Deleted IDs are never reassigned. New entities are appended at the end.

  This turns the identity problem from "match semantically equivalent structures across independent graphs" into "track numeric ID changes across three versions of the same file." That's a fundamentally simpler problem, and the merge algorithm reflects it — roughly 400 lines of clean three-way logic: additions don't conflict, single-branch modifications are accepted automatically, dual modifications attempt attribute-level merging by position, and dependency integrity is checked at the end.

  The renumbering strategy is particularly clever: when both branches add entities (and thus generate colliding IDs), local entities are offset upward so remote IDs are never touched. Simple, deterministic, no heuristics.

  The Open BIM constraint is real and important

  Your point about Open BIM is one the earlier argument glossed over. ifcmerge/Native IFC only works within a single authoring context where the ID preservation protocol is respected end-to-end. The moment a file crosses a tool boundary — exported from Revit, imported into another application, re-exported — ID stability is lost and the merge approach breaks down. In Open BIM, where IFC is a read-only exchange format, you can't assume this.

  This is actually a meaningful limitation on the distributed version control argument: the "branch, merge, pull request" workflow requires participants to author natively in IFC, not export to it. That's a workflow constraint that most of the industry isn't ready to adopt yet. But it's the right direction to push, and the Native IFC movement is precisely the prerequisite for making this work at scale.

  The broader argument still holds — it just needs sharper framing

  The case for IfcOpenShell as the foundation for distributed BIM version control isn't "use GUIDs like git uses content hashes." It's "the Native IFC protocol creates the conditions under which a real merge tool becomes possible — and ifcmerge proves it works in practice." The GUID approach would have been a dead end; the ID preservation approach is already running.

  What's still missing is the semantic diff layer on top — something that translates SPF-level changes into human-readable descriptions of what actually changed in the model. That's where GlobalIds become useful: not as merge identity anchors, but as a lookup layer for surfacing "wall A3-101 height changed from 3000mm to 3500mm" rather than "#3518 attribute 4 changed." The merge logic stays ID-based; the reporting layer uses GUIDs where they exist and falls back to type/position context where they don't.

  Would be interested in your view on how far the Native IFC protocol has actually penetrated authoring workflows in practice — that seems like the real constraint on how widely this can be deployed.

  
• brunopostle

  March 26

  It sort-of proves that you can get the bot to say anything you like.

  Though it had an original idea that has legs that I hadn't considered: "something that translates SPF-level changes into human-readable descriptions of what actually changed in the model". We can totally do this with git diff, ifcmcp and ifcquery; I bet we can simply ask ifcmcp to describe the changes between any two revisions: "What did Ryan do on Monday, and how is it different to what he said he did?".

  
• theoryshaw

  March 26

  
  

  Asked mr bot to parse out this idea more

  
  The semantic diff layer is worth unpacking in full because it's actually a well-defined engineering problem with a clear implementation path, especially given what IfcOpenShell already provides.

  ---

  What the raw SPF diff looks like

  When ifcmerge processes a change, the output is at the entity level. A height change might look like:

  -#3518=IFCEXTRUDEDAREASOLID(#3515,#3516,#3517,3000.);
  +#3518=IFCEXTRUDEDAREASOLID(#3515,#3516,#3517,3500.);
  
  

  Attribute 4 changed from 3000. to 3500.. This is precise and correct, but completely unreadable without schema knowledge and graph traversal. No BIM coordinator can action that.

  ---

  The two-direction traversal problem

  To make that change human-readable you need to go in two directions simultaneously:

  Upward — walk the reference graph from #3518 toward the nearest entity that has a GUID. The chain is roughly:

  #3518 IfcExtrudedAreaSolid
    ↑ referenced by #3512 IfcShapeRepresentation
    ↑ referenced by #3510 IfcProductRepresentation
    ↑ referenced by #3507 IfcWall [has GUID: '2O2Fr$t4X7Zf...', Name: 'A3-101']
  
  

  That gives you the subject: "Wall 'A3-101'"

  Downward — use schema knowledge to name what changed. IfcExtrudedAreaSolid's attribute positions are fixed by the schema: attribute 4 is Depth, typed as IfcPositiveLengthMeasure. That gives you the predicate and values: "extrusion depth changed from 3000mm to 3500mm"

  Combined output: "Wall 'A3-101': extrusion depth changed from 3000mm to 3500mm"

  ---

  Why IfcOpenShell is uniquely positioned to do this

  The two ingredients — upward graph traversal and downward schema introspection — are both things IfcOpenShell already does well. The schema is baked in. Inverse relationships are tracked. The upward walk is just following inverse references until you hit a GUID-bearing entity. No other library has this combination already working and battle-tested.

  ---

  The fallback hierarchy when no GUID exists

  Some entities have no GUID ancestor — global geometry contexts, shared material definitions, profile definitions. The fallback isn't silence; it degrades gracefully:

  1. Named entity — IfcMaterial has a Name attribute. Use it: "Material 'Concrete C30': density changed"
  2. Type + role — IfcGeometricRepresentationContext has a ContextType attribute: "Model geometry context: precision changed"
  3. Type + parent attribute name — if all else fails, describe by type and the attribute name on the parent that references it: "IfcWall 'A3-101': ObjectPlacement geometry changed"

  The goal is that every change has at least a meaningful type-and-parent description, even if the full semantic chain can't be resolved.

  ---

  GUIDs as cross-version anchors, not merge anchors

  This is the distinction worth being precise about. In the merge operation, GUIDs are irrelevant — SPF IDs do the work. But in the diff report, GUIDs serve a different purpose: they let you link the same element across commits even after renumbering.

  If a merge causes local entities to be renumbered (the offset mechanism), #3518 in commit A might be #3621 in commit B. If you're reading a git log of changes to Wall 'A3-101' across 10 commits, you need GUID-based lookup to maintain continuity. The diff layer says "find the wall with this GUID, report what changed about it" — independent of what SPF ID it happens to have in each version.

  ---

  What this looks like end-to-end

  The pipeline is:

  [ifcmerge diff output]       ← SPF ID changes, raw
          ↓
  [GUID/name lookup]           ← walk up graph to find human-readable subject
          ↓
  [schema attribute naming]    ← name the changed attribute by position
          ↓
  [unit conversion]            ← IfcOpenShell already handles project units
          ↓
  [human-readable diff report] ← "Wall 'A3-101': height 3000mm → 3500mm"
  
  

  Each step is independently useful and independently testable. The first step already exists (ifcmerge). The last three are pure IfcOpenShell operations. The middle step — GUID/name lookup — is the novel piece, and it's essentially a constrained graph traversal with a well-defined termination condition (stop at the first GUID-bearing ancestor).

  ---

  The reason this matters beyond readability: once you have a semantic diff, you can do things like audit trails that non-developers can actually read, automated change notifications to relevant stakeholders ("you're the responsible engineer for this wall"), and PR review workflows where a BIM coordinator approves a merge the same way a senior developer approves a code change — by reading a diff that makes sense.
  
• zoomer

  March 26 edited March 26

  @Moult said:
  However, there are clearly areas which are lacking compared to alternatives like Web-IFC and IFC Lite. These newer libraries put a lot of emphasis on speed, re-serialisation into formats that allow scalability, and focus on the web platform which is clearly the favourite of the newer generation.

  OMG is IFC Lite fast.
  I threw a 459 MB IFC into the browser and expected that would make it crash. the opposite. it took about 2 seconds to open the model and everything works real time. I have never seen something like this before .....

  
• brunopostle

  March 26

  @brunopostle said:
  Though it had an original idea that has legs that I hadn't considered: "something that translates SPF-level changes into human-readable descriptions of what actually changed in the model". We can totally do this with git diff, ifcmcp and ifcquery; I bet we can simply ask ifcmcp to describe the changes between any two revisions: "What did Ryan do on Monday, and how is it different to what he said he did?".

  This works, here is ifcmcp asked to give a day by day narrative of the changes in an IFC repository (ifcmcp is a bot that knows how to read and modify IFC models):

  Design Log — My Building

  A day-by-day account of how this IFC building model grew from a structural shell into a fully furnished two-storey community building with service extension and south garden.

  ---

  24 February 2026

  The building model began its life as a complete structural skeleton: four exterior walls forming a compact 4 m × 6 m rectangular plan on the first floor, sitting on four concrete ground beams and footings. Above the walls a pitched timber roof spans the space, with eaves corona and tile coverings wrapping the edges and gutters running along the lower eave. The single internal room was defined as living-space/0, fitted with eight sash windows — tall arched lights on the north and south elevations, and wider sash-big openings on the east and west.

  With the geometry in place, the model was immediately put to work. Element quantities were computed for every wall, slab, footing, and roof panel, and a full construction schedule was written: Foundations → Structure → Roof → Openings → Finishes, with durations running from 2 days for the gutters up to 8 days for the walls. A Bill of Quantities cost schedule was also set up, ready to receive unit rates. The last task of the day was to add FireRating and Thermal Transmitance properties to the wall common property set to satisfy a pending IDS validation requirement.

  
  The original building as it stood at the end of 24 February: a single room with eight windows and a pitched roof.

  ---

  27 February 2026

  Attention turned to the interior. Three elements transformed the bare room into a habitable space: a wood-burning stove was positioned as the hearth and focal point for communal gathering; a chimney was added rising through the roof; and a window seat was built into the south wall, inviting people to sit in the light. Outside the front door a bench was placed for people waiting or removing muddy boots, and an apple tree was planted nearby.

  A library type for a Neufert Retail Dining Chair was also imported into the model at this point, anticipating future furnishing of the space.

  Two housekeeping fixes were made: the work schedule's PredefinedType was corrected from BASELINE to PLANNED (a BASELINE schedule without a parent to compare against causes the Gantt tool to crash), and a thermal transmittance property name that had been spelled ThermalTransmittance was corrected to Thermal Transmitance to match the IDS requirement exactly.

  
  End of 28 February: the entrance porch is in place, the panelled front door is installed and the chimney rises above the ridge.

  ---

  28 February 2026

  The main entrance was given proper architectural definition. One of the north wall windows — a wide sash opening — was removed and replaced with a panelled entrance door. This is modelled accurately: the original window and its opening element were deleted, a new door-height opening (2.08 m, no sill) was cut through the wall, and the door was placed and assigned its panelled door type.

  Almost immediately a lean-to entrance porch was added on the east side of the building: three new walls (south, north and east faces) enclose a small lobby space that shelters the entrance from wind and rain. Two interior doors — a lobby entrance door and an interior lobby door — connect the porch to the main space. The lobby was formally defined as an IfcSpace (entrance-lobby/0), and the construction schedule was extended with tasks for Erect Porch Walls (2 days) and Install Lobby Doors (1 day).

  The schedule also gained tasks for the stove, chimney, window seat, bench and tree added the previous day, each assigned their newly computed quantities.

  ---

  1 March 2026

  The busiest day in the project's history. Seven significant design moves were made, more than doubling the model's element count.

  Lean-to porch roof. The porch walls were trimmed to a sloped lean-to profile — a half-space clipping replaces a simple extrusion so the walls taper correctly from 3.26 m at the building face down to a 2.38 m eave. A shallow pitched porch roof slab was added over the entrance, giving the cascade-and-sheltering quality of Pattern 116/117.

  Fire-exit door. A second door was added to the south wall, providing a safe secondary exit from the main space.

  South outdoor gathering space. A generous outdoor room was defined south of the building: a paved area with three low sitting walls (south, east and west edges) forming an informal enclosure. Four garden chairs were placed within it. This follows Patterns 105, 161, and 163 for outdoor gathering.

  South service extension. A single-storey service wing was added to the south side of the main building — three perimeter walls plus an internal partition dividing the space into three rooms:
  - service-lobby/0 — circulation between the main building and the service rooms
  - wc/0 — fitted with a toilet, basin, and two windows (west and south)
  - kitchenette/0 — fitted with a bench, sink, and two windows (east and south)

  A flat extension roof was placed over the extension and three internal doors connect the rooms. Sanitary and kitchen fixtures were imported from the Bonsai asset library (Neufert Toilet, Neufert Small Basin, Neufert Small Kitchen Bench, Generic Small Sink).

  Landscape. The apple tree was moved from its original position beside the building to a new position further south, clearing the extension footprint. Eight small shrubs were planted around the building perimeter (two on each side).

  Quantities and BoQ. All new elements were quantified and added to the construction schedule (tasks: Erect Extension Walls, Install Sanitary and Kitchenette Fixtures, Build Garden Sitting Walls and Paving) and the Bill of Quantities.

  
  End of 1 March: the building has grown its service extension, the south garden is paved and planted, and the apple tree has moved to its new position.

  ---

  5–6 March 2026

  A dining table was built from scratch using the shape-builder API: four circular-section legs (30 mm radius, 720 mm tall) and a rectangular tabletop (1 400 × 800 mm, 40 mm thick). The table was placed in the living space and assigned a furniture type.

  The first version used an IfcBlock primitive for the tabletop, which caused a schema validation error (CSG and SweptSolid items cannot share the same IfcShapeRepresentation). The next day the tabletop was rebuilt as an extruded rectangular profile, keeping all items as SweptSolid and resolving the validation failure.

  ---

  9 March 2026

  Six Neufert Retail Dining Chairs were placed around the table — two on each long side, one at each short end — completing the dining group. All six chairs were initially placed facing the same direction (the library default). They were then corrected so that each chair faces inward toward the table: the two south chairs rotated 180°, the east chair rotated 180° about Z, and so on, depending on which side of the table they sit on.

  
  End of 9 March: the dining group is complete — table, six inward-facing chairs, stove and window seat — seen through translucent walls.

  ---

  11–12 March 2026

  A series of geometry corrections improved the quality of wall junctions throughout the model.

  Wall mitre connections. The corners where the porch walls and the extension walls meet were upgraded from simple abutting ends to properly mitered connections. Each wall pair was given an Axis/Curve2D representation and connected via IfcRelConnectsPathElements; regenerate_wall_representation was then called to recompute the mitered profiles. For the porch walls (which also carry a slope clipping), the mitre was baked directly into the 2D profile as a trapezoid rather than using two half-space clippings, which would have produced viewer artefacts.

  Porch geometry. The porch wall slope clipping normals were corrected (the normal must point toward the removed material, i.e. upward, which is counter-intuitive), and the west extension wall geometry was fixed to match the new mitered profile.

  Opening alignment. Window and door openings in the service extension were repositioned to align correctly with their host walls.

  Dining table resize. The table dimensions were adjusted.

  Quantities, costs and the construction schedule were recalculated to reflect the updated geometry.

  ---

  19 March 2026

  The building gained a second storey. Until now all four exterior walls had been on storey 1 (the first and only occupied floor). The model was restructured so that:

  • The original four walls and their windows were renumbered to a new storey 2 (the upper floor), keeping all their geometry intact.
  • Four new ground-floor walls (ground-south, ground-north, ground-west, ground-east) were created on a new storey 1, with the same rectangular footprint.
  • A first-floor concrete slab (first-floor-slab) was added at the 3 m level to separate the two floors.
  • Five windows were punched through the ground-floor walls: two on the south elevation, two on the west, and one on the north.
  • A ground-floor entrance door was added on the east wall, aligned with the porch lobby.

  The construction schedule was extended with a Ground Floor phase covering Ground Floor Walls (15 days), Ground Floor Slab (5 days) and Ground Floor Windows and Door (5 days).

  
  End of 19 March: the building is now two storeys. The new ground-floor walls and first-floor slab are visible below the original upper-storey windows and roof.

  ---

  20 March 2026

  The ground floor window set was completed. Additional openings were added to bring all elevations to their final fenestration:

  Elevation	New openings added
  North	Second window (win-north-2)
  West	Third window (win-west-3)
  East	Two windows (win-east-1, win-east-2)
  South (service wing)	Service opening

  This brings the ground floor to nine windows plus the entrance door.

  The construction schedule underwent a significant correction. All element-to-task assignments were changed from IfcRelAssignsToProcess (which marks an element as an input to a task — material being consumed or demolished) to IfcRelAssignsToProduct (which marks an element as an output — the thing being constructed). Using the wrong relationship type caused the Bonsai construction animator to crash with a KeyError when trying to animate CONSTRUCTION-type tasks. The sequence ordering was also corrected so that ground-floor walls are built before first-floor walls, which had been reversed.

  ---

  Final state

  The model as it stands describes a two-storey community building: a generous double-height living room on the ground floor opens through a porch lobby to the east; the first floor above holds the main social space with its eight sash windows, dining table and six chairs, window seat and wood-burning stove; a single-storey service extension to the south provides WC and kitchenette facilities; and a paved south garden with sitting walls, garden chairs and shrubs completes the outdoor setting. A large apple tree stands to the south-west.

  
  The completed model as of 20 March: two storeys, lean-to porch, service extension, south garden and full window complement.

  and 4 others.
• brunopostle

  March 27

  To be clear: not just this summary but all the changes in this model were by an ifcmcp bot responding to issues in a bug tracker.

  
• bsmith

  March 31

  This all sounds great to be honest!
• isain

  April 17

  Yes first class library for web ifc authoring is maybe most needed feature in IFC world so can be easily generating ifc views in web browser but also generating ifc or editing simple futures
• Moult

  May 4 edited May 9

  OK, a month and a bit later, we now have significant progress on quite a few of these initiatives. Unfortunately, none of this is yet available via the build system so the only way to try it out is to compile the code yourself. However, I truly hope in the next few weeks we will have a build up of at least one of these. Let's go!

  A more optimised IfcOpenShell for the web

  There are 2 updates here. Firstly, Sayan's GSoC project which will start soon and make this a reality. Second, starting around this commit (with full details in PR) @aothms has been decoupling the C++ side of things so that instead of IfcOpenShell being one monolithic software, it now treats serialisers, geometry kernels, and schemas as plugins (shared libraries - a.k.a. dlls). So basically "IFC4" is a plugin, "OpenCascade" is a plugin, "GLTF" is a plugin, and so on. This breakdown is a huge deal in code portability and reuse.

  A lighter geometry library for even more speed

  A huge amount of profiling was done comparing IfcOpenShell to web-ifc and IfcLite. We measured where we were fast and slow, and this lead to the introduction of the Manifold geometry kernel. Note that IfcOpenShell is unique in that it supports hybrid kernels, each kernel has pros and cons, so in IfcOpenShell you can mix and match. Manifold is fast, but it is not technically correct (i.e. in implementation of IFC's precision attribute), but this is a tradeoff you can make for simple shapes, for example.

  This, along with other improvements means that IfcOpenShell is much faster now.

  The big win in improvements in geometry (with multicore). On the IfcLite profiling test case model set, IfcOpenShell is faster for geometry on ~half the models (13/26), web-ifc on 9, with 4 roughly tied. Basically, if you want speed for geometry, IfcOpenShell is now much better than before (edit: removed previous incorrect claim). However, web-ifc has a 3-7x parsing advantage (i.e. to "open" the file) means it still wins in terms of total time (from open, to geometry, to close) on 22/26 models. Parsing, not geometry, is now IfcOpenShell's main bottleneck when multiprocessing is available. More work still to be done. In particular this addresses the "Instant IFC SPF loading for non-geometric queries" concern. Also note XBim was not assessed. Edit: also note the ifclite tests were not comprehensive (e.g. Ifclite actually does support multithreading)

  This also kicks off a body of work around geometric correctness. Just because you are fast, does not mean you are correct. Initial experiments have started (for internal correctness between kernels) so watch this space. See full profiling analysis here.

  

  Well supported hybrid serialisations where SPF falls short

  After discussion, it is likely the HDF5 support will be dropped. RDB will likely take a prominent position as a replacement for IFC-SPF in many workflows (at work, I hope to roll it out sooner than later once some bugs are fixed). There has also been work on a highly compressed geometry-only cache currently just nominally called "IFCVIEW". I have written a page of docs explaining what all these things are but have not yet committed. Next time.

  This chart shows filesize comparisons tested across real life projects. IFC is the .ifc SPF format.

  • IFC: the .ifc format you know. Plaintext.
  • RDB: IFC in a database form. Lossless. Better in almost every way? Instant opens. Negligible memory. Drop-in replacement for .ifc. ~50% the filesize.
  • RDBDATA: IFC in database form with classes filtered out (and therefore intentionally lossy). Useful if you need just non-geometric data or specific data. Good for data analytics. ~10% of the filesize.
  • IFCVIEW is geometry only (for viewing usecases) ~40% of the filesize.
  • IFCVIEW+RDBDATA: combine the two together, for read-only usecases (such as coordination, filtering, visual legends, issue management, auditing, clash detection, etc). ~50% of the filesize.

  Note that these are generalisations. There are always tradeoffs with any technology, and you can see some examples here where plain old .ifc text is even smaller than "optimised binary blah blah".

  

  A desktop viewer

  This is the big one for users. Work is done here. In short, there is no free software equivalent of Revizto, BIMCollab, Solibri, etc. We are building one, and whilst doing so, enabling others to also build their own desktop (tablet? kiosk? on-site screens?) apps. Here's the current state of the UI:

  

  

  

  

  It's designed to be simple to use (i.e. most complex stuff hidden away, no 1000 buttons like Blender) and super speedy. Speedy as in, in my current tests, I have loaded 111 real-life large project models (from work) in under 10 seconds, which have over 1,000,000 objects, where I can navigate and fly around like superman with 60FPS using only 4GB of RAM. Note this is precomputed caches, similar strategy to XKT / Fragments. The intent is that you can cloud-generate these caches and then cloud sync (4GB RAM ~= 4GB full network download for 111 models) so that teams can quickly load up models.

  This geometry cache (currently named "IFCVIEW" as a placeholder) can be coupled with IFC RDB. This means instant IFC open times with negligible memory usage. The RDB can be lossless, or lossy (for read-only). For lossy, we can choose what classes to omit, so if we exclude geometry (so RDB for data, IFCVIEW for geom) we get in my example ultra-high-load scenario 5GBs (4GB geom + 1GB data) for 111 models. The original SPF was about 10GB (note these are quite curated IFCs, not full of arbitrary bloat, some of which are incredibly dense steel where even plaintext geometry is smaller than binary triangles).

  Georeferencing support has recently been implemented in it, which I think is one of the big things which set us apart from other viewers - that we have correct coordinate handling. That in itself took half my weekly Claude tokens to do ;)

  and 18 others.
• condur

  May 5

  Awesome work @Moult , I can't wait to get my hands on this thing and use it as my main IFC non-authoring tool!

  
• isain

  May 5 edited May 5

  @Moult Is maybe planned rules set manager for checking models by the rules with combined with IDS , and online respiratory for sharing rules sets like

  https://help.solibri.com/hc/en-us/articles/1500004624081-Using-the-Ruleset-Manager

  Also maybe MCP like interface if is possible for modern ifc checking

  And is possible to add git version and issues control so this can be viewer and bonsaiBIM or free cad as authoring platforms but work simultaneously on one project , multi viewers multiple bonsaiBIM and version control

  
• KoAra

  May 5

  RDB: IFC in a database form. Lossless. Better in almost every way? Instant opens. Negligible memory. Drop-in replacement for .ifc. ~50% the filesize.
  RDBDATA: IFC in database form with classes filtered out (and therefore intentionally lossy). Useful if you need just non-geometric data or specific data. Good for data analytics. ~10% of the filesize.

  I had interpreted IFC as an entity-relationship data model, so I assumed it used RocksDB’s key-value NoSQL database, but are you saying it turned out to be an RDB? Amazing
• theoryshaw

  May 8 edited May 8

  Does the viewer render out Bonsai drawings? That would be cool.

  
• FeeBarradas

  May 8

  I can't wait to see what comes next, it looks amazing already!

  A suggestion for the user interface: it would be great to have a “command finder” so we don't have to rely so much on “finding the right button,” even though the panels look nice and clean in the preview.

  The best examples I know of this kind of tool are the bimdots tool for Archicad and the AutoCAD's command line (yes, I know... but it still works great to this day).

  I have a feeling that button-based UI will soon become outdated, as we’re all moving towards natural language input. It’s worth thinking about it, so please consider if possible.

  
• zoomer

  May 8

  I have a feeling that button-based UI will soon become outdated

  Not for me.
  I am a notorious button clicker. Muscle memory.
• steverugi

  May 9

  @zoomer

  I have a feeling that button-based UI will soon become outdated

  Not for me.
  I am a notorious button clicker. Muscle memory.

  I'm all for keystrokes, direct like in Blender or QCAD, no command line stuff
  Never used the gizmo :)

  
• louistrue

  May 9 edited May 9

  Hello, thought I'd chime in 😉
  First: really appreciate this race. Wonderful that we can run it on open, free libraries. That's exactly why I started IFClite a few months ago. Not one library to rule them all, but a diverse, openly accessible landscape covering the full range of IFC use cases. OK, stage set 😅

  @Moult said:
  Basically, if you want speed for geometry, IfcOpenShell is now the best choice.

  I kindly disagree, but I think the disagreement is mostly about which IFClite path is being tested.
  I forked the profiling harness, kept the framework intact (Parse / Geometry / Total, same exclude set, same 21 public files) and added the missing series: IFClite's native Rust deployment alongside the WASM one. Same chart layout, more bars, plus a geometric-output panel and a proposed zero-copy category at the bottom.
  
  from Apple M4 / 10c / 16 GB / Node 22:

  • IFClite native, 10 threads wins 21/21 on Total vs IOS-max, web-ifc, and IFClite WASM
  • IFClite native, 1 core wins 21/21 vs IOS-max-threads (so it's not just about threading) and 19/21 vs web-ifc

  Fork with code, chart, RESULTS.md, raw JSONs, and per-file product/triangle validation:
  github.com/louistrue/profiling/tree/apples-to-apples-with-native

  A few places where the original chart underweights IFClite, from where I sit:
  1. The native Rust server ships at @ifc-lite/server-bin with rayon multi-threading and is the production deployment. Adding it flips most per-file rankings.
  2. The Total column sums two independent IFClite parsers. TS-side parseLite (non-geom queries) and WASM-side parseMeshes (geometry) are alternative entry points, not pipeline stages: parseMeshes does its own internal parse from scratch. My fork reports them as separate races and uses a single-call native pipeline for the native rows.
  3. Zero-copy as a proposed fourth category. parseZeroCopy returns a single concatenated, GPU-upload-ready buffer with WASM-memory views. Different output shape than iterator(), so not strictly apples-to-apples, but it's what real viewers consume. Panel 4 measures it against a web-ifc reference (what a viewer would otherwise assemble manually: OpenModel + StreamAllMeshes + GetGeometry/Vertex/Index + JS concat). IFClite wins 21/21, median 2.4×.
  One more thing: real-world models are reaching 1GB+ now, and that's where IFClite's columnar / lazy / zero-copy architecture was designed to shine, both for raw speed and memory footprint. I'd expect the gaps to widen once larger models are added to the corpus.

  To be clear: this isn't a "IFClite beat IOS" post. IfcOpenShell remains the correctness reference, the schema authority, and frankly the only engine handling the full depth of IFC-the-spec properly. The numbers should read as: for the narrow-but-common workload of parse + per-element mesh, native Rust IFClite runs faster than what's been measured so far. More options for the ecosystem, and the correctness conversation keeps going ✌️

  Happy to be challenged on any of this. Fork is open, harness is reproducible, every finding documented in RESULTS.md.
  Let's keep rocking 🚀
  Louis

  *edited chart at 10:29 CEST, wrong IOS numbers (from my machine, not Dions...)
• louistrue

  May 9

  Hello, thought I'd chime in 😉
  First: really appreciate this race. Wonderful that we can run it on open, free libraries. That's exactly why I started IFClite a few months ago. Not one library to rule them all, but a diverse, openly accessible landscape covering the full range of IFC use cases. OK, stage set 😅

  @Moult said:
  Basically, if you want speed for geometry, IfcOpenShell is now the best choice.

  I kindly disagree, but I think the disagreement is mostly about which IFClite path is being tested.
  I forked the profiling harness, kept the framework intact (Parse / Geometry / Total, same exclude set, same 21 public files) and added the missing series: IFClite's native Rust deployment alongside the WASM one. Same chart layout, more bars, plus a geometric-output panel and a proposed zero-copy category at the bottom:
  
  from Apple M4 / 10c / 16 GB / Node 22:

  • IFClite native, 10 threads wins 21/21 on Total vs IOS-max, web-ifc, and IFClite WASM
  • IFClite native, 1 core wins 21/21 vs IOS-max-threads (so it's not just about threading) and 19/21 vs web-ifc
    Fork with code, chart, RESULTS.md, raw JSONs, and per-file product/triangle validation:
    github.com/louistrue/profiling/tree/apples-to-apples-with-native

  A few places where the original chart underweights IFClite, from where I sit:
  1. The native Rust server ships at @ifc-lite/server-bin with rayon multi-threading and is the production deployment. Adding it flips most per-file rankings.
  2. The Total column sums two independent IFClite parsers. TS-side parseLite (non-geom queries) and WASM-side parseMeshes (geometry) are alternative entry points, not pipeline stages: parseMeshes does its own internal parse from scratch. My fork reports them as separate races and uses a single-call native pipeline for the native rows.
  3. Zero-copy as a proposed fourth category. parseZeroCopy returns a single concatenated, GPU-upload-ready buffer with WASM-memory views. Different output shape than iterator(), so not strictly apples-to-apples, but it's what real viewers consume. Panel 4 measures it against a web-ifc reference (what a viewer would otherwise assemble manually: OpenModel + StreamAllMeshes + GetGeometry/Vertex/Index + JS concat). IFClite wins 21/21, median 2.4×.

  One more thing: real-world models are reaching 1GB+ now, and that's where IFClite's columnar / lazy / zero-copy architecture was designed to shine, both for raw speed and memory footprint. I'd expect the gaps to widen once larger models are added to the corpus.
  To be clear: this isn't a "IFClite beat IOS" post. IfcOpenShell remains the correctness reference, the schema authority, and frankly the only engine handling the full depth of IFC-the-spec properly. The numbers should read as: for the narrow-but-common workload of parse + per-element mesh, native Rust IFClite runs faster than what's been measured so far. More options for the ecosystem, and the correctness conversation keeps going ✌️

  Happy to be challenged on any of this. Fork is open, harness is reproducible, every finding documented in RESULTS.md.
  Let's keep rocking 🚀
  Louis

  
• Moult

  May 9

  Thanks @louistrue ! I had no idea when I was running the tests that IfcLite had these different settings and multi-threading. Also perhaps worth mentioning that the tests I ran for IOS were not using hybrid-cgal-simple-opencascade, but instead the new hybrid manifold kernel along with the new changes in the datamodel branch.

  For those following along, @louistrue and I had a chat recently to discuss these results and if we could share a benchmark suite, so we could measure correctness and speed across many kernels, technologies / settings, and environments. I'm really looking forward to collaborating more on this suite. https://github.com/IfcOpenShell/benchmark is the (currently blank) repo for anyone who wants to peek in when the first commit lands. The idea is that we can start by assuming IOS's opencascade is the slow but likely correct result, then compare against that (and if it turns out opencascade isn't correct, we can choose a new correct result).

  Watch this space :) Hopefully more news in the next update.

  
• KoAra

  May 11

  I’m looking forward to IfcOpenShell/benchmark 🤩
  I’m keen to see if it’s faster when compared to OCCT_VERSION=7.8.1 in IOS 0.8.5 and the recently released OCCT_VERSION=8.0.0
• vorax_mentis

  May 11

  I like where this is going!
• zoomer

  May 16 edited May 16

  A lighter geometry library for even more speed. 90% of geometry is either a mesh or an extrusion with possible CSGs. CGAL was a step in the right direction, but further micro kernels can optimise geometry loading even further.

  Will only the Bonsai Viewer profit from this ?
  Or also Bonsai, or would it then be bottlenecked by the connection to its host, Blender ?
• Moult

  May 16

  @zoomer everything will benefit from this - the Bonsai Viewer, Bonsai in Blender (but only in some scenarios, since in most scenarios Blender is the bottleneck), the upcoming IfcOpenShell for the web, all IfcOpenShell based scripts that work with geometry (at work, I have a lot and I know a lot of other companies too) as well as all utilities (e.g. IfcClash, IfcConvert, ...).

  
• zoomer

  May 16 edited May 16

  Thanks @Moult
  that sounds fantastic.

  Bonsai in Blender- only in some scenarios, since in most scenarios Blender is the bottleneck

  Honestly, so far, I never felt that Blender itself is bottlenecked in any way (?)
  (Viewport, switching Visibilities, Outliner, loading/importing files, accessing/changing Properties, Selections, Snapping)
  Even when loading my largest most ugly geometry examples and compare to my other Apps.

  Are there special known issues where it is worth to avoid or keep an eye on ?
  I remember that manual spatial sorting IFC in Outliner was given up for such (?) reasons but I never experienced any so far.
• zoomer

  May 16

  @zoomer said:
  Honestly, so far, I never felt that Blender itself is bottlenecked in any way (?)
  (Viewport, switching Visibilities, Outliner, loading/importing files, accessing/changing Properties, Selections, Snapping)

  OK, I read about the bottleneck in one of the Links in https://community.osarch.org/discussion/comment/28921#Comment_28921

  @aothms has been decoupling the C++ side of things so that instead of IfcOpenShell being one monolithic software, it now treats serialisers, geometry kernels, and schemas as plugins (shared libraries - a.k.a. dlls). So basically "IFC4" is a plugin, "OpenCascade" is a plugin, "GLTF" is a plugin, and so on.

  To me that sounds very reasonable and very exciting !

  When reading through things that are far ahead of me and I don't understand (https://github.com/elalish/manifold), I have to think my concerns about geometry/accuracy degradation to dumb Meshes (also valid for Yorik's LinesCAD project thread) isn't real (?)
  So no loss like Pixel vs Vector, Mesh vs mathematical Solids (?)

  So .....
  if Bonsai Viewer has its own autark geometric and graphics engine, its own modeling tools, .....
  there is no more much dependent/needed from Blender host left (?)

  May Bonsai authoring one day develop to a standalone App ?

  
• Moult

  May 29

  Just a small update because a lot is happening but it takes time to type it all up. Please check out https://builds.ifcopenshell.org/ for builds called BonsaiViewer that you can test with! Current status:

  • The UI which you saw as a mockup previously is now implemented!
  • It is now hooked into the build system so we can deliver both Linux and Windows builds on the builds website
  • Almost all toolbar functionality is implemented, you can fly, perspective, top, down, measure, area, volume, hide, isolate, open, save, etc
  • You can connect to a cloud source! For now, only Autodesk is bundled as a connector, so if you have an Autodesk connector, you can publish models to cloud, save your federation project to cloud, and open from cloud, sync from cloud etc. It also implements local cache so that subsequent cloud loads are instant if you already have the thing downloaded.
  • Worth mentioning is that the first time you open a file, it does process all the geometry, but the second time, it opens the cache so it will be instant!
  • Georeferencing interface!
  • Renamed to "Bonsai Viewer"
  • Test it out with ultra huge models! Throw in 100 models in there because why not (note: in my dayjob, it is not uncommon to have at least 50 models loaded in, and on large projects easily 100 models).
  • The default kernel is hybrid-cgal-simple-opencascade, but please try out hybrid-manifold-opencascade too and report what you find! It should be to load (first time, subsequent cache load unaffected).

  Coming soon: MacOS, web, actual data being shown (right now the properties / spatial tree is just a dummy mockup), even more speedups, streaming, known stability and geometry correctness, ...

  

  and 4 others.
• sjb007

  May 29

  I notice the Linux builds are from quite a few days ago, with a lot of Windows only builds since then. Are they still up-to-date?