Gaussian splatting tips into mainstream as nearly every major engine adds a plugin

Gaussian splatting has one big thing going for it: it makes photo-real 3D feel less like a Pixar budget and more like a production pipeline. Scan a real space, run a reconstruction and “splat training,” then render a scene built from millions of tiny, semitransparent 3D Gaussians. According to scan artist Christoph Schindelar, who has been doing Gaussian splatting since at least 2024, the tech now has a practical escape hatch from the usual photoreal bottlenecks, because it is far less resource-intensive than many alternatives and can achieve fast playback.

And here is the part that should matter to anyone making engine choices or staffing decisions: Schindelar says Gaussian splatting is “implemented in nearly every major engine (standalone or via plugin).” That means the moment for the technique is not just in the lab. The implementation is already close to where teams actually build games, which is why Schindelar is explicitly watching independent studios and creators move first. “What is especially exciting to me at this point in time is that GS opens doors for independent creators,” he says, adding that “small studios are not” slow about new tech the way the “big budget game industry” can be.

So what is Gaussian splatting, in plain English? Schindelar describes it as “a modern capture-and-rendering method that turns photos or video into a real-time 3D representation.” It is similar to photogrammetry, but it avoids some of photogrammetry’s heavier resource demands by not building the scene from polygons. Instead, the scene becomes a swarm: millions of small “splats,” each with a 3D position, size, orientation, and opacity. Those splats also include view-dependent behavior via “spherical harmonics.” When rendered, the approach projects each splat into an elliptical footprint on screen. The result is a photo-real look that can be created and viewed efficiently because the GPU is largely projecting and blending splats rather than streaming high-quality textures.

For production leadership, the payoff is less about graphics “coolness” and more about throughput. Schindelar says playback can be very fast because the GPU “mostly has only to project and blend these splats.” He also frames this as an accessible route to photorealistic presentation for smaller projects. That matters because most teams do not fail on ambition. They fail on time, cost, and pipeline complexity: scanning overhead, texture workloads, and the compute needed to deliver something stable at scale. Gaussian splatting shifts that balance. It moves the heavy lift earlier into capture and training, and it keeps runtime closer to projection and blending.

But pipelines still come with constraints, and Schindelar gets specific about where the pain lives. Capture comes first. For “high-end work, [where] color fidelity, dynamic range and overall image quality are crucial,” he spends “several hours snapping images” using either a DSLR camera or a camera-RIG solution. He cites an example where he scanned and processed an abandoned former lead and goods factory, including “the entire interior and exterior,” within two weeks using “a single Sony A7R4.” Resolution requirements vary by environment, capture distance, field of view, desired detail, and the use case. Crucially, Schindelar cautions that “more megapixels is always better” is not universally true. It is about having enough visual information from the right viewpoints.

He also explains why planning the geography of your shoot matters. With lower resolution you may need more pictures to cover details, but larger scenes usually require more high-res coverage so visuals do not break quickly. In a forest example, he says he typically uses high-resolution cameras because he does not want visuals to collapse at the first line of trees, since that would force “walk all the way to get every tree with close-up captures.” The data set sizes can vary massively. Schindelar mentions reaching raw capture datasets close to 1.5 TB in “high-end projects,” while “in many practical cases” raw data is in the “double-digit gigabyte range” for indie-friendly production.

Then comes reconstruction and training. Post-processing can take between one and three days, but Schindelar’s emphasis is on the reconstruction pipeline. Starting from captured reference images, often with pre-aligned camera positions and a sparse point cloud estimated through structure from motion (photogrammetry), the Gaussian Splatting optimization process adjusts splats until rendered views match the original photos. He describes the training as “splat training,” where a chaotic cloud converges into a coherent representation and becomes the final result. This is also where hardware decisions get real. “GPU power matters, of course,” Schindelar says, but in production “VRAM is the thing you always want more.” He uses an RTX 5090 for splat training on most projects, but he also points out that good results can be achieved with relatively lightweight laptops. Cloud options exist too, including Varjo Teleport (which mentions elastic GPU clusters), KIRI Engine (app/cloud processing), and XGRIDS (cloud-based processing).

Finally, there is the part executives can measure without squinting: output size. After reconstruction, training and export, GS scenes are usually much smaller than the raw capture dataset. Schindelar says exported data often lands in the range of a few gigabytes, often “around 2 to 4 GB,” and he notes a continuous scene with about 130 million splats and roughly 16 GB uncompressed. He also gives a concrete compression win: “We pushed a church scene from about 1 GB down to only 55 MB without significant visible losses.” He highlights a PlayCanvas demo using “Self-Organizing Gaussians” compression, and the demos he cites are part of the broader pattern: once the toolchain is present in engines and the output is manageable, more teams can experiment.

This is why the strategic stakes are higher than “cool rendering.” If Schindelar is right that GS is already implemented across nearly every major engine, the advantage shifts from novelty to execution: who can turn capture into training into reliable exports fast enough for real production schedules. Boards and investors should also notice what is implied here about adoption incentives. Schindelar frames the big-budget industry as slow to implement new technologies, while small studios push forward with experiments. When the gatekeeping moves from “engine support” to “pipeline maturity,” it rewards teams with capture workflows, data management, and VRAM-aware compute budgets, not just shader talent.