2DGS vs. 3DGS: One Chair Capture, Two Kinds of Gaussian Scene
2D Gaussian Splatting (2DGS) and 3D Gaussian Splatting (3DGS) are both 3D reconstruction methods. The “2D” in 2DGS does not mean that it produces a flat scene. It describes the shape of each primitive: 2DGS uses surface-aligned disks, while 3DGS uses anisotropic 3D ellipsoids.
We ran both methods on the same phone capture of a static chair and its surrounding room. The result is not a general leaderboard. It is a focused test of the practical difference between a rendering-first Gaussian scene and a surface-oriented one.
The shared input contract
Both methods started from the same qualified multi-view reconstruction: 48 sampled camera views, all registered by COLMAP, with 12,525 sparse points. That matters because Gaussian splatting does not turn an arbitrary video into reliable 3D. It needs overlapping views of a subject that remained still while the camera moved around it. COLMAP's tutorial explains the camera-recovery requirement.
The full runs each used 7,000 optimization steps. The input, camera evidence, and evaluation setup were held constant so that the representation was the meaningful variable.
What changed in the representation
3DGS starts from calibrated sparse points and optimizes a collection of anisotropic 3D Gaussians with position, shape, opacity, and view-dependent appearance. It combines density control with a fast visibility-aware renderer for novel-view synthesis. The original 3DGS project is the primary reference.
2DGS represents the scene as oriented 2D disks, often called surfels. The official project adds geometry-oriented regularization and documents mesh-extraction approaches built from the reconstructed surface. The official 2DGS implementation describes the representation and its meshing paths.
The distinction is not that one scene has depth and the other does not. Both are 3D. The distinction is whether the primitive is free to behave like a small volume or is explicitly encouraged to sit on a visible surface.
Our local demo result
| Result from the same chair capture | 3DGS | 2DGS |
|---|---|---|
| Representation count | 532,612 Gaussians | 379,865 surfels |
| PSNR | 25.718 | 28.289 |
| SSIM | 0.921 | 0.932 |
| LPIPS | 0.098 | 0.083 |
| Delivered observation | Gaussian scene render | Surfel render with depth and normal observations |
PSNR and SSIM improve when they rise. LPIPS improves when it falls. On this capture's held-out views, 2DGS produced a closer image match by all three measurements.
That is useful evidence, but it has a narrow meaning. These measurements compare rendered validation images with photos from one static scene. They do not prove physical measurement accuracy, establish a general benchmark, or guarantee that another subject, capture path, lighting condition, or training configuration will produce the same ranking.
Why the previews appeared so different
Each trajectory export in this demo contained two diagnostic panels: the RGB render and an expected-depth view. The gray depth panel is not a second material treatment or a different 3D asset. Its values are normalized for each frame, so brightness should not be compared as if it were a photorealistic render.
The fair visual comparison is RGB against RGB. The three-column validation check below makes the input and the two model renders explicit.
Left: validation reference photo. Middle: 3DGS RGB render. Right: 2DGS RGB render. The two render columns are outputs from separate trained representations, not copies of the reference pixels.
Because both methods are optimized to reproduce this capture near its observed camera views, their RGB trajectories can resemble the input footage. The clip below is not an excerpt of the input MOV: it is a side-by-side re-encoding of the two model-rendered RGB trajectories.
Left: 3DGS RGB. Right: 2DGS RGB. This silent 1.23-second camera-path comparison uses the same capture and excludes the depth diagnostic panel.
Which method fits which job?
| Goal | Better first choice | Why |
|---|---|---|
| Explore a static room, facade, or object from nearby viewpoints | 3DGS | It is the direct, mature baseline for free-viewpoint scene rendering. |
| Inspect surface continuity, depth, normals, or prepare for mesh extraction | 2DGS | Surface-aligned surfels make geometry a first-class concern. |
| Create a portable prop or character from one image | Neither | Use an image-to-asset workflow, then review its generated mesh. |
| Reconstruct a kick, walk, or another continuous action | Neither | A static Gaussian scene assumes the subject did not move during capture. |
Neither result is a game-ready asset by default. A Gaussian scene does not supply clean topology, UV ownership, collision geometry, rigging, or animation. Our current 2DGS demo also does not claim a finished editable mesh; it proves the local surfel, depth, and normal-rendering path.
The next experiment: test the surface claim
The next useful step is not another beauty render. It is a mesh-oriented test on the same qualified capture: extract a surface from 2DGS, compare it with a conventional reconstruction baseline, and inspect both in Blender.
The acceptance criteria should be practical: connected components, holes, normal consistency, triangle count, scale, and whether each result opens and renders cleanly in a DCC. Held-out camera views should remain part of the review. That experiment directly tests the reason to choose 2DGS in the first place: whether its surface-oriented representation creates a more useful downstream surface.
Dynamic Gaussian methods belong after that. A moving person introduces time as another unknown, so a handheld orbit of a kick cannot distinguish body motion from camera motion. It needs a separate time-aware capture and evaluation design.