3DGS Research Pipeline: how it came together.
How it came together.
- 01
Scoring across five scan-difficulty tiers
Most 3DGS benchmarks score against a small set of scene types, usually clean studio scans where every modern engine clears thirty dB. Split the eval into five scan-difficulty tiers, from a clean studio booth through mirror-walled interiors to an extreme commercial office, so engines that excel on clean interiors but fail on mirrored marble get scored honestly, not averaged away.
Research - 02
Failure mode is a first-class metric
Engines do not just produce worse images on hard scenes: they crash, produce floaters, or output garbage point clouds that crash downstream rendering. Every failure is logged as a red cell in a per-engine × per-scan heatmap, still filling in as more scans run. The write-up will lead with that matrix, not PSNR scores: robustness is what a production team actually buys.
Data Pipelines Off-plan has nothing to scan. The generated path and the captured path end in the same viewer, so a real apartment and an unbuilt one do not need two codebases. - 03
Novel-view synthesis as a parallel path
Off-plan luxury properties have no scan to start from, the building has not been built yet. Video diffusion and monocular depth lift run in parallel to the scanned pipeline, so the same viewer shows a real apartment and an AI-imagined one without two separate codebases. Both paths are evaluated against COLMAP-grounded baselines.
AI & Machine Learning - 04
Raw vs. cleaned, scored separately
Floaters and stray gaussians make a scan look worse than the underlying capture warrants. Scoring raw output and cleaned output separately keeps it visible how much of the gap is the engine and how much is post-processing, instead of folding both into one number. The comparison closed before that split was run across the full eval, so it rests on spot checks.
3D & Spatial
Decisions on the record.
The few calls worth defending. Each one is a fork; the other branch would have been a different project.
gsplat as the CUDA-native reference path
gsplat is the CUDA-native training engine the field has largely standardised on: faster training, cleaner gradient flow, a maintained Nerfstudio integration. It is one of the 26 engines recon-bench runs, and the one this benchmark's own tooling is built around.
Writing it up as an academic paper
The gap here was not a new method, it was an evaluation harness paired with real deployment context. Writing it up as a paper forces that rigour and makes the work citable alongside the engines it benchmarks.