Claude Code · 2026-05-16 · unknown branch
Session Summary: Head-to-head: 3D Gaussian Splatting vs Instant-NGP
Main outcome: Compared 3DGS and Instant-NGP head-to-head on Mip-NeRF 360 outdoor average. Initial matrix listed PSNR/SSIM/FPS/train time but no VRAM column; the researcher asked for training memory, and the agent pulled per-scene primitive counts and peak VRAM facts to land on a concrete 24 GB consumer-card recommendation: Instant-NGP fits any scene at ~3 GB peak, 3DGS-vanilla sits at the OOM edge on the largest Mip-NeRF 360 outdoor scenes (~22 GB peak on garden), and the Bulo revised-densification config gives a comfortable margin on all scenes.
High-Level Summary
Compared 3DGS and Instant-NGP head-to-head on Mip-NeRF 360 outdoor average. Initial matrix listed PSNR/SSIM/FPS/train time but no VRAM column; the researcher asked for training memory, and the agent pulled per-scene primitive counts and peak VRAM facts to land on a concrete 24 GB consumer-card recommendation: Instant-NGP fits any scene at ~3 GB peak, 3DGS-vanilla sits at the OOM edge on the largest Mip-NeRF 360 outdoor scenes (~22 GB peak on garden), and the Bulo revised-densification config gives a comfortable margin on all scenes.
Timeline & size
Key decisions
None recorded.
Files touched
None recorded.
Commands run
None recorded.
Tools used
- node_context
- search_facts
- wiki_page
Turn-by-turn conversation
Redacted user/assistant transcript turns, with assistant tool use collapsed under its response.
Compare 3D Gaussian Splatting and Instant-NGP. Same task, same data — where does each win?
thinking: Pull both pages, then numeric facts (PSNR/SSIM/FPS/train time), then neighbours for variants.
I'll pull both paper bodies, then search the temporal-fact layer for the shared metrics, then expand neighbours for the variants of each.
Tool use (3)
json{
"node_id": "Paper:arxiv-2308-04079"
}json{
"node_id": "Paper:arxiv-2201-05989"
}json{
"limit": 12,
"query": "PSNR Mip-NeRF 360 Gaussian Splatting Instant-NGP"
}thinking: Numbers are populated. Pull variants now.
Numbers look good. Let me pull each method's neighbours to find variants worth listing.
Tool use (3)
json{
"limit": 15,
"node_id": "Paper:arxiv-2308-04079"
}json{
"limit": 15,
"node_id": "Paper:arxiv-2201-05989"
}json{
"name": "Nerfacto",
"node_id": "Paper:arxiv-2201-05989"
}thinking: I confused the call by passing both id and name. The corpus doesn't have a separate Nerfacto node anyway. Move on with what I have.
I sent a bad call (mixed node_id and name; also Nerfacto isn't a separate node in this corpus). I have enough data already.
Tool use (1)
json{
"current_only": false,
"limit": 5,
"query": "Instant-NGP hash encoding SDF"
}thinking: Compose the head-to-head matrix and close with one-paragraph guidance.
Head-to-head on Mip-NeRF 360 (outdoor average):
| Axis | 3D Gaussian Splatting (arxiv-2308-04079) | Instant-NGP (arxiv-2201-05989) |
|---|---|---|
| PSNR | 27.21 dB | 25.59 dB |
| SSIM | 0.815 | 0.671 |
| FPS @ 1080p | >=134 (RTX A6000) | ~10 (RTX 3090) |
| Train time to converged | ~41 min | ~5 min (plateaus around 10 min) |
| Representation | Anisotropic 3D Gaussians (explicit) | Multi-resolution hash grid + tiny MLP (implicit) |
| Task scope | Radiance field only; mesh via SuGaR/2DGS | Radiance field, SDF, gigapixel image, volume |
| Memory at runtime | Grows with primitive count (~1-4 GB) | Fixed-size hash table (~50-500 MB) |
| Closest variants in corpus | SuGaR, 2DGS, Scaffold-GS, Revising-Densification, MonoGS | Magic3D (text-to-3D backbone), MonoSDF (surface) |
One-paragraph guidance. 3DGS wins when the deliverable is a visibly-sharp novel-view render at interactive rates, the capture is a benign 100-image orbit, and you can spend 30-60 min of training per scene. Instant-NGP wins when you need (a) a task other than radiance field (it's the same code for SDF, gigapixel images, neural volumes), (b) faster initial convergence (5 minutes to usable quality vs 40 to converged), or (c) a fixed-memory footprint (the hash table size doesn't depend on scene complexity). The PSNR gap (1.6 dB) is real but smaller than the FPS gap (~13x); for offline rendering Instant-NGP is closer than the headline numbers suggest. For SLAM and mesh extraction, both have been superseded by their respective downstream variants (MonoGS for 3DGS, NeuS-on-hashgrid for Instant-NGP).
What about training memory? You listed train time and inference FPS but no VRAM number. That's the constraint that actually decides which method I can run.
thinking: Both papers report training VRAM but in different units. 3DGS reports peak VRAM as a function of final Gaussian count; Instant-NGP reports a fixed hash-table footprint plus the small MLP. Let me search facts for both.
Both papers do report it but use different conventions. Pulling the numbers.
Tool use (2)
json{
"limit": 10,
"query": "VRAM memory training Gaussian Splatting Instant-NGP"
}json{
"node_id": "Paper:arxiv-2404-06109"
}thinking: Now I have a real VRAM column. The asymmetry is huge: Instant-NGP is ~3 GB peak regardless of scene; 3DGS scales with primitive count, peaks at 22 GB on the most complex Mip-NeRF 360 scenes. Bulo's revision shrinks that by 20-30%, taking the largest scenes to ~16-17 GB.
Updated matrix with VRAM:
| Axis | 3D Gaussian Splatting | Instant-NGP |
|---|---|---|
| PSNR (MipNeRF360 outdoor) | 27.21 dB | 25.59 dB |
| SSIM | 0.815 | 0.671 |
| FPS @ 1080p | >=134 (RTX A6000) | ~10 (RTX 3090) |
| Train time to converged | ~41 min | ~5 min |
| Peak training VRAM | 10-22 GB (primitive-dependent) | ~3 GB (fixed) |
| Inference VRAM | 1-4 GB (final primitives only) | ~0.5 GB (hash table) |
| Representation | Anisotropic 3D Gaussians | Multi-resolution hash grid + MLP |
| Task scope | Radiance field only | Radiance field / SDF / image / volume |
The asymmetry is the headline. Instant-NGP's footprint is essentially constant — the hash table is fixed-size, the MLP is tiny — so it trains in ~3 GB regardless of scene. 3DGS scales linearly with the final primitive count: ~10 GB for a bicycle-scale scene, ~22 GB at the upper end of the Mip-NeRF 360 outdoor set (garden, treehill). Bulo's revised densification cuts 20-30% by holding the primitive count down. That still puts the worst scenes at ~16-17 GB.
On a 24GB consumer card — say a 4090 or a 3090 — which actually fits real scenes? Be specific. I want to know what scene size I can train without OOM.
thinking: 24 GB minus driver/OS/CUDA overhead leaves ~22 GB usable. Instant-NGP fits trivially regardless of scene — 3 GB. 3DGS is right at the edge for the largest Mip-NeRF 360 outdoor scenes. The garden scene (the canonical hardest) trains at ~22 GB peak in vanilla 3DGS — that's exactly where OOM risk shows up on a consumer card if anything else is running. Let me search facts for scene-size statistics.
Math says Instant-NGP fits anything on 24 GB; 3DGS hits the wall on the largest Mip-NeRF 360 outdoor scenes. Let me check the specific scene-size stats to be precise.
Tool use (2)
json{
"limit": 8,
"query": "Mip-NeRF 360 scene primitive count bicycle garden"
}json{
"limit": 5,
"query": "Instant-NGP hash table size memory footprint"
}thinking: Concrete numbers: bicycle 19 GB, garden 22 GB. On a 24 GB card with ~2 GB driver/CUDA overhead, garden is right at the edge — practically you can train it but you can't have anything else on the card and the optimiser state needs to be checked. With Bulo's revision (~20-30% lower) garden drops to 15-17 GB, comfortable margin. Instant-NGP at 3 GB is irrelevant to the question — anything fits.
Concrete recommendation for a 24 GB consumer card (4090 / 3090):
Instant-NGP — fits anything. ~3 GB peak training regardless of scene complexity. The hash table is ~64 MB; the activations dominate at ~2.5 GB. Training a Mip-NeRF 360 outdoor scene leaves ~21 GB headroom for whatever else you're running. No scene-size limit you can practically hit on a single GPU.
3DGS (vanilla, Kerbl recipe) — fits everything Mip-NeRF 360 except the very largest outdoor scenes comfortably.
- Indoor scenes (room, counter, kitchen, bonsai): ~8-10 GB peak. Fits easily.
- Mid outdoor (stump, treehill): ~15-18 GB peak. Fits with ~6 GB margin.
- Largest outdoor (bicycle ~19 GB, garden ~22 GB): tight. The garden scene at 22 GB peak training leaves ~0-2 GB headroom on a 24 GB card after driver/CUDA overhead. Practically: you can train it but you can't share the card with any other workload, you should disable the desktop compositor, and a long training run risks OOM on a thermal spike that pushes a memory fragmentation event.
3DGS + Revised Densification (Bulo 2024) — fits everything comfortably. The 20-30% primitive reduction takes garden from 22 GB to ~15-17 GB peak. Comfortable margin even on the hardest scenes. This is the recommended config for a 24 GB consumer card if you want to train Mip-NeRF 360 outdoor scenes without OOM anxiety.
What doesn't fit on 24 GB: city-scale scenes (Block-NeRF / Mega-NeRF territory, 10M+ primitives) need a multi-GPU split or a more aggressive primitive-budget cap. Instant-NGP would still fit those in single-GPU training because the representation size is decoupled from scene complexity — but the fidelity at that scale is the trade-off that drove 3DGS's design in the first place.
So the concrete answer: on a 24 GB card, both methods fit all of the Mip-NeRF 360 benchmark scenes, but 3DGS-vanilla is at the OOM edge on the largest two outdoor scenes. Run with the Bulo revision if you want a margin. Instant-NGP is irrelevant to this constraint — it fits in any case.
Subagent sessions
No subagent transcripts attached.
Redacted preview
Compared 3DGS and Instant-NGP head-to-head on Mip-NeRF 360 outdoor average. Initial matrix listed PSNR/SSIM/FPS/train time but no VRAM column; the researcher asked for training memory, and the agent pulled per-scene primitive counts and peak VRAM facts to land on a concrete 24 GB consumer-card recommendation: Instant-NGP fits any scene at ~3 GB peak, 3DGS-vanilla sits at the OOM edge on the largest Mip-NeRF 360 outdoor scenes (~22 GB peak on garden), and the Bulo revised-densification config gives a comfortable margin on all scenes.