Modelling from the Point Cloud

Every scan-to-BIM job begins the same way: you reference the registered, cleaned point cloud into your BIM authoring software. "Reference" is the right word — the cloud is usually *linked* rather than imported, so it sits underneath your model as a measured backdrop you trace over, the way an architect once traced over a survey drawing, but in three dimensions and to millimetres. The cloud stays read-only evidence; your model is the new, editable thing you build on top of it. Before anything else, the cloud must be correctly positioned and oriented: aligned so the building sits square to the model's axes where that makes sense, set to the right units, and placed at the right level and coordinates. If the cloud was georeferenced by the surveyor, you respect that coordinate system rather than inventing your own; getting this wrong early poisons everything downstream.

With the cloud in place, you build the scaffold: the levels and grids that organise the whole model. You read the floor levels straight off the cloud — slice a vertical section and the floors and ceilings appear as dense horizontal bands — and set a level at each, noting that in a real building the "same" floor may not be at exactly one height across its span (itself a finding worth recording). You establish a structural grid if the building has one, reading column centres from horizontal slices. This scaffold matters more than beginners expect: levels host the floors, walls and ceilings; grids locate the structure; and a clean scaffold makes the rest of the modelling orderly instead of chaotic.

Two habits pay off immediately. First, slice relentlessly: a 3D cloud is hard to model in directly, but horizontal and vertical *section cuts* turn it into readable plans and elevations you can snap to — most scan-to-BIM modelling happens in section views, not in the 3D fog. Second, keep the cloud visible as you work, ideally ghosted behind the model, so you are always fitting objects to evidence rather than drifting into invention. The moment you stop looking at the cloud and start "tidying up" from memory or assumption, you have quietly left scan-to-BIM and gone back to guessing — which is precisely the failure the whole exercise exists to prevent.

With the scaffold set, you build the model up in a deliberate order, because elements depend on one another. A sound sequence is structure first, then enclosure, then openings, then services and detail. Start with the primary structure you can read — columns, structural walls, floor slabs, beams where visible — fitting each to the cloud: snap a column to the ring of points its faces make in a horizontal slice; set a floor to the band of points in a vertical section. Structure located first gives everything else something true to align to.

Next the enclosure and internal walls. In a section cut, a wall reads as two roughly parallel bands of points (its two faces). You place a wall object so its faces sit on those bands, choosing a wall *type* whose thickness matches the measured gap — already a small act of interpretation, since the real gap varies along the wall. Then openings: doors and windows, read as gaps in the wall bands and the lintel and sill lines above and below, placed as door and window objects of the right size and position. Then the floors, ceilings and roofs as surfaces on their level bands. Finally the MEP and detail that the brief calls for — ducts, pipes, cable trays, major fittings — traced to the linear and cylindrical clusters they make in the cloud. Not everything that *can* be modelled *should* be, which is where the next lesson on level of detail comes in; you model to the agreed scope, no more.

Throughout, you are doing two things at once: identifying (what is this cluster of points — a wall? a pipe? a radiator? clutter to ignore?) and fitting (placing an object so it matches the points within tolerance). Identification draws on building knowledge — you recognise a column, a lintel, a downpipe by what it is and where it sits, not just by its dots — which is exactly why the work resists full automation. Fitting is geometric discipline: snapping, aligning, and then *checking* the object against the cloud. Good modellers constantly toggle a deviation check — colouring the cloud by how far it lies from the model surface — to see where the fit is tight and where they have strayed. The loop is always the same: identify, place, fit, check, correct — and move to the next element, thousands of times, until the building stands in the model as it stands in the cloud.

Here is the decision that sits under every element you place, and it is the heart of the craft: how faithfully should the model follow the messy real building? Real walls bow, lean and vary in thickness; real floors sag and slope; real "right angles" are rarely 90 degrees. A BIM wall object, by default, is a perfect prism — flat, plumb, constant thickness. So each time you place one you are choosing between two honest options. You can idealise: model a single clean plane through the average of the wavy points, accepting that the model is a tidy abstraction of a crooked reality. Or you can model faithfully: follow the deviation, building geometry that captures the bow, the lean, the varying thickness.

Neither is simply "right" — the use decides, which is the recurring principle of this module. For a great deal of design work, idealisation is correct and sensible: a clean, plumb, well-behaved model is far easier to design in, to dimension, to coordinate and to build new work against, and forcing the real building's every wobble into the model would make it heavy, slow and harder to use for no benefit. But idealisation has a cost you must never hide: the model now differs from reality, and if someone trusts it blindly they may be misled — the new cabinet sized to the idealised 4.20 m wall will not fit the real 4.13 m one. For heritage documentation, structural assessment, deformation studies, or any case where the *deviation itself is the information*, faithful modelling (or keeping the cloud alongside the model) is essential, because smoothing it away would erase the very thing you were asked to record.

The professional habits that make idealisation safe are straightforward. Decide deliberately, not by accident: choose a level of faithfulness per element type, driven by the use, rather than drifting. Record the deviation: keep the point cloud referenced with the model so anyone can check the idealised object against the real points, and flag where deviations are significant. Never silently correct reality: if a wall is 80 mm out of plumb and that matters, say so — do not quietly model it straight and let the drawing imply it is true. And remember the course-wide boundary: the *measured* deviation — how far the wall really leans, to what tolerance — is survey data, and where that figure must be relied on for a binding purpose (structural, legal), it belongs to the surveyor and the verified instrument, not to your eyeballing of the cloud. Your job is to model honestly to the agreed idealisation and to make the abstraction visible, never to pass off a tidy model as perfect truth.

A few more practicalities turn modelling-from-the-cloud from a slog into disciplined work. Model in the right views. As noted, most of the job happens in section cuts and plan slices rather than the raw 3D cloud, because flat views give you crisp lines to snap to; set up a family of section boxes and work through them methodically, floor by floor, room by room. Agree a fitting tolerance up front. How close must a modelled face sit to the points — within a few millimetres, a centimetre, more? That tolerance flows from the level of accuracy the job requires (lesson 6.3), and pinning it down stops endless, pointless fiddling on one hand and sloppy drift on the other. A deviation analysis — the model coloured by distance from the cloud — is the honest scorecard.

Handle the gaps deliberately. Every real scan has occlusion: the back of that cupboard nobody moved, the space above the false ceiling, the pipe run hidden behind a duct, the bit of wall a scanner never saw. Where the cloud has no points, you cannot fit — you must either infer (reasonably, from context and building logic) or leave a flagged gap, and you must be clear which you did. Quietly modelling over a void as if you had data is exactly the kind of invention scan-to-BIM is meant to abolish; a good as-is model marks its assumptions. Likewise, decide what to do with the clutter: furniture, people, vehicles and temporary objects are in the cloud but usually not in the model, so you identify and ignore them — though sometimes (a fixed machine, a heritage fitting) they matter and are modelled.

Finally, keep the cloud with the model as a deliverable, not a disposable scaffold. The referenced cloud is the evidence behind every object; handing it over (or keeping it archived with the model) lets anyone later verify the model against reality, re-model to a higher level if the use changes, and see exactly where idealisation and inference were used. This is the difference between a model that merely *looks* authoritative and one that can *prove* its relationship to the real building. And it keeps the professional boundaries clean: the model is your authored interpretation to an agreed accuracy and detail; the cloud is the measured record; and anything that must be certified as survey-grade accurate, georeferenced, or fit for a binding structural or legal purpose is verified by a licensed surveyor against the governing standards — not asserted by the modeller. Model diligently, fit to the evidence, idealise deliberately, mark your gaps, and keep the cloud — that is modelling from the point cloud done well.