I start with three basic questions.

Are the scans correctly aligned?
I check how well neighbouring scan positions fit together and look for registration problems such as duplicated surfaces or ghosting.

Is the point density appropriate?
The dataset needs enough information for the intended purpose, but unnecessary density can make downstream processing more difficult.

Was everything important actually captured?
Occlusion is unavoidable in many environments, but critical missing geometry can become a serious problem if that information is required later.

These checks quickly tell me a great deal about both the quality of the dataset and what may be required during processing.

Before asking how to process the data, understand what is actually in it.

Subscribe now

Yes. To a large extent, the final deliverable determines what kind of point cloud is actually required.

A dataset intended for CAD documentation does not necessarily need the same characteristics as one prepared for detailed mesh generation, BIM, measurements, visualisation or integration into another platform.

Point density is only one consideration.

The required format, dataset size, organisation and downstream software environment also matter. It is important to understand who will use the data next, what information they need to extract and how they will continue working with it.

For this reason, I prefer to think about the final use of the data before deciding what the dataset should look like.

The deliverable should help define the data, not the other way around.

SEE IT IN PRACTICE

For a nationwide tourism office documentation project, processed point clouds formed the basis for CAD floor plans and supplementary Revit visualisations.

Subscribe now

Only to a certain point.

Registration problems and unwanted data can often be corrected or improved during processing. Point clouds can also be cleaned, filtered and optimised for their intended use.

But there is an important limit.

If a critical part of the surveyed environment was not captured in the field, that measurement does not exist in the dataset. Processing cannot recreate reliable spatial information that was never recorded.

This is why field acquisition and processing should not be treated as completely separate stages. Decisions made during capture directly influence what can be achieved later.

Processing can improve captured data. It cannot replace data that was never captured.

SEE IT IN PRACTICE

During mobile scanning of complex cemetery environments, trajectory planning and sufficient overlap were important because vegetation, monuments and narrow spaces created significant occlusion.

Subscribe now

Yes.

A point cloud can look convincing at first glance while still containing technical problems.

One of the first things I check is how well neighbouring scan positions align. Poor registration can create duplicated surfaces or ghosting, meaning that geometry representing the same physical object does not correctly coincide.

Problems can also originate earlier in the workflow. Incorrect field acquisition or positioning issues, including the use of inappropriate RINEX data during PPK processing, can affect the spatial reliability of the resulting dataset.

The opposite is also true. A point cloud may look less impressive because it has a lower point density, but still be technically excellent if the geometry is reliable and the required information can be extracted.

Visual appearance and geometric reliability are not the same thing.

SEE IT IN PRACTICE

In an elevator shaft verification project, registered point cloud data was used to identify and quantify geometric deviations that were preventing installation of the elevator system.

Subscribe now

Higher point density is not automatically better.

There are projects where dense point cloud data is important. If the objective is to create a detailed mesh, for example, the additional geometric information can be valuable.

But if the required measurements, geometry or documentation can be reliably extracted from a lower-density point cloud, additional points may simply create a larger dataset.

That affects storage, transfer, processing performance and the ability of downstream systems to work efficiently with the data.

The right point density is therefore always project-dependent.

More points only add value when the project actually needs them.

SEE IT IN PRACTICE

During a digital cemetery mapping project, the processed datasets contained more data than the target platform could efficiently handle. The point clouds were downsampled while preserving the geometry required for the final application.

Subscribe now

A point cloud is useful when it is correctly registered, has the appropriate point density, and contains the information required for the intended project outcome.

A visually impressive or extremely dense point cloud is not necessarily better. If the information required by the project can be reliably extracted from a smaller dataset, additional points may only increase file size and make processing, transfer and downstream use more difficult.

The intended deliverable matters too. A point cloud prepared for detailed mesh generation may require a very different level of density from one used for measurements, CAD documentation or integration into another platform.

For me, the most important question is therefore not how much data the point cloud contains, but whether it contains the right data for what needs to happen next.

A useful point cloud is not the one that looks impressive. It is the one that is prepared for the purpose of the project.

SEE IT IN PRACTICE

In a digital cemetery mapping project, the completed point clouds contained more data than the target platform could efficiently process. I reduced the point density while preserving the geometry required for the final application.

Subscribe now

Most people begin by asking which scanner they should use. In my experience, that is rarely the first question. The better question is: What does the project actually need?

Only then does it make sense to decide which technologies, workflows and specialist knowledge will deliver the right result. That idea sits at the heart of how I approach every project.

This article is an introduction to that way of thinking and the starting point of the Reality Capture Knowledge section. As new articles are published, each stage of the workflow introduced here will expand into dedicated technology guides, Field Notes and documented project examples.

Every Project Begins With a Question

Before choosing equipment, planning fieldwork or opening processing software, every project starts with an objective. What information is needed? Who will use it? How accurate does it need to be? What will happen to the data afterwards?

The answers to these questions influence every decision that follows. Two projects may appear similar on the surface yet require completely different workflows because their objectives are different. Understanding the project first almost always leads to better technical decisions later.

Capturing Reality

Reality capture begins in the physical world. The objective is straightforward: to collect reliable spatial information that can be transformed into useful digital data.

Today there are many different ways to capture that information, including terrestrial laser scanning, mobile mapping, SLAM-based systems, photogrammetry, UAV surveys and GNSS-supported workflows. Each has strengths, each has limitations and none of them is automatically the “best” technology. The right choice depends entirely on the project, the environment and the required outcome.

Throughout my career, I have worked across several of these workflows, and one lesson has remained remarkably consistent.

Good data starts with good planning.

The scanner only records what you choose to capture.

From Reality to Data

One of the biggest misconceptions I still encounter is that a point cloud is already the finished product.

It isn’t.

A point cloud is measurement data.

It is the digital representation of a real environment, created from millions or sometimes billions of measured points. That dataset often becomes the foundation for engineering documentation, survey drawings, BIM workflows, mesh generation, inspection, measurements, visualisation or digital twins.

The point cloud itself is rarely the final objective. It is one stage within a much larger process, and understanding that difference changes the way projects are planned from the very beginning.

Processing Is Where Information Begins to Take Shape

Collecting data is only one stage of a reality capture project. Once fieldwork is complete, the dataset needs to be transformed into something reliable, organised and usable.

Depending on the project, processing may include:

• Registration

• Georeferencing

• Cleaning and optimisation

• Quality assurance and quality control (QA/QC)

• Dataset organisation

• Classification

• Export preparation

• Deliverable preparation

This is where separate scans become a coherent dataset, errors are identified, data quality is verified and information is prepared for the people who will use it next. It is also one of the areas where I most often support project teams as an independent reality capture specialist.

Deliverables Are the Real Objective

Technology is rarely the final deliverable. Clients are not looking for a scanner, or even for a point cloud. They are looking for reliable information that supports the next stage of their project.

Depending on the objective, that deliverable may be a clean point cloud, a mesh, CAD drawings, BIM-ready data, measurements, technical documentation or something entirely different. Understanding the final objective helps determine every earlier decision in the workflow.

The deliverable should shape the process and not the other way around.

Choosing the Right Workflow

Modern reality capture offers more choices than ever before, which makes experience increasingly valuable. More data is not always better data. The newest technology is not automatically the right technology, and the fastest workflow is not always the most efficient once processing, quality control and project requirements are taken into account.

Good decisions come from understanding how the different parts of the workflow influence one another. Field decisions affect processing, processing decisions affect usability, and dataset structure affects downstream workflows. Every stage has consequences for the next.

That wider perspective has shaped the way I approach projects throughout my career.

An Evolving Technology Map

Reality capture continues to evolve. New sensors appear, software improves, automation becomes more capable and AI is beginning to reshape parts of the workflow.

The technologies will continue changing, but the underlying questions remain remarkably consistent: what needs to be captured, what level of accuracy and information is required, how should the data be processed and what does the final deliverable need to support?

Reality Capture Knowledge will continue to expand around these questions, with dedicated articles, practical guides, Field Notes and real project examples covering individual technologies and workflow stages.

The Workflow at a Glance

Every completed project improves the next workflow.

Explore Reality Capture Knowledge

This article is the starting point.

From here, the knowledge base continues through three complementary types of content:

Reality Capture Knowledge →
Technical articles exploring the technologies, methods and decisions behind modern reality capture workflows.

Field Notes →
Shorter observations, technology encounters and practical lessons from field work and industry experience.

Projects →
Documented case studies showing how technologies, workflows and technical decisions are applied to real projects.

Whether you are new to reality capture or already working with spatial data, I hope these resources help you understand not only the technologies themselves, but also the thinking behind using them effectively.

Reality capture is not about the scanner. It is about understanding the entire workflow.

Let’s stay connected.

RdesignR is where I share projects, technologies, lessons and practical experience from my work in reality capture and spatial data.

If you work in this field, are exploring these technologies, or simply find this world as interesting as I do, I’d be glad to have you along.

LINKEDIN • EMAIL • WHATSAPP

Subscribe now