The Splat Stack: Where Gaussian Splatting Turns Into Five Different Products

What Actually Makes a Splat Ship-Ready

A Gaussian splat scene is, mechanically, nothing but a big flat list of anisotropic 3D Gaussians — each one a position, a covariance matrix (which factors into an orientation and a per-axis scale), an opacity, and a spherical-harmonic term encoding view-dependent color. There's no surface, no topology, no mesh underneath any of it. What makes this fast enough to matter is how it renders: sort the Gaussians by depth, splat each one onto the screen as a soft 2D footprint, and alpha-composite them front-to-back. That's a rasterization problem, not a ray-marching problem — which is exactly the axis it beats NeRF on, since a NeRF has to query a neural field along a ray for every pixel, and it's the axis it beats photogrammetry on, since photogrammetry has to solve for a consistent triangle mesh before it can render anything at all. Splats skip both steps and get real-time frame rates on hardware a NeRF would choke on.

That one property — direct render speed with no intermediate solve — is the entire reason this stopped being a research curiosity and turned into a product substrate in under two years. It's also why the tooling around it has fragmented into five genuinely different businesses that only look like one industry because they all produce or consume the same Gaussian-cloud format: generating whole worlds from a prompt (Marble), capturing real spaces into splats with dedicated hardware (XGRIDS), querying and detecting objects inside an existing splat (Splat Analyzer), getting a splat to actually load and render inside an engine or a browser (Unity/Unreal/web deployment), and generating single mesh-first objects that get composited into a splat scene rather than being splats themselves (fal.ai/Tripo). Each of those five competes against a completely different set of alternatives, on a completely different axis. That's the structure worth following, because "gaussian splatting" as a category label obscures how little these five have in common day to day.

Marble's Bet: An Exportable World Instead of a Live One

World Labs built Marble to take five distinct kinds of input — a text prompt, a single image, multiple images, a video, a coarse 3D layout in what they call Chisel mode, or an existing 3D asset you want to restyle — and turn all of them into the same three output types: Gaussian splats (framed as the highest-fidelity representation, rendered through Spark, their open-source three.js renderer), triangle meshes in both a low-fidelity collision-ready form and a high-fidelity visual form, and video with pixel-accurate camera control through the generated space. It reached general public release on November 12, 2025, then added a World API in January 2026 so the same pipeline could be called programmatically instead of only through the web app. You can edit iteratively — removing an object, restyling structure — and expand a generated world into an adjacent region, though that expansion is capped at one region per world, which tells you the underlying model still has limited confidence extrapolating far past what it originally generated.

flowchart LR
    A[Text prompt] --> G[World-model generator]
    B[Single image] --> G
    C[Multi image] --> G
    D[Video] --> G
    E[Chisel coarse layout] --> G
    F[Existing asset restyle] --> G
    G --> H[Gaussian splats]
    G --> I[Low-fi collision mesh / high-fi visual mesh]
    G --> J[Camera-controlled video]
    H --> K[Spark 2.0 progressive LOD streaming]
    K --> L[Web viewer]

The piece of that stack that matters most for anyone shipping a scene rather than a demo is Spark 2.0, which landed April 14, 2026. Before it, a gigabyte-scale splat scene meant a full download before anything rendered — dead time nobody tolerates in a browser. Spark 2.0 adds a streamable level-of-detail system: the viewer loads a low-resolution version of the whole scene first, then fills in detail as the camera explores it, so a scene that would take minutes to download becomes interactive in seconds and sharpens as you move. That's not a convenience feature — it's the fix for the specific failure mode that made web-delivered splat scenes impractical at real size.

Where Marble gets interesting competitively is that its real rival isn't another splat tool at all — it's Google DeepMind's Genie 3, which generates a world live as you explore it at roughly 24fps and 720p, sits behind a $250/month Google AI Ultra subscription with no public API, and produces nothing you can take away afterward. Odyssey sits closer to Genie's model too: API-accessible, continuous interactive simulation, with enough investor conviction to raise a $310 million Series B in mid-2026. Marble is making the opposite trade on purpose. It gives up the ability to stream a genuinely live, ad-hoc world the way Genie 3 does, in exchange for producing something durable — a splat or mesh you actually own, can edit, and can drop into Unity, Unreal, or a WebXR scene later. Of the three, Marble is the only one that fits into an existing production pipeline rather than functioning as a standalone experience; narrower ambition, but the kind that turns into shipped work.

