The geometry void: why your BIM standards are blind to geometric detail

For years, the AEC industry has been trapped in a high-stakes guessing game. We draft elaborate BIM Execution Plans (although we seem to be changing that term…), populating them with acronyms like LOIN, LOD, IDS, PDT, MVD, and IDM. This is all under the assumption that we are creating a rigorous contract for our digital models. We demand a geometry “level of detail 300'“ or a “Level Of Information Need: geometry level x,” expecting that these labels will act as a contractual tether that forces architects, engineers, and manufacturers to deliver 3D assets of a specific, predictable geometric complexity.

In practice, however, the disconnect between human intent and machine execution is stark. We routinely receive BIM deliverables burdened by hyper-detailed, high-polygon assets, such as an office chair rendered with internal springs and structural hardware, that provide zero value to the project workflow. This “geometric noise” adds nothing to the data requirements but creates an exponential drag on model performance, often bloating file sizes to the point of system collapse.

Our industry continues its pursuit of standardised definitions for geometric complexity requirements. There is a fundamental, uncomfortable truth the industry is reluctant to admit: none of these standards provide a native, machine-interpretable definition for geometric detail requirements.

A computer lacks the native intelligence to interpret a subjective “Level of Detail” label; it cannot look at an input mesh and decide whether the geometry complies with an abstract requirement. Phrases like “detailed enough for construction” or “visually resembles design intent” are essentially non-computable. Even when encoded as standardised metadata, these labels remain human-centric benchmarks that a machine cannot verify. Even. worse: these definitions fail to establish any upper bounds for geometric complexity, allowing modellers to unknowingly (or unnecessarily) pack an object with so much data that it effectively defeats the purpose of the intended detail level.

We have spent years attempting to force-fit geometric requirements into standards designed for entirely different use cases. You might, for instance, mandate that a room-filling piece of mechanical equipment be delivered only as a “Bounding Box” or an extrusion (mvdXML, etc) to maintain model performance. Some go into a lot of detail like requiring the ⁠presence of openings, ⁠⁠clearance and operating zones, is the object location ⁠⁠absolute/relative, is there ⁠⁠parametric behaviour, etc. (mvdXML, LOIN, etc). In essence these are requirements of an object and do not clearly define a machine interpretable definition of geometric complexity.

Alternatively, you might limit the allowed file size or the maximum dimensions of an object to discourage over-modelling (like a maximum height as a quantity or property). There are even examples of maximum file sizes to forcefully reduce overly complex geometries.

While these constraints are practical, they are not the same as defining Geometric Complexity. A bounding box is a simplification, a deliberate loss of information, not a definition of the geometric detail required for a specific task. When we use these workarounds, we aren’t enforcing a standard for “Level of Detail/Geometry 300”; we are simply putting the model on a diet. The true intention of an geometry detail definition is to dictate the representation of an object based on its functional role, not merely to cap its physical footprint. Defining that an object or model must not exceed ‘geometry level x’ does not work either (PDT, LOIN, etc) since there is no clear machine checkable definition of what that actually means. By relying on these proxy rules, we are confusing performance optimisation with contractual geometric clarity.

If we cannot rely on the current suite of (open)BIM standards to define, check, or enforce geometric detail, where do we go? The answer lies in shifting our focus from compliance (checking if a box is ticked) to analysis (measuring the mathematical reality of the model).

Forward-thinking VDC teams are moving toward Geometric Complexity Auditing. This involves writing custom code to ingest your IFC files and generate a “heat map” of the model. By calculating metrics like local polygon density, vertex-to-volume ratios, and mesh surface curvature, you can visualize “complexity hotspots” across the building.

Tools like MyBimApi and CtrlPath are pioneering this space, allowing developers and advanced users to query the geometric complexity of an IFC file directly. With this approach, you stop asking the architect, “Did you model this at LOD 300?” and instead ask the data, “Where in this model are the geometric clusters that are threatening performance?” This is no longer a conversation about contractual definitions; it is a rigorous, data-driven approach to model health.

The persistent desire to solve this with human-readable labels, like “LOD 300” in a PDF or a text-based BEP/IDM, is a profound business risk. When you define geometric expectations in “pseudo-standards” that are only interpretable by humans, you create an environment of ambiguity. Remember that some of the ‘machine readable’ standards are not always ‘machine interpretable’.

Because the computer cannot interpret the labels in many of the standards, the “compliance” of your model becomes entirely subjective. Does a manufacturer’s chair with 15,000 polygons satisfy your “LOD 300” requirement, or does it violate it? In a contract based on human-readable labels, that is a legal dispute waiting to happen. You have no automated way to prove the model is non-compliant until your coordination software crashes during a real-time meeting.

Advanced users of BIM and IFC use custom scripts to limit the geometric complexity of meshes before continuing on a workflow. In this case the information and semantics of an IFC dataset does not change, but the geometric complexity is reduced. A human eye won’t notice, but the CPU and GPU of your computer will. So does the ‘loading….’ screen when opening a file.

It is time to be honest about the state of our industry: none of the existing standards (LOIN, LOD, IDS, PDT, MVD, or IDM) provides a mechanism to define a machine-interpretable geometric detail level. These standards were built to solve the problems of the last decade: data silos, inconsistent property sets, and broken exchange workflows. They are excellent at what they do, but they are not, and were never intended to be, tools for geometric detail enforcement by a machine.

For as long as we pretend that an “LOD” label can be validated by a machine, we are leaving our projects exposed to performance failures, litigation, and coordination bottlenecks.

The future of BIM is not in expanding the definitions of current standards; it is in building the data-driven tools that can measure the actual geometric footprint of our assets. If you want geometric control, stop writing it into your contracts and start writing it into your code.