Point clouds are becoming operationally difficult
Point clouds are now essential to industrial surveying, brownfield modification, scan-to-CAD, and verification workflows. Modern scanners can capture hundreds of millions or billions of points, together with RGB, intensity, scan poses, structured scan information, and panoramic images.
The increased richness is useful, but scale changes the practical problem. A dataset may be accurate and complete while still being difficult to load, navigate, transfer, and reuse in everyday design work.
The all-or-nothing problem
Many workflows treat a point cloud as one monolithic dataset. An engineer who needs one pipe rack, room, equipment area, or elevation band may still have to open and process the entire project.
This creates a mismatch:
- Reality capture produces a large, continuous dataset.
- Engineering tasks are usually local and purpose-specific.
- Designers need only the part relevant to the current model or discipline.
The problem is not that the data exists. The problem is that the workflow often provides no lightweight way to reach exactly the required part.
Hidden duplication of effort
Teams compensate by creating reduced copies, exporting zones manually, maintaining several intermediate versions, and repeating preparation work for different designers. Those adaptations introduce their own costs:
- duplicated storage;
- repeated processing and export time;
- inconsistent subsets and naming;
- difficult handover between survey and engineering teams;
- dependence on high-specification workstations for relatively local tasks.
Memory is only one part of performance
RAM consumption is highly visible, but usability also depends on disk traffic, time to first useful preview, operator preparation time, export strategy, and verification of the resulting files. Downsampling can improve interaction, but it trades detail for responsiveness. Splitting can help, but manual splitting creates repeated work.
A better architecture should keep memory bounded while preserving the option to produce full-resolution outputs from the original source.
A missing preparation layer
The central requirement is a dedicated layer between registered scan data and downstream engineering tools. Its job is not registration and not CAD modelling. Its job is controlled preparation:
- inspect very large source files with a sampled preview;
- select tiles, zones, or height ranges;
- retain the original coordinates and requested attributes;
- stream the source again for verified full-resolution export;
- create organized outputs for individual engineering tasks.
This is the problem that led to CloudCutter. The next publication introduces the first practical implementation of that idea.
E57 file too large to open or use efficiently?
A common engineering problem is not that an E57 file is invalid, but that it contains far more project context than one downstream task needs. A registered scan of an entire plant, building or infrastructure area may be practical as a master dataset while still being inconvenient on an individual CAD or BIM workstation.
Typical symptoms include long opening times, high memory pressure, repeated manual cropping and many local copies of the same source. In that situation, splitting a large E57 into smaller task-specific point-cloud files can be more useful than repeatedly loading the complete project.
Split, crop or subsample: these are different operations
Splitting creates multiple spatial outputs. Cropping extracts one selected region. Subsampling reduces point density. CloudCutter focuses on spatial preparation: selecting useful regions and exporting points from the original source so that selected outputs can retain full source resolution.
For measured examples, see the CloudCutter E57 benchmark series.