The Reality Capture Workflow

Strip away the brand names and every reality-capture job, from a phone scan of a bathroom to a laser survey of a railway station, runs through the same six stages. Plan: you establish the intended use and the accuracy and completeness it demands, then choose a method, settings and coverage to suit, and sort out access, safety and permissions. Capture: you go to site and record the data - scan positions, photo sets, flight lines, control and targets - working to the plan and checking coverage as you go. Process: back at the desk you turn raw field data into a clean, coherent dataset: you register the separate scans or images into one coordinate frame, then clean out noise, moving objects and stray points. Model or derive: from the processed cloud or mesh you produce the actual deliverable - a BIM model, 2D drawings, an orthophoto, a mesh, sections, or simply a measurable cloud. QA: you check the result against the brief and against independent measurements, confirming it meets the stated accuracy and covers what it had to. Deliver: you hand over the agreed files and a short report of what was done, to what accuracy, with what gaps.

Each stage has a different character. Planning is cheap thinking time that pays back many times over. Capture is the one stage that happens *on site*, under time, weather and access pressure, and it is largely irreversible - what you did not record, you cannot recover without going back. Processing is patient desk work, often the longest stage, and heavily tool-driven. Modelling or deriving is where human judgement and, increasingly, some automation turn measured geometry into the thing the client actually uses. QA is the discipline that separates a professional deliverable from a hopeful one.

The figure shows the arc as a single chain with one crucial extra element: a feedback loop from QA back to capture and processing. When a check fails, you either re-process or - expensively - go back to site and re-capture. That loop is why the whole course keeps insisting you check *on site, before you leave.* A gap caught while the tripod is still up costs minutes; the same gap caught in the office costs a return trip, and caught after handover it costs your credibility. Treat the pipeline as a chain whose every link inherits the strength, and the weaknesses, of the link before it.

The beginner's instinct is to start from the instrument - which scanner, which app, which setting - and then wonder what to do with the data. The professional instinct is the reverse: start from the intended use and let it dictate everything. Ask first what decisions the data has to support, and to what tolerance. A fit-out contractor measuring for fitted wardrobes needs reliable millimetre-to-centimetre geometry of a few rooms. A heritage team documenting a carved facade needs fine resolution and faithful detail, and a defensible record. A site manager verifying that a slab was poured flat needs accuracy tied to real-world levels and a clear pass or fail against tolerance. Each of those is a different job, and each implies a different method, density, coverage and processing route.

Two pieces of vocabulary make this concrete, and both return in Module 6 and Module 9. Level of accuracy (LOA) is how closely the data and the model match the real world - the measured truth. Level of detail or development (LOD) is how much the deliverable contains - how finely things are modelled and how much information each element carries. They are independent: you can have a highly detailed model that is inaccurately placed, or a sparse but dead-accurate one. Starting from the use means deciding, up front, the LOA and LOD the deliverable actually needs - and, just as importantly, what it does *not* need, so you do not burn time and money capturing or modelling to a tolerance no one will ever use.

This backwards reasoning also tells you when the job is not yours to do. If the intended use is legally or structurally binding - a boundary, a setting-out, a deformation survey, a georeferenced survey-grade deliverable - then the required accuracy and the standards that govern it push the work into the domain of a licensed surveyor or geospatial professional. Recognising that at the planning stage, rather than halfway through processing, is itself a professional skill. Define the use, derive the accuracy, choose the method, and know the boundary: that sequence, not the choice of gadget, is what makes a capture workflow sound. Everything downstream is an attempt to hit the target the brief sets - so set the target first, and write it down.

Here is the counter-intuitive heart of the lesson. The stages that *feel* like the work - processing and modelling, the hours at the screen - are mostly spending down a budget of quality that was fixed much earlier. The freedom to shape the outcome is highest at the very start, in planning and on the field day, and it collapses as you move downstream. By the time you are modelling, the data either contains the accuracy and coverage you need or it does not, and no software can conjure what the field never recorded. The leverage curve in the figure is the single most useful mental model in this whole module: influence starts high and falls; the cost to fix a mistake starts low and rises.

Think about what this means at each stage. A planning decision - the right method, enough scan positions, proper control, the correct density - costs nothing but thought, yet sets the ceiling for the entire job. A field decision - one more scan position to kill an occlusion, a target placed for good registration, a quick coverage check - costs a few minutes on site but would cost a whole return trip to remedy later. A processing decision can recover some situations and ruin others, but it cannot add accuracy that was never captured. And a mistake discovered at delivery is the most expensive of all, because by then drawings may be issued, materials ordered, or a contractor waiting. The same error grows roughly an order of magnitude more costly at each stage it survives.

The practical discipline that follows is to push effort and checking upstream. Spend generously on planning, because it is the cheapest quality you will ever buy. Over-capture slightly in the field rather than under-capture, because site time is precious and irreversible, and a spare scan position is cheap insurance against an occlusion you did not foresee. Check coverage and registration while you are still on site. By the time you reach processing and modelling, your job should be to *realise* the quality you already secured, not to rescue a thin capture. Teams that internalise this curve quote more accurately, deliver more reliably, and spend far less time on heroic rescues - because they stopped trying to fix upstream problems downstream, where it is hardest and dearest.

A pipeline is defined as much by its *handoffs* as by its stages, because that is where quality leaks away. Capture hands raw scans or image sets to processing; if the field geometry was weak - poor overlap, too few positions, no control - registration will struggle no matter how good the software. Processing hands a registered, cleaned dataset to modelling; if the cloud still carries noise, drift or gaps, the model inherits them, and a modeller who trusts a flawed cloud will faithfully reproduce its errors. Modelling hands a deliverable to QA; and QA hands a verified, documented result to the client. At each boundary, the honest question is the same: *is this good enough for the next stage to do its job?* The 'garbage in, garbage out' rule is not a cliche here - it is the governing physics of the chain.

QA is the stage that makes the chain trustworthy, and it is not one event at the end but checks threaded throughout. On site you verify coverage and that targets registered. In processing you inspect registration error, look for drift and confirm the cloud is clean and complete. After modelling you compare the model against the cloud and against a handful of independent check measurements, and you confirm the deliverable meets the LOA and LOD the brief specified. The deliverable is not just the files; it is the files *plus* an honest record of what was captured, by what method, to what accuracy, and with what known gaps and occlusions. That report is what lets the next person trust - and correctly use - the data, and it is where you make explicit any limits and anything that should be verified by a licensed surveyor.

Finally, real workflows iterate. QA exists precisely so that failures are caught and fed back: re-process if the data allows, re-capture if it does not. A mature team designs the loop in deliberately - building in a coverage check before leaving site, a registration review before modelling, and a model-versus-cloud deviation check before delivery - so that problems surface at the cheapest possible moment. Understand the pipeline as one connected system with feedback, start it from the intended use, and invest where leverage is highest, and you have the backbone on which every tool, every piece of hardware and every field technique in the rest of this module hangs.