From a Phone Orbit to a Gaussian Scene: A Local 3DGS Chair Experiment

We reconstructed a static chair scene from a phone video with a local 3D Gaussian Splatting (3DGS) pipeline. The final 7,000-step run passed after COLMAP registered all 48 sampled views. It produced 532,612 Gaussian primitives, a validation render, and a decodable novel-view trajectory.

This is a reconstruction result, not a single-image asset generator and not a clean mesh-delivery workflow. It ran locally on an RTX 5090 Laptop GPU with 24 GB of VRAM, in an isolated WSL environment, without a third-party inference API.

What 3DGS does

The original 3DGS method starts from calibrated cameras and a sparse point cloud. It optimizes many anisotropic, semi-transparent 3D Gaussians—each with a position, shape, opacity, and view-dependent appearance—then rasterizes them into new views. Optimization alternates with density control so the representation can add or remove Gaussians where image evidence needs more detail. Kerbl et al.'s paper and project page are the primary reference.

Before training, the images must support camera recovery. We used COLMAP as a CPU-side admission gate. Its Structure-from-Motion pipeline estimates camera parameters and sparse 3D structure from overlapping images of the same static subject. COLMAP's guidance calls for texture, stable illumination, substantial overlap, and real camera translation rather than rotating from one fixed position. COLMAP's tutorial explains the constraint.

phone video
  -> sampled portrait frames
  -> COLMAP camera poses + sparse points
  -> gsplat optimization and density control
  -> Gaussian scene + validation render + novel-view video

We used gsplat for its CUDA rasterization and COLMAP-oriented trainer. It is an implementation of Gaussian splatting, not a different reconstruction claim.

The qualification gate mattered

The first video was rejected before GPU training. It supplied 36 sampled frames, but COLMAP registered only two cameras and recovered 362 sparse points. That is not enough geometric evidence for a useful scene model, so the pipeline stopped instead of asking the optimizer to make a plausible-looking but unsupported result.

The successful input was a portrait phone orbit of the chair. We preserved its aspect ratio while resizing frames to 540×960. COLMAP then registered all 48 sampled images and recovered 12,525 sparse points.

Registration is the first falsifiable test. A dense-looking output alone would not prove that the input was reconstructable.

From smoke test to full run

The qualified chair capture first ran through a 250-step smoke test. That verified the source revision, Blackwell compatibility patch, dataset, trainer, and verification path before the full run. Only after an explicit continuation did we execute 7,000 steps.

These are run-specific validation measurements for this capture and split. They show that full optimization materially improved over the smoke test. They are not physical measurement accuracy, a universal benchmark score, or a comparison against an unrelated single-image model.

The final validation render preserved the chair, floor, nearby chair, door, bag, and lighting as one captured static scene. Its camera-path video decoded at 1088×960 and 30 fps. The trajectory is 1.23 seconds long; it is not a claim of complete 360-degree capture coverage.

This silent validation trajectory is included as an observation of this run, not as a claim of complete scene coverage or mesh quality.

What this result proves

The experiment proves a bounded local path from a real, static, multi-view capture to a verified Gaussian scene representation. It also proves why an input gate is necessary: a weak capture was rejected before it consumed GPU training time.

It does not make the result a production game mesh. Gaussian splats do not provide clean topology, UV ownership, collision geometry, rigging, or animation. Moving people, changing shadows, reflections, and handheld camera instability remain capture risks.

For a static place or object whose appearance must be observed from nearby viewpoints, this is the right contract. For a portable, editable character or prop, a mesh-oriented workflow remains necessary.