Gaussian splatting missed glTF's Q2 deadline: where engines stand now
If you've been asking whether you can drop a Gaussian splat scene into a standard glTF pipeline yet, the answer is no. Khronos's KHR_gaussian_splatting extension is still sitting at release-candidate status, more than five weeks past the Q2 2026 window the working group itself set for ratification. Every engine that supports splats today does it through its own incompatible format instead: Godot leans on a community plugin's `.ply` importer, Unity leans on a different open-source package's `.ply` importer, and Unreal Engine 5.7 leans on two separate third-party plugins. None of them read the actual Khronos extension, because it doesn't exist as a finished spec yet.
Khronos announced the release candidate on February 3, 2026, with Nvidia, Google, Adobe, and Cesium named as backers reviewing the spec. The 3D Formats Working Group set Q2 2026 (April–June) as its ratification target. Q2 ended June 30. It's now August 10, and KHR_gaussian_splatting is still open for community feedback — no ratified spec, no version bump, no merge into the core glTF 2.0 registry.
What actually shipped while ratification stalled
Game engines didn't wait around for Khronos. Three separate, mutually incompatible splat pipelines shipped in the gap.
Godot's most-used option is ReconWorldLab's GDGS plugin (`godot-gaussian-splatting`), now at v3.3.0. Version 3.1.0 added editor-side collision: select a GaussianSplatNode, generate a StaticBody3D from the splat data, one node at a time — not automatic, but real. A later release added a second rendering path, a Raster backend that draws splats through Godot's normal pipeline instead of a compute shader. That unlocks the Mobile and Compatibility renderers, MSAA, VR/multiview, and hardware depth-tested occlusion, at meaningfully lower VRAM than the original Compute backend.
Unity's most-used option is a different project entirely: UnityGaussianSplatting, built by Aras Pranckevičius, a former Unity engineer. It's open-source, imports `.ply` directly, and GPU-sorts splats at runtime. Unity Technologies ships nothing first-party.
Unreal Engine 5.7 has no Epic-built Gaussian Splatting module at all. The two paths developers actually use are Luma AI's free, documented UE plugin and Polycam's GS export pipeline — both third-party, both tied to their own capture apps.
The one implementation actually tracking the Khronos extension itself, rather than a proprietary interim format, is Cesium: CesiumJS and Cesium for Unreal added KHR_gaussian_splatting support ahead of ratification. That's a geospatial and digital-twin stack, not a general game-dev one.
| Engine | What's actually used | Built by | Reads KHR_gaussian_splatting |
|---|---|---|---|
| Godot 4.5/4.6 | GDGS v3.3.0 (.ply, Compute + Raster) | ReconWorldLab (community) | No |
| Unity 6.x | UnityGaussianSplatting (.ply) | Aras Pranckevičius (community) | No |
| Unreal Engine 5.7 | Luma AI plugin / Polycam GS export | Luma AI / Polycam (3rd party) | No |
| CesiumJS / Cesium for UE | Native KHR_gaussian_splatting | Cesium | Yes |
The realistic performance ceiling across the community plugins is around 60 fps for scenes under 1 million Gaussians, on RTX 3060- or RX 6600-class hardware. That's the number to plan around if a splat scene is going into a shipping build instead of a tech demo.
Why splats still won't replace your prop and character pipeline
None of this makes splats a drop-in replacement for textured mesh assets, and the gaps are structural — not a version number away from closing.
Splats can't be skeletally animated. A Gaussian splat is a static capture — positions, orientations, scale, color via spherical harmonics, and opacity, frozen at the moment of capture. There's no bone hierarchy to drive, so a splatted character can't walk, attack, or react. Anything that needs animation still needs a rigged mesh.
Collision is manual and per-object, not automatic. Godot's GDGS gives you a StaticBody3D generator, but it runs node by node — it isn't the free collision you get importing a modeled prop with its collision mesh already baked in.
The format built on today probably isn't the format shipping on later. Every pipeline above uses its own `.ply`-based convention, and none of these tools has committed to a migration path toward KHR_gaussian_splatting once it actually ratifies. A splat scene built against GDGS or UnityGaussianSplatting today is a bet on that specific plugin staying maintained, not a bet on an open standard.
None of that shows up in interactive props, characters, or weapons — anything a player touches, picks up, or fights is still textured-mesh territory. Elven Ranger is a useful comparison: fully rigged, UV-mapped, collision-ready on import — the opposite of a splat's static point cloud. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships — see pricing.
Where splats make sense right now is environment backdrops and capture-based set dressing — the stuff a player looks at but never touches, the same use case Cesium is building toward with real-world geospatial capture. For anything a player interacts with, run the mesh through 3D Studio first and check the actual triangle count and UVs before deciding it needs to be a splat at all — most interactive props don't.
If a pipeline already leans on glTF 2.1's scene composition (covered in what changed) or renders GLB scenes through Three.js's WebGPURenderer (see what r185 broke), Gaussian splatting sits alongside that stack right now, not inside it — not until Khronos ships a spec beyond release-candidate.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*