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. Everything that turns one into the other is invisible from the client side: you send a file, a model comes back. Here is what happens in between on our projects.

Most of the clouds we work from arrive from surveying and scanning firms, not from building owners. We do not scan. For the firms that send us modelling work that matters, because we are never standing next to them bidding for their next site.

Before anyone opens Revit

Every project starts with an audit of what arrived. We check registration quality, look for noise, gaps and occlusions, confirm the scope, and agree the LOD and the tolerance the model has to hold.

Tolerance is a number, not an adjective. We work at 50 mm for general reference, 25 mm for standard renovation work, and 10 mm for heritage and fabrication-level jobs. The tolerance you pick moves the price and the hours more than the building type does, and it is the single decision clients most often leave vague at enquiry stage.

Anything the cloud cannot answer comes back to you as one structured missing-data request, before modelling starts rather than halfway through it. Then the cloud is cleaned and optimised in ReCap, Cyclone or CloudCompare, and a shared coordination system is set up so every discipline models against the same spatial reference.

We take clouds captured on Faro, Leica RTC360 and BLK360, NavVis VLX, Matterport and Trimble. In practice the hardware rarely decides anything. A registered cloud in E57, RCP or RCS is enough, panoramas help, and no project we have taken has stalled because of an input format.

Modelling by discipline

Architecture, structure, MEP and landscape are modelled as native Revit geometry, each discipline against the same cloud, in Revit 2020 to 2026.

Regular geometry goes into parametric families. Irregular geometry needs a decision. On a cathedral we modelled at LOD 400, around 8,000 m², forcing the carving and the vaulting into parametric families would have cost days and still drifted from the scan, so those elements were modelled in place, carrying full data and sitting in the right category. We changed the modelling method three times on that project before it held.

On buildings over 6,000 m² the model is split into zones with a QA pass every three to four days. A wrong assumption caught on day three costs half a day of correction. The same assumption found at handover costs a week of rework running across three disciplines at once.

The deviation check

When modelling is finished, the geometry is compared back against the source cloud. Every element has to sit inside the agreed tolerance, and the check produces a deviation report you can open and read line by line. Anything outside tolerance is either corrected or recorded with the reason it stands, which matters on heritage work where a wall genuinely is 40 mm out of plumb and the model should say so.

Delivery

The model ships in RVT, IFC or DWG, or whatever opens correctly on your side. IFC is the usual bridge for Archicad teams. DWG sometimes needs post-processing in AutoCAD, for instance on German projects where the layer names have to come out right, which is why we run those models in the German Revit interface.

From the same model we prepare dimensioned plans, facades and sections, shop drawings, and quantity take-offs pulled straight from the geometry. After handover you get revisions and export preparation for whatever platform your team runs.

How long it takes

The unit we quote in is hours. Calendar time depends on how many modellers work the building in parallel, while the effort itself is stable and predictable. We published our real ranges from 35 completed projects in the Scan to BIM cost guide: a building under 2,500 m² at LOD 200 runs 75 to 180 hours for the full discipline set, and a building over 15,000 m² at LOD 400 with architecture, structure and MEP runs 2,300 to 5,350. Every project we have delivered so far has landed inside the agreed deadline.

When the cloud will not carry the job

Some clouds cannot support the scope being asked of them. There is too much occlusion, or a storey is missing, or the noise sits exactly where the detail matters. It is not rare. On four of the projects we documented in detail, the cloud came in below what the requested LOD needed, and we said so before quoting.

What happens next is that we mark the problem zones and recalculate the scope around the data that exists. Sometimes the answer is that two rooms need a rescan, and we give that answer as well, even when it delays the order.

Two things follow from this, and both are commitments rather than preferences. You will not see an invoice until you have approved a fixed scope and a fixed price, with no hours added after the fact. And you do not need an NDA to get a quote; if you have your own, we sign it the day you send it.

If you have a cloud waiting, send it through the contact page via WeTransfer, Google Drive or any file service you already use, with a line on what the model is for, and you get a fixed price and a delivery date back within one working day. Tolerances, LOD definitions and the full scope of the service are on the Scan to BIM service page.