It has real edges worth knowing before you integrate it. Output quality degrades the further you get from the seed image or prompt — it's fundamentally an outpainting process, extrapolating outward from an anchor view, so confidence and detail both drop with distance. And it's scoped deliberately to environments: it is not built to generate people, pets, or hero characters, and routing that kind of request through it won't error — it'll just quietly hand back something mediocre or malformed. Treat that as a hard boundary on intent, not a quality bar to push past.

XGRIDS and the Shrinking Hardware-Grade Niche

The Lixel L2 Pro is XGRIDS' flagship handheld scanner: 1.7kg, IP54-rated, dual 48-megapixel panoramic cameras plus LiDAR plus a 500Hz IMU, all fused on-device through what XGRIDS calls Multi-SLAM AI, delivering 3cm absolute and sub-1cm relative RMS accuracy while capturing 320,000 to 640,000 points per second depending on variant. The reconstruction happens in LCC (Lixel Cyber Color), XGRIDS' own engine, which takes the point cloud and panoramic imagery straight to a photorealistic Gaussian splat without a separate photogrammetry pass — capture and splat generation are effectively one step, which is the actual product here, not the scanner hardware in isolation.

Its most direct competitor, the NavVis VLX2, doesn't lose on paper so much as trade in a different direction entirely. NavVis claims 8mm accuracy at 100m under ideal conditions, tighter than XGRIDS' spec at that range, but it runs a cloud-based, pay-per-upload processing model, while XGRIDS processes locally with no per-job fee — a real difference if you're scanning anything you don't want leaving the building. In a matched roughly 20-25 minute scan, XGRIDS captured about three times more panoramas and more total points than NavVis, and its SLAM held up better under motion, where NavVis needed control points to stay accurate. Neither wins outright; you're trading data sovereignty and throughput against slightly tighter short-range accuracy and simpler one-button operation.

The pressure that actually threatens the category isn't NavVis, though — it's the bottom falling out from under it. Phone-based capture through Polycam and KIRI Engine now does LiDAR-plus-photogrammetry 3DGS capture for free to $150 a year, and DJI Terra does professional aerial capture at $2,800-4,400 with direct 3D Tiles output for web streaming. None of that touches survey-grade, georeferenced accuracy — nobody serious claims a phone replaces a certified scan — but that's precisely the shrinking slice of work that still justifies XGRIDS' $15,000-25,000 hardware tier. For real estate walkthroughs, game-asset capture, or social content, phone apps have already won by being close enough at near-zero cost. The dedicated hardware tier survives specifically where centimeter-certified accuracy is the deliverable, not as the default entry point into 3DGS capture anymore.

Method	Accuracy	Processing model	Cost	Throughput
XGRIDS Lixel L2 Pro	±1cm relative / 3cm absolute, up to 300m range	Local, on-device, no per-job fee	~$15,000-25,000 (hardware)	320-640k pts/sec; ~680 panoramas in a 20-25 min scan
NavVis VLX2	8mm at 100m under ideal conditions	Cloud-based, pay-per-upload	Per-scan/subscription cloud fees	~297 panoramas, 163M points in a comparable scan
Phone apps (Polycam, KIRI Engine)	Sub-survey-grade, consumer-level	On-device/cloud hybrid, phone-based	Free to ~$150/year	Fast single-space capture, not built for large-site throughput
DJI Terra (aerial)	Professional aerial-grade, site-dependent	On-device processing, exports to 3D Tiles	$2,800-4,400	High area coverage per flight, aerial rather than interior

Splat Analyzer: Querying a Splat Without Training a Model

Splat Analyzer takes a .ply or .spz file and a plain-English prompt like "chair, table, monitor" and hands back labeled 3D bounding boxes, with no training step and no manual annotation. The mechanism is a four-stage pipeline, and none of the four stages is individually novel — the value is that someone wired them together into something you can point at a splat and run.

Stage one renders synthetic camera views around the splat using density-aware sampling, so the view count concentrates where the geometry actually is rather than sampling a uniform sphere. It runs on gsplat for CUDA or gsplat-mps for Apple Silicon, auto-selected by hardware, and the quality preset sets how many views you get: 24 for low, 90 for medium, 192 for high. Stage two runs OWLv2 — an open-vocabulary 2D detector — on every one of those rendered views, against whatever prompt you gave it. Stage three uses the per-view depth maps to back-project each 2D detection into 3D space. Stage four clusters and fuses those back-projected detections across views into a single set of 3D boxes, gated by three thresholds: score_threshold at 0.12, min_votes at 8 supporting frames, and min_peak_score at 0.40. What comes out is interactions.json — label, position, size per object — built to drop straight into WebXR or game interaction zones.

flowchart LR
    A[Splat file .ply/.spz] --> B[Density-aware multi-view rendering<br/>gsplat CUDA / gsplat-mps Metal]
    B --> C[Per-view OWLv2<br/>open-vocabulary 2D detection]
    C --> D[Depth-based back-projection<br/>into 3D]
    D --> E[Cross-view clustering/fusion<br/>score_threshold 0.12 / min_votes 8 / min_peak_score 0.40]
    E --> F[interactions.json<br/>labeled 3D bounding boxes]

The academic competition here — LangSplat's scene-specific language autoencoder, Dr. Splat's CLIP embeddings registered directly onto Gaussians via product quantization — is methodologically more sophisticated than render-detect-project-fuse. Splat Analyzer's actual edge isn't the method, it's that it ships: Docker plus FastAPI, zero training, an 8GB VRAM floor that makes it runnable on a decent consumer card, versus research code that mostly requires per-scene optimization or was never released as an installable tool at all.

That packaging advantage comes with an inherited cost. The detection ceiling here is OWLv2's ceiling, not Splat Analyzer's — one aerial-imagery evaluation logged a 69% false-positive rate under domain shift, and OWLv2 is documented to confuse objects under occlusion and pose variation. Multi-view voting is a noise suppressor, not a fix for the underlying detector; it raises confidence in agreement across views, it doesn't correct what the detector gets systematically wrong. Splat renders are themselves a second domain-shift layer on top of that — synthetic RGB with rendering artifacts and floaters, not the natural photos OWLv2 was trained on. I'd treat every interactions.json this produces as a first draft to hand-check on a cluttered scene, not ground truth, and I'd budget for the "high" preset's ~7GB peak VRAM eating your entire headroom on an 8GB card — drop to medium before you hit an out-of-memory wall on a real scene instead of the demo room.

The Deployment Layer Is Fragmented by Design

Nobody planned this fragmentation — it's what happens when three different platforms each decide not to own the problem. Unity converged on a single de facto standard, Aras Pranckevičius's open-source UnityGaussianSplatting, precisely because Unity never shipped first-party splat support at all. The vacuum opened early, one library filled it, and by Unity 6 LTS it's good for roughly 60fps on mid-range GPUs as long as the scene stays under about a million Gaussians — which, worth flagging again, is a budget an XGRIDS scanner blows through in seconds of capture at 320-640k points/sec.

Unreal took the opposite path. There's still no Epic-native splat module as of UE 5.7, so production teams are choosing between Luma AI's official plugin, Akiya Research's UE5 plugin, XGRIDS' own LCC SDK, and Volinga — four competing import paths with no convergence pressure forcing a winner. In practice the choice is usually decided upstream: whichever vendor's capture pipeline you already committed to is the plugin you use, since XGRIDS pushes its own SDK and Luma pushes its own plugin. That's a real maintenance cost every UE version bump gets to reintroduce.

The web split cleanly by use case rather than by vendor lock-in. PlayCanvas SuperSplat is the open-source editor for post-capture cleanup and publishing — you bring a scan, fix it, put it online. World Labs' Spark, now with Spark 2.0's progressive LOD streaming, is built for loading large generated scenes without a full download first. They're not fighting over the same job.

Path	First-party support	Dominant tool	Primary use case
Unity	None — community filled the gap	UnityGaussianSplatting (open-source)	General splat rendering, ~60fps under 1M Gaussians
Unreal	None through UE 5.7	Fragmented: Luma plugin, Akiya Research, XGRIDS LCC SDK, Volinga	Vendor-tied import, tied to capture pipeline choice
Web	N/A (browser-native via three.js/WebGL)	PlayCanvas SuperSplat vs. World Labs Spark	SuperSplat: editing/publishing. Spark: large-scene streaming

The thing that could actually collapse this fragmentation is KHR_gaussian_splatting, the glTF extension Khronos announced February 3, 2026, defining position, rotation, scale, color, and opacity per-Gaussian as a native glTF primitive. If it lands, any glTF-compliant engine loads splats without a vendor plugin, which is exactly the kind of thing that erodes the value of XGRIDS' LCC SDK or Luma's Unreal plugin over time. But it's still in release-candidate/feedback phase, targeting Q2 2026 ratification, and I found nothing confirming that ratification actually happened. Anyone building an export pipeline against it right now is targeting a spec that can still change shape under them.

The Mesh-First Floor: fal.ai, Tripo, and the Commodity Squeeze

This layer looks like it belongs next to Marble and XGRIDS because it sits next to them in a pipeline diagram — generate an object here, drop it into a world-scale scene there — but it's a structurally different problem: single mesh-first objects, not world-scale splats, and it's the most commoditized of the five categories by a wide margin.

fal.ai's play is aggregation, not competition: TripoSR at roughly $0.07 a generation, Trellis, Hyper3D/Rodin, and Tripo's own models, all metered on one bill. Going direct to Tripo instead gets you their full current lineup — V3.0/V3.1 for image- and multiview-to-3D, a dedicated V3.0 texture service, H3.1 for text-to-3D, and P1.0, which Tripo positions as a production-grade native 3D diffusion model generating engine-ready topology. The tradeoff is the one you'd expect from any aggregator: fal.ai buys you model-shopping flexibility and unified billing, direct access buys you the vendor's newest model sooner and deeper platform-specific tooling.

Within the category, the differentiation is real but narrow. Tripo wins on fast, clean-topology drafts and 3D-printing pipeline integration. Meshy wins on stylized game-asset output and has the most mature engine plugin ecosystem, down to one-click Bambu Studio slicer export. Hyper3D/Rodin wins on geometric fidelity and 4K PBR texturing, positioning itself explicitly as the high-detail option against Tripo's speed.

What I'd actually plan around is that every generator in this class ships the same two defects. Lighting gets baked directly into the albedo texture — shadows painted into the diffuse map that then look wrong the moment you drop the asset under different in-engine lighting — and automatic UV unwrapping produces uneven texel density, crowding some islands and starving others. Neither fixes itself; both get fixed in Blender, by a person, every time. Trellis adds its own failure mode on top of that: reported structural-plausibility breaks, an extra-leg artifact on text-to-3D output being the specific one on record, which is why it reads as closer to a research project than a shipped tool even while fal.ai hosts it next to more production-ready options like Rodin Gen-2.5. None of this makes the category unusable — it means a manual Blender pass is a standing stage in the pipeline, not a contingency you budget for occasionally.

Where the Stack Actually Breaks in Production

Every failure mode in this stack traces back to the same root cause: a splat is a cloud of alpha-blended ellipsoids with baked color, not a surface. There's no topology to build physics on, so nothing does. In Unreal specifically, Lumen doesn't touch a Gaussian splat at all — 3DGS renders as a screen-space effect that sits outside the global illumination system entirely, shadow proxies fall back to voxelized approximations that lose fine detail, and reflection probes misbehave whenever the reflection ray's view direction falls outside the hemisphere the spherical-harmonic color term was actually fit to interpolate. None of this is a bug to patch. It's the format working as designed, which means every object a player or user needs to touch, stand on, or bump into needs a second, hand-built collision mesh maintained alongside the visual splat indefinitely — exactly the parallel-asset maintenance burden splats were supposed to eliminate.

Editing carries the same tax. Because the representation is soft and view-dependent rather than a manifold surface, anything past deleting a region is research-grade work, and generated geometry can look completely convincing from a demo camera path while containing self-intersections or wrong-scale elements that only surface once something has to physically interact with it. Dynamic content is further behind than the marketing suggests: static 3DGS can't represent motion at all, and 4D-GS variants only replay pre-captured or pre-generated motion sequences — they don't simulate new physics or respond to a novel interaction. Splats stay backdrop; characters, ragdolls, and anything destructible stay mesh-based, and the two need a rendering seam.

The budget math is unforgiving in a way that's easy to underestimate. Uncompressed, a splat runs about 248 bytes per Gaussian, and real scenes land between 50MB and 1.5GB, loaded as one giant GPU buffer that has to share VRAM with the tiled sort-and-rasterize working set on top of it. Compression buys 5-12x with a real cost — visible artifacting, "JPG artifacts in space" — and even after that, mobile-class hardware still isn't real-time: published benchmarks put an Orin NX at 2-9 FPS. An XGRIDS scanner capturing at 320,000-640,000 points a second blows past Unity's roughly one-million-Gaussian, 60fps ceiling within seconds of scanning, so raw capture never ships as-is — it gets decimated and compressed first, and that step is exactly what reintroduces the popping and sorting artifacts that don't show up as errors, only as something QA has to catch by eye.

The XGRIDS operator rules are the sharpest example of a failure that hides until it's expensive. Never idle the scanner in front of glass or mirrors, keep moving at 0.5 m/s or faster, and — the one that actually bites — loop closure fails silently if the return viewing angle at a revisited location differs from the original pass by more than 40°. SLAM drift accumulates uncorrected past that threshold, and nothing in the live capture flags it. The scan looks fine, decimates fine, imports fine, passes visual QA fine. It only fails the moment someone stitches it against a second pass or a BIM reference, at which point it isn't a fix, it's a re-scan.

stateDiagram-v2
    [*] --> RawCapture
    RawCapture: Raw Capture (XGRIDS scan)
    RawCapture --> Decimation: return angle within 40°
    RawCapture --> DriftAccumulated: loop-closure return angle > 40°
    DriftAccumulated: SLAM drift accumulates, undetected
    DriftAccumulated --> Decimation: scan proceeds normally, drift invisible
    Decimation: Decimation / Compression
    Decimation --> EngineImport
    EngineImport: Engine Import (+ hand-authored collision mesh)
    EngineImport --> VisualQA
    VisualQA: Visual QA (check popping/sorting artifacts by eye)
    VisualQA --> Decimation: artifacts found, re-tune compression
    VisualQA --> Shipped: clean
    Shipped --> DriftDiscovered: stitched against second pass or BIM reference
    DriftAccumulated --> DriftDiscovered: stitched against second pass or BIM reference
    DriftDiscovered: Drift discovered — scan doesn't register
    DriftDiscovered --> RawCapture: re-scan required

What I'd Build on This Stack Today

The most useful thing to build right now isn't a demo of any single tool — it's a pipeline that forces two or three of these pieces to cover each other's gaps. The clearest version of that is a WebXR interaction layer driven by Splat Analyzer: capture a space with a phone through Polycam or with an XGRIDS scanner if you need the accuracy, run Splat Analyzer against the resulting splat to get an interactions.json full of flagged objects, hand-author a real collision mesh for whatever it flags, and load the composite into SuperSplat or Spark with clickable zones wired to the detected boxes. The part worth actually building carefully is the review step in the middle — treat every box in that JSON as a first draft, not ground truth, because OWLv2's documented false-positive rate and its occlusion confusion carry straight through the pipeline and get worse on a cluttered or partially-occluded room than on the clean single-object demo case everyone shows.

A second project worth a quarter's worth of time is a hybrid Marble-backdrop, mesh-foreground scene, which is the only pattern in this whole stack with actual production precedent. Generate the environment through Marble's World API, export the mesh form for collision, and populate it with foreground objects generated separately through Tripo or another fal.ai-hosted model, then composite the two in Unity via UnityGaussianSplatting or Unreal via whichever third-party plugin matches your capture vendor. Two things will bite you if you skip them: don't route people, pets, or hero characters through Marble — it's scoped to environments, quality degrades with distance from the seed image, and it'll hand back something quietly mediocre rather than erroring — and budget a manual Blender pass on whatever comes out of Tripo or Rodin for the baked-in lighting and uneven UV density every generator in that category ships with.

The third is less glamorous and probably more useful to an actual team: a capture-method decision guide, built as a short internal tool or even just a scored checklist, that routes a given job to phone-based capture, XGRIDS-class hardware, or DJI Terra aerial capture based on required accuracy, budget, and site conditions. Feed it the RMS accuracy requirement, whether the site has glass-heavy areas or long featureless corridors, and the budget, and have it output a recommended capture path plus an operator checklist. The judgment call to encode explicitly: don't spec hardware-grade LiDAR for work that doesn't need centimeter-certified, georeferenced accuracy, since that's the exact segment phone apps have already eaten — but for anything that does need it, the guide should insist on operator training for glass surfaces and loop-closure technique as a line item, not an afterthought, because that's the failure that doesn't show up until it's a re-scan.

Resources

• How to Build with 3DGS Across World Labs, Web, Unity & Unreal · Zoom · Luma
• Generating Bigger and Better Worlds | World Labs
• 301 Moved Permanently