Advanced IFC Splitting Strategies for Large and Complex Projects

Beyond floor-by-floor: split by discipline, zone, element type, or custom property to keep huge models manageable across teams and tools.

Splitting by floor is the obvious first cut. For large or complex projects — airports, hospitals, campuses, infrastructure — floor-level splits are not enough. Here are the advanced splitting strategies that keep huge BIM models manageable, plus when to use each.

Why split at all?

  • Performance. A 4 GB federated model locks up most viewers. Split parts each load in seconds.
  • Scope isolation. A subcontractor only needs their scope; giving them the whole model is a distraction and a security concern.
  • Parallel work. Different teams can work on different parts of the model simultaneously without version-control nightmares.
  • Deliverable packaging. Different stakeholders get different subsets.
  • Validation. Smaller files validate faster against IDS and health-check tools.

Strategy 1: split by storey (the classic).

Output: one IFC file per floor.

  • Use when each floor is a natural review unit — tenant fit-outs, multi-storey office buildings, residential towers.
  • Configure in Split IFC Model → "By storey." Check storey assignments in Manage IFC Storeys first.

Strategy 2: split by building.

Output: one IFC file per IfcBuilding entity.

  • Use when the project contains multiple buildings (campus, hospital site, business park).
  • Configure "By building." The split respects the IfcSite → IfcBuilding → IfcBuildingStorey hierarchy.

Strategy 3: split by element type / discipline.

Output: one IFC file per IFC class group (walls and columns in one file, pipes in another, ducts in another).

  • Use when handing off to specialised subcontractors. The MEP contractor gets only the MEP elements; the structural fabricator gets only the structural elements.
  • Configure "By element type" with pre-defined groupings: ARC (walls, doors, windows, slabs), STR (beams, columns, footings), MEP (pipes, ducts, electrical).

Strategy 4: split by custom property.

Output: one IFC file per unique value of a named property.

  • Use when the authoring tool has tagged elements with a "Zone," "Phase," "Construction Package," or "SubcontractorID" property. Perfect for phased construction, tenant separation, or multi-package tenders.
  • Configure "By property," pick the property name. If elements are not yet tagged with that property, use Add Custom IFC Properties to assign values first.

Strategy 5: split by spatial bounding box.

Output: one IFC file per arbitrary 3D region.

  • Use when disciplines need geographic slices that do not follow floor or building boundaries — for example, airport terminals where a functional zone spans multiple storeys.
  • Configure with a bounding-box definition (min/max X/Y/Z). Elements whose centroid falls inside the box go to that partition.

Combining strategies

For large projects, one split is rarely enough. Pipelines let you chain them:

  1. Split by building first.
  2. Within each building, split by storey.
  3. Within each storey, optionally split by discipline.

You end up with a per-building, per-floor, per-discipline folder structure that any subcontractor can navigate to exactly their scope.

Before splitting: prep the model

  • Fix storey assignments. Run Manage IFC Storeys. Orphan elements (those not assigned to any storey) either get dropped or dumped into a special "unassigned" file. Neither is ideal.
  • Run a health check. Duplicate GUIDs across the output files create validation nightmares downstream.
  • Decide on GUID handling. By default, each split file retains the original GUIDs so elements remain traceable back to the master model. Do not re-assign GUIDs on the splits — that breaks round-tripping.
  • Choose whether to split or copy site/building entities. Most splits retain the IfcSite and IfcBuilding entities in every split file so each partition is self-contained and opens correctly in any viewer.

After splitting

  • Inspect each output. Run IFC Viewer on each split to confirm element counts add up to the original.
  • Re-federate for coordination. When you need to check the whole model again, Merge Files rejoins the parts. Round-tripping works because GUIDs are preserved.
  • Document the split. Write a short README in the delivery folder explaining how files were split and how to rejoin them. Six months later, when nobody remembers, it saves a support call.

When not to split

  • Small models (under a few hundred megabytes). Splitting adds coordination overhead without performance wins.
  • Models that already load fine. Premature splitting is a category of premature optimisation.
  • When viewers support federation natively. The BIMCamel viewer and most modern BIM viewers can hold the federated model in memory — at that point, splitting is only for deliverable packaging, not viewer performance.

A thoughtful split strategy turns an unmanageable model into a workable one. A careless one produces a pile of half-valid files that nobody wants to own. Plan the split, document it, and automate it with a saved pipeline.

Tools mentioned in this guide

Part of BIMCamel's Learn library — browse the free online tools or see every guide.