Point Cloud to Revit: How the Conversion Actually Works

A point cloud is a measurement. A Revit model is something a design or construction team can work in. The conversion between the two is where Scan to BIM projects are won or lost, and it is mostly invisible to the client: you send a file, a model comes back. This is what actually happens in between, step by step, on our projects.

Before modelling starts: the data audit

Every project opens with an audit of what arrived. We check the registration quality of the cloud, look for noise, gaps and occlusions, confirm the scope, and agree the level of development and the tolerance the model has to hold. Anything the cloud cannot answer goes back to you as a structured missing-data request, once, up front. Then the cloud is optimised and a coordination system is set up so every discipline models in the same spatial reference.

The clouds arrive from Faro, Leica RTC360 and BLK360, NavVis VLX, Matterport and Trimble hardware, and are processed in Autodesk ReCap, Leica Cyclone and CloudCompare before Revit ever opens.

Modelling by discipline

Architecture, structure, MEP and landscape are modelled as native Revit geometry, each discipline against the same cloud. Regular geometry is built with parametric families. Irregular geometry gets a judgment call: on heritage work, forcing a curved vault into a parametric family costs hours and still drifts from the scan, so unique elements are modelled in place, carrying full data, sitting in the right category. Knowing when to stop automating is part of the craft.

The deviation check

When modelling is done, the finished geometry is compared back against the source point cloud. Every element has to sit within the agreed tolerance, and the check produces a deviation report rather than a shrug. This is the step that separates a model you can trust from a model that merely looks right on screen.

Delivery, and what you can ask for

The model ships in RVT, IFC or DWG. From the same model we can prepare dimensioned plans, facades and sections, shop drawings, and quantity take-offs pulled straight from the geometry. Support continues after handover: revisions, follow-up questions, and export preparation for whatever platform your team runs.

How long does it take?

The honest unit is hours, not weeks: calendar time depends on how many modellers work the building in parallel, while the effort itself is stable. We published our real effort ranges from 35 completed projects in the Scan to BIM cost guide: a small building at LOD 200 starts around 75 modelling hours for the full discipline set, and a very large one at LOD 400 can run past 5,000. What we can add to the tables: every project we have delivered to date has landed within the agreed deadline.

When the cloud is the problem

Some clouds cannot support the scope being asked of them: too much occlusion, missing storeys, noise where the detail matters. When that happens we say so before quoting. We flag the problem zones, and recalculate the scope around the data that exists, instead of quoting the full job and improvising later. A conversation before the project beats a surprise inside it.

If you have a cloud waiting: send it via WeTransfer, Google Drive or any file service through the contact page, with a line on what the model is for. You get a fixed price and a delivery date within 24 hours on working days. The full service, tolerances and LOD definitions live on the Scan to BIM service page.