Who’s Afraid of hBIM?

There’s something uncanny about building a model of a building that predates the idea of modelling itself. A Romanesque church, a Baroque theatre, a medieval stronghold—they were never drawn in plan, never imagined in 3D software. And yet, here we are, holding laser scanners, waving drones through ancient courtyards, chanting acronyms like LOA as if they were their non-capitalised version. It feels like summoning a ghost. Or worse: taming one.

Oh, great, the poltergeist in the mannequin has gone rampant again.

This is where the fear begins.

Not fear in the gothic sense (although working under a groaning 15th-century timber roof will certainly give you that), but fear as resistance, friction, and complexity. Fear as the creeping suspicion that the model — the promise of digital control, clarity, and coordination — might not be able to hold the richness, the mess, the irregular beauty of heritage. That, in trying to formalise the past, we might end up flattening it. That in translating memory into geometry, we might forget what made it matter in the first place.

In the world of fantasy fiction, the artefact that gives you power also often comes with a price. BIM, in the heritage field, is not so different. It offers dazzling powers: precise inventories, condition tracking, structural simulations, long-term management potential. The dream of an eternal, federated, interoperable model that holds every stone and story. It’s no wonder institutions and funding bodies crave it: it feels like certainty in a field riddled with ambiguity.

But then comes the cost: bloated files, semantic gaps, clashing agendas, broken workflows. The digital model, like a too-perfect copy of a thing, starts to feel… off. Like the skin of a dragon wrapped around a pigeon. Accurate, maybe. Alive? Not quite. Meaningful? Don’t make me laugh.

This isn’t to say information modelling for heritage is a bad idea. Far from it. But its adoption is uneven, hesitant, fragmented. Not because it lacks functionality, but because it asks for a different kind of trust, a trust that heritage professionals are not always ready to give to a system built for concrete slabs and HVAC systems. And can you blame them? Asking a medieval historian to encode the meaning of a tympanum into a “Property Set” is like asking a bard to recite The Silmarillion in spreadsheet form.

Yet here’s the paradox: if we want to preserve, understand, and share these buildings in a world increasingly shaped by data, we cannot ignore the digital and BIM, though not born to fit this purpose, might be the best set of processes and tools we have. But to meet that challenge, we must first name the obstacles. And the fear.

So, who’s afraid of hBIM?

Maybe everyone, a little. And maybe that’s not a bad thing. Because fear, as every storyteller knows, is just the beginning of a better story.

Except these guys. These guys aren’t afraid of hBIM.1. Not Built to Code: when History defies Standards

Heritage buildings are stubborn. They’re not made to comply, and they never asked to be modelled. They lean, sag, deviate. They betray their own blueprints, if such things ever existed, and respect physical maquettes that did not survive. Their geometries are closer to textual math than drawings, their proportions a whisper of hands long dead. This is where the standard tools of BIM authoring — with their precision, repetition, classification — begin to unravel. Because parametrising a column that never wanted to be symmetrical is a whole different endeavour.

Let’s be clear: BIM loves regularity but doesn’t need it. What it needs is method. It thrives on types, categories, modules. In a contemporary building, a window is a type. It has dimensions, materials, behaviors. It belongs to a class, with siblings that all look alike in a certain way. It fits into a wall that was plumbed by a laser and defined in a spreadsheet. But in a 16th-century monastery, every window is a cousin of the next: almost alike, never identical. That niche was widened in 1742. That wall leans because of the earthquake of 1908. That vault never matched the one on the other side, and nobody ever thought it should.

My students know very well the example of Rosslyn Chapel, possibly one of the peak examples of a creativity spanning from providing specifications instead of drawings.

But try to feed that into your favourite BIM authoring tool. It resists. It blinks. It tries to round the angle p to 90, to normalise the arc. Suddenly, you’re no longer modelling the building: you’re correcting it. You’re scrubbing away its accidents, its age, its soul.

Field example? A simple one. Surveying a Romanesque apse, we found that each rib in the vault deviated by a few centimetres from the ideal radial pattern. It wasn’t a mistake, but an adaptation to a skewed base geometry. But try to model it in Revit: the moment the user tried an array, the other ribs became “wrong.” The ones on site, of course, not the ones in the model, because that’s how the mind of the lay operator works. Unless, of course, you abandon the family logic and start modelling each one as a unique object. Which defeats the efficiency of BIM, but preserves the truth of the building. So, which do you serve?

This is where typology fails: the notion that buildings can be abstracted into types and families, predictable patterns and standard rules. It works in textbooks. It collapses in cloisters.

This looks regular. It’s not.

Historical architecture isn’t anti-type because it’s chaotic. It’s anti-type because it’s particular. Because it was built under constraints we no longer recognise: the availability of stone from a quarry five kilometres away; the skill of a mason on that particular day in 1456; the fear of collapse prompting a last-minute change in the angle of a flying buttress. These aren’t quirks: they’re highly valuable data. But they don’t fit neatly into any known standard.

And so, we bend. Or fudge. Or abandon BIM entirely, retreating to mesh models, point clouds and textured scans that preserve appearance but lose structure, material logic, or annotation capability.

This tension — the unmodelable within the model — is not a signal, a sign that our tools, as powerful as they are, were forged in a different age, for different battles. They are made for control, repetition, and prediction. Heritage buildings demand interpretation, forgiveness, and curiosity. And that’s why I think every student should have a field experience in surveying and modelling one of these beauties: to remember that our tools might be suitable in a context, but vary the context and they become obsolete.

We weren’t working in BIM, but we needed the 3d, and the point cloud of these beams still gives me nightmares…

To use a videogame metaphor: if BIM is great for building highly complex LEGO, hBIM is closer to restoring a puzzle where half the pieces are missing, and the picture on the box has been painted over three times by monks, masons, and bureaucrats. There’s no “snap-to-grid.” You must look, listen, and choose. That’s the outlaw way: to model not in spite of the irregularities, but because of them. To let the building teach you how to model it, not the other way around.

So no, these buildings weren’t built to code. But maybe the code can learn to listen.

2. Drawing Ghosts: from Reality Capture to Selective Reconstruction

Let’s admit it: the point cloud is seductive. It hovers in digital space like a ghost: flickering, floating, hyper-real. It shows everything and…. well, nothing. A billion measured points suspended in silence. When you first orbit around a high-resolution photogrammetric model of a vaulted nave or a war-torn façade, it feels like magic, like you’ve captured the truth, like you can finally stop guessing and just model what you see.

Take a look at the ghost cell project, if you don’t believe me.

But here’s the twist: the moment you start building a BIM from that scan, you realise you’re not capturing reality. You’re translating it. Filtering it. Interpreting it. The scan is not a model: it’s a veil, a suggestion, and what lies behind it is not certainty, but choice. Reality Capture is the name we give it in polite software brochures. But for heritage, it’s closer to Reality Imagination. Because what the scanner gives you is just the skin: the material logic is missing, the hierarchy is up to you. It’s up to you to bring into a model the knowledge of why that arch cracks here but not there. The cloud provides no understanding of how many times the plaster was redone. You need to look for the record of what was lost.

This is where Scan-to-BIM becomes Interpret-to-BIM. And interpretation is not neutral.

Let’s say your scan reveals a vaulted ceiling obscured by scaffolding. Occlusion. What do you do? Reconstruct the vault from symmetry? Fill in the blanks using a mirror of the other half? Or do you mark it as “unknown”? Every choice you make has consequences. Every curve you trace on top of the point cloud isn’t just a model but a statement, a subjective reconstruction. Sometimes a guess. This is where the ghosts begin to speak.

And it’s often not happy

Field example? A 19th-century theatre, partially burned in a fire. The scan was complete on the surviving side, vague and noisy on the collapsed zone. We were asked to “model it as it was.” But how? Based on symmetry? Historic photographs? Drawings that contradicted each other? In the end, we offered two models: one based on remaining geometry, one on conjectural reconstruction. The client was confused. “Which one is right?” they asked. Both and neither, darling, both and neither.

The point is that the scanner doesn’t give you history: it gives you shape, and shape alone is not enough.

Here, heritage modelling takes on the tone of a necromancer’s spell. You’re rebuilding the dead from fragments: a stone here, a groove there, the ghost of a door that was filled in, the faint imprint of an altar. Except in this necromancy, you can’t conjure: you need to imagine what once was, based on what is, and that’s not technical work. That’s storytelling. Which is fine, so long as we’re honest about it.

It’s the difference between the actual Natalie and N.A.T.A.L.I.E., if you get my reference.

The danger comes when we confuse precision with truth. A model may have been extracted from a point cloud with a Level of Accuracy to 3mm, and still be wrong in its logic. That arch may be perfectly modelled, and still misunderstood. That wall may be orthogonal in the scan but sloped in history, rebuilt after a quake, subtly rotated by time. Fidelity is not the same as authenticity but, in the digital space, they wear the same clothes.

The Mirror shows you what is, what was, and perhaps what could be… but never tells you which is which. The skill lies in knowing when you’re looking at a reflection, and when you’re looking at a guess wrapped in laser dots.

So yes, scan it. Model it. But remember: you are not drawing facts. You are drawing ghosts. And they deserve respect, or they’ll wreak havoc on your model.

But what does that actually mean?

3. Building what, exactly? The Question of Purpose

Here’s a question we don’t ask nearly enough: what is the model for? The concept of model use becomes even more crucial in the complex territory of modelling heritage and yet, in the rush to digitise, to scan and segment and attribute, this question often gets quietly pushed aside, buried under funding reports, software licenses, and a collective excitement about “innovation.” Let’s do the model and keep it as a record, and then we’ll be able to use it… for what? I’m telling you for what. For nothing. The question of model use haunts every project like a silent NPC in the corner of the map: blinking, untriggered, waiting to be talked to. And when you finally do, it changes everything. The inconvenient truth is that you can’t build the right model if you don’t know what the model is meant to do.

I feel I’ve been screaming that in the desert for decades now.

Is the model meant as a record? Then maybe accuracy and fidelity are your priority, and you model everything, even the cracks. Is it a tool for conservation management? Then perhaps you simplify, prioritise materials and condition states, and align with conservation workflows. Is it a digital twin? Then you’ll need sensors, live data, behaviour modelling: a whole infrastructure that most heritage buildings aren’t even wired for. Or then again, is it a narrative? An educational object, a museum exhibit, an act of digital storytelling?

These aren’t minor forks in the road: they are different planets. And yet, most hBIM projects try to be all things to all people… and end up satisfying none.

This pizza is called “4 seasons”. The only reason for this pizza to exist is for 8-year-old me, who would get bored eating a whole pizza, but I’ve yet to find anyone who actually likes it. Much like there’s no model suitable for all seasons.

This is the heart of the problem: use-case opacity. We build detailed, data-rich models without ever defining who will use them, for what, when and how. It’s like crafting a sword without knowing the hand that will wield it. Elegant, yes. Sharp, maybe. Useful? That depends on whether you’re in a duel or slicing bread.

In a recent project for a historic urban compound, the architects wanted layered phasing to understand spatial evolution. The conservators needed material stratigraphy and degradation patterns. The facility managers demanded simple zoning and maintenance sheets. The engineers were after structure, not stone type. The digital twin team wanted to plug in IoT sensors. And the client wanted a fly-through video. It’s pointless to even try to make one model serve them all. The result would be a Frankenstein’s monster of overmodeled parts, conflicting parameter sets, and a barely functioning interface that no one will want to open twice. That’s what happens when everyone contributes, but no one owns the purpose.

This isn’t just a workflow problem, if you don’t mind me throwing words around: it’s an epistemological one. Each discipline approaches the building with a different set of questions. Whene a conservator sees material and decay, an architect sees form and function. An engineer sees forces and tolerances. A software designer sees data structure and interface. A historian sees meaning. You can’t flatten that into one file and expect it to sing.

What we need is multi-model awareness. Interlinked data. Aggregated, maybe. But not collapsed into one unwieldy everything-bagel of data.

Think of the building like a polyhedral artefact, each side revealing a different attribute. One interface for structure. One for meaning. One for geometry. One for storytelling. Trying to wrap them all into one map means no one can read it. But give each hero their own lens? That’s when the party starts to work together. So, before we draw a single line, we must ask:

Who is this for?
What will they do with it?
What don’t they need?

4. Rebuilding Meaning: a Cultural Model of Modelling

Let’s imagine, for a moment, that a building is not a structure but a story. A story made of stone, wood, plaster, and time, shaped by the rituals it hosted, the hands that built it, the ones that broke it, and the ones that tried to fix it. Some parts are clear: walls, beams, thresholds. Others are hidden: memories, symbols, absences. When we model heritage, we’re not just capturing geometry but we’re capturing this layered narrative, and we aren’t trained to do so. We should be.

Because if all we do is reproduce form, we’re modelling the corpse, not the soul.

That’s the uncomfortable truth. BIM, at its core, is a geometric and parametric tool. It models what things are: walls, windows, slabs. It links them to how they’re built: materials, dimensions, quantities. But heritage often demands something deeper: the why. Why was this space added in 1724? Why is that arch broken but untouched? Why does no one walk under that lintel? These whys matter in new construction too, but in heritage they are not optional. They are what give the building its cultural weight. Strip them away, and you’ve got an empty shell. Worse: a lie made of polygons.

To rebuild meaning, we need a different mindset. A cultural model of modelling that doesn’t stop at “what it is,” but asks “what it means,” “who it mattered to,” and “how it changed.” It’s a philosophical shift, and it starts with semantics.

Ontologies like CIDOC-CRM offer a glimpse of what’s possible. Designed for cultural heritage documentation, CIDOC lets you describe not just “object X was made of material Y,” but “object X was used in ritual Z by person W at time T,” it can track provenance, usage, symbolic meaning, even gaps in knowledge. It’s messy. It’s rich. It’s human.

Often, when you bring that into a BIM environment, it feels like playing Dungeons & Dragons in a spreadsheet. You can do it, and I have, but you can’t deny that it kills the vibe for most of us.

Some brave souls are trying to bridge the gap with dedicated data structures and property sets, extending IFC schemas to accommodate cultural dimensions. “Monumental status,” “associated legend,” “ritual use,” “period of significance.” It’s a start. But it’s hard, because most BIM authoring tools don’t know what to do with meaning. You can write “sacred threshold” into a parameter field, but it won’t show up in a schedule. It won’t trigger a clash detection. It won’t export cleanly. It just sits there, like a forgotten line of lore on an old game cartridge.

Still, we try. Sometimes, the model is not meant to be smart or accurate. Sometimes, it’s meant to be true.

Take the case of a small village chapel we once documented to be used in a videogame environment. Structurally insignificant. Architecturally modest. But socially immense. It had no clear typology. No repeated elements. Just one altar, an oddly shaped apse, and a doorway always kept half-open. Model the shadow line that fell across the floor at dusk, because that’s when the ritual will begin. How do you do that? A reference plane, a timestamp, a coded instruction: “When this line crosses this angle, unleash the creature.” That was the moment the model became a story. And I’ll be damned if that’s not what people call 4d BIM.

So here’s your nudge, if you’re still reading: model the story. Use tags if you must. Use linked documents. Use auxiliary databases. Invent new parameters. Draw from the game masters and the lorekeepers and the scribes. If the tool doesn’t let you write down meaning, build around it. Or break it. Someday, someone will open your model not to renovate the wall, but to understand what the wall meant. And when they do, may they find more than surfaces and steel. May they find the ghost, still whispering in the geometry.