Gaussian Splat: The gap you can't see is still there
Gaussian Splat: The gap you can't see is still there
Why AI-filled geometry and measured geometry aren't the same thing, and why that difference matters on compliance-facing work
There's a pattern showing up across more and more capture tools: hit a gap in the scan, and let AI fill it in rather than flag it.
It's easy to see why. A hole in a 3D model looks broken. A smooth, photorealistic render looks like a finished product. Gaussian splatting, the technique behind a lot of the "instant 3D twin" tools on the market right now, is very good at the second option. Point a camera, walk through a space, and the software renders a continuous scene, including in areas it never actually measured.
That's not a criticism of the technology. Splatting is genuinely useful. Rendered well, it's fast, cheap, and photorealistic in a way older methods aren't. The problem is what happens when that output gets treated as data rather than as a picture.
Rendered Isn't The Same As Measured
AEC Magazine's overview of Gaussian splatting in AEC workflows is a useful primer on where the industry has landed on this. Even vendors moving early on splatting, Bentley among them, are positioning it as a complementary visual layer rather than a replacement for photogrammetry, meshing, or LiDAR. The established pipelines stay responsible for geometry and measurement. Splats provide the walkthrough.
That distinction matters more than it sounds. A recent industry piece on SLAM accuracy put it plainly: a Gaussian splat is a rendering, not a measurement. The article's broader point is that the industry routinely conflates three separate numbers under one word, "accuracy": relative accuracy (internal consistency), absolute accuracy (agreement with real-world coordinates), and point-cloud noise. A capture method can score well on one and poorly on another, and a single headline accuracy figure hides which one you're actually getting.
A Gaussian splat is a rendering, not a measurement.
Put the two together and you get the core issue. More tools are quietly filling gaps with AI-generated best guesses, and doing it well enough that the gap isn't visible in the output. That's fine for a marketing walkthrough. It's a real problem the moment that dataset gets used for anything else: a measurement, a BIM model, a condition report, a golden thread submission.
One Word, Three Numbers
Winston Wen, founder of Tersus GNSS, made a sharp observation in a recent piece for Geo Week News: watch any handheld scanner demo at a geospatial conference and you'll see the same show. The device sweeps the room, a dense, colourful point cloud fills the screen, and someone in the crowd calls it accurate. The cloud looks thick. The colours look vivid. Nobody in the room has actually checked anything.
"Accurate" is quietly standing in for three different measurements, and the demo has shown none of them properly.
Wen is blunt about where the blame sits too: he runs a scanner company himself, and treats the piece as much a confession as a complaint. The industry, his own included, has let one comfortable word cover three numbers that behave nothing alike in practice. The cost isn't abstract. It shows up as specs nobody can actually test a scanner against, deliverables that get disputed because both sides were quoting a different number under the same word, and rework a ten-minute conversation upfront would have avoided.
Relative, Absolute, Noise
Relative Accuracy
Relative accuracy asks whether the model agrees with itself. If two doorways sit 12.40 metres apart in the real building, do they still sit 12.40 metres apart in the point cloud? This is the number SLAM systems are naturally strong at, since loop closure keeps the model internally consistent. It degrades with drift, long unclosed paths, and featureless corridors, and it's also the number spec sheets quote most often, usually without saying what conditions it was measured under.
Absolute Accuracy
Absolute accuracy is a separate question entirely. Is that same doorway actually where the real-world coordinates say it should be? A dataset can be internally consistent to a few millimetres and still sit twenty centimetres off true position, or lean slightly off vertical. This number has nothing to do with the SLAM algorithm itself. It comes entirely from anchoring, RTK where satellite visibility allows it, surveyed ground control where it doesn't, and it's the number most contracts are actually judged against once work is delivered.
Point-Cloud Noise
Point-cloud noise is what that conference crowd was really looking at. Scan a flat painted wall and the points won't sit neatly on a plane. They'll form a fuzzy shell with real thickness, often a centimetre or two for this class of device, and that thickness grows with range and with shallow angles of incidence. Noise is a property of the sensor and the geometry of the shot, not of how the trajectory was flown.
On screen, noise looks like density, and density looks like quality. A thick, busy point cloud reads as more impressive than a thin, quiet one, even when the thin one is the more accurate dataset.
The three numbers are independent of each other. A device can score well on two and fail the third, and that's not a flaw in the instrument. It's just the nature of the measurement. The real defect is in how the industry talks about it, folding three different questions into one reassuring word.
What Can Actually Be Checked On Site, Today
None of this needs lab equipment.
Point-cloud noise is the easiest to test. Scan a flat wall, take a thin slice through the data, and measure how thick that "wall" actually comes out at the point cloud level. A clean scan gives you a thin, tight shell. A noisy one gives you a smear.
Relative accuracy is almost as quick. Pick two fixed reference points in the space, door frames or columns work well, measure the real-world distance with a tape, then compare that against the same distance in the model. This tells you whether the capture is internally consistent, not whether it sits correctly in the real world.
Absolute accuracy needs one extra step: hold back two or three surveyed points from the original adjustment, treat them as independent checkpoints, and report the residual difference once the model is built. This is the test that actually answers "is this positioned correctly," and it's the one most spec sheets skip. Saying "18mm RMSE against independent checkpoints" tells a client something real. Saying "accuracy: 1cm" on its own tells them almost nothing, because it doesn't say which of the three numbers it's describing, or how it was measured.
None of these checks take more than a few minutes on site. The table below is what I'd want every capture spec sheet, and every project report, to lead with instead of a single unexplained figure.
| The Number | The Question It Answers | What Degrades It | Field Check |
|---|---|---|---|
| 01Relative accuracy | Is the model consistent with itself? | Drift, missed loops, degenerate scenes | Tape known distances; compare |
| 02Absolute accuracy | Is the model where the world says it is? | RTK pseudo-fix, weak anchors, poor control layout | RMSE on independent check points |
| 03Point-cloud noise | How fuzzy is each surface? | Sensor class, range, incidence angle, reflective materials | Section a flat wall; measure shell thickness |
| 043DGS output | How convincing is the picture? | Capture coverage, lighting, motion blur | Not a measurement - do not quote accuracy |
Why This Is A Compliance Question, Not Just A Technical One
This isn't a hypothetical concern dressed up for a blog post. RICS's own research shows a real gap between AI adoption and AI confidence: a meaningful share of construction and commercial surveyors report they're not yet aligned with the RICS AI standard that came into force in March 2026, with reliability concerns cited as a leading reason. That's a professional body naming the tension directly.
And the risk is starting to get priced, not just discussed. Design professional liability insurers have begun filing AI-specific policy exclusions, citing published research on how often generative outputs can be wrong. Whatever you think of the specific numbers, the direction is clear: "the AI filled in a gap and got it wrong" is moving from theoretical to underwritten.
A dataset can look complete and still contain sections nobody actually verified.
For anyone specifying capture on a project where the output feeds a compliance record, that's the practical takeaway.
The Question Worth Asking Your Capture Vendor
Before accepting any 3D dataset for compliance-facing work, ask one thing: where did the AI infer, and where did the sensor measure?
A credible vendor can answer that. They can show accuracy figures broken down by method rather than one blended number for the whole dataset, and they can tell you, area by area, what was captured directly versus rendered to fill a gap.
That's not a reason to avoid these tools. Splatting has a real place, particularly for fast, low-cost visual documentation where photorealism matters more than millimetre accuracy. It's a reason to be precise about which job you're asking it to do, and to keep the measurement-critical work on methods built to answer that question honestly.
If you need help, Twinflow Consulting works across a wide range of 3D capture technology.
We put together solutions designed for the specific project, not a one-size-fits-all sensor. Book a consultation below to find out more.
