3D Gaussian Splatting in Godot: Beyond Viewer Demos

For the past two years, 3D Gaussian Splatting (3DGS) has been one of the most significant shifts in 3D reconstruction. Its strength is easy to see: 3DGS can capture complex reflective materials, specular highlights, and difficult lighting behavior that traditional methods often struggle with (for a deeper dive, see our guide on ).

But for game developers, the real question was never just whether splats could look good in isolation.

The more practical question has always been: can 3DGS actually work inside an engine scene?

• Can it sit next to standard meshes in the scene tree?

• Can a CharacterBody3D move behind it correctly?

• Can it participate in the engine’s depth pipeline, instead of behaving like a disconnected viewer layer?

A slide from KIRI Engine’s GDC 2024 presentation on the use of 3D Gaussian Splatting in games, reflecting the growing interest in scan-based assets for real-time workflows.

That is why what is happening in the Godot ecosystem right now feels important. The conversation is no longer just about rendering splats. It is increasingly about whether splats can fit into a usable, real-time toolchain. KIRI Engine also touched on this direction at GDC 2024, including how 3DGS can start to make sense inside real game workflows.

Rendering Is Only the First Step

For most Godot developers, visual fidelity alone is not enough.

Godot is a key part of the conversation as 3DGS moves from rendering demos toward real scene integration.

A splat may look impressive in a demo, but that does not automatically make it useful in production. The real friction appears as soon as you try to place it into an actual scene:

• Does it blend correctly with other scene elements?

• Can it read and write to the native depth buffer?

• Can standard mesh-based characters and props coexist with it naturally?

• Can it behave like part of the engine instead of a separate rendering trick?

This is why scene-depth compositing matters so much. If a scanned 3DGS asset cannot correctly occlude or be occluded by other elements in the world, its usefulness in gameplay-heavy scenes becomes much more limited.

In other words, the challenge is not just rendering. It is scene integration. True engine integration means a 3DGS asset should be importable, exist as a normal node in the scene tree, and interact spatially with traditional polygonal content in a predictable way.

Two Open-Source Directions in Godot

The Godot community is actively exploring this problem, and two distinct approaches help illustrate where 3DGS integrations are heading.

1. The Compute-Based Prototype / Technical Viewer

Projects like 2Retr0/GodotGaussianSplatting were important because they proved something early: Gaussian splats could be rendered in Godot.

That alone mattered. It moved 3DGS in Godot from theory into something graphics programmers could study and experiment with directly. This kind of project is especially useful for understanding the lower-level rendering side of splats, including forward-pass logic, compute-driven rasterization, sorting, and the use of Godot’s RenderingDevice.

But as the creator itself suggests, this type of implementation is still closer to a technical viewer than a complete scene pipeline. It demonstrates feasibility, but it does not fully solve the broader question of how splats should behave as native assets inside a real project.

It answers: Can this run in Godot? It does not fully answer: Can this behave like a real scene asset?

2. The Compositor Plugin / Scene Integration Approach

A different direction is represented by projects like ReconWorldLab’s gdgs plugin.

Here, the focus shifts away from "can we display splats?" and toward "can splats fit the engine more naturally?" Built as a Godot 4 add-on, this approach uses the CompositorEffect architecture to treat Gaussian rendering as part of the engine’s compositing process rather than as an isolated visual pass.

That distinction matters because depth interaction is one of the main things that makes splats more usable in actual game scenes. Once a splat can participate correctly in scene compositing, it starts to feel less like a standalone viewer and more like part of the world.

The addition of a GaussianSplatNode also changes the pipeline in practical ways. It allows developers to manipulate splats using familiar editor tools. Support for engine-oriented formats such as .compressed.ply and .sog, plus import-side fixes like Z-axis correction, determine whether an integration process feels robust or fragile.

Why This Matters Beyond Rendering

Once engine-side rendering and compositing begin to improve, the pressure naturally shifts upstream.

The problem is no longer only how to reconstruct reality convincingly. It becomes: how cleanly can that result be handed off into a real-time engine?

A Godot editor view of integrated 3DGS compositing, illustrating how scan output becomes more valuable when it is aligned, engine-ready, and easier to hand off into real-time production workflows.

From a capture perspective, that changes the definition of good output. A scan is no longer valuable only because it looks impressive to the viewer. It also needs to arrive in a format that is aligned, standardized, and usable inside real production tools.

This is where the broader industry direction matters. Just as formats like glTF helped standardize asset handoff for real-time 3D, engine-side 3DGS implementations will likely depend on cleaner expectations around packaging, orientation, compression, and interoperability.

For capture platforms like KIRI Engine, that means the job is not only to reconstruct reality well. It is also to deliver output that reduces friction at the engine-import stage.

The Hybrid Pipeline Is the Real Near-Term Future

It is important to stay realistic about what 3DGS can and cannot do.

Gaussian splats do not provide topology in the way meshes do. That means they cannot natively support many systems that still depend on polygonal structure, such as:

• Skeletal animation

• Dynamic deformation

• Clean raycast collision

• Standard physics interactions

So no, 3DGS is not replacing mesh-centric pipelines any time soon. What feels much more realistic is a hybrid pipeline:

• Splats for dense, photoreal visual context.

• Meshes for interaction, animation, and gameplay-critical structure.

• Proxy meshes / collision shapes for physics, navigation, and rigid-body behavior.

This is likely the most practical way forward for real-time projects. For smaller independent teams in particular, that is a powerful idea. Imagine building a 2D side-scrolling survival game: developers can use scanned 3DGS environments to carry the heavy visual density of a grim, photorealistic background, while relying on conventional invisible colliders and 2D physics for the actual side-scrolling gameplay interactions.

At GDC 2024, KIRI Engine demonstrated 3D Gaussian Splatting running inside a game engine, showing how splats can move beyond standalone viewing and into practical real-time use.

That is where 3DGS starts to feel less like a novelty and more like a serious production tool: not as a replacement for meshes, but as a strong complement to them.

The Capture Side: Engine-Ready Data Matters More

As plugins and engine integrations improve, capture pipelines also need to become more engine-aware.

If a Godot plugin expects structured, compressed, engine-friendly splat data, then scanning tools need to think beyond "high-fidelity reconstruction" and toward engine-ready formatting. That includes questions like:

• Is the output aligned correctly for engine coordinates?

• Is the format easy to ingest without custom preprocessing?

• Is the data compact enough for practical project sizes?

This is why deciding between is no longer just a reconstruction-quality debate. It is also an integration debate. In many cases, the "better" output is not simply the one that looks best in a viewer. It is the one that moves most cleanly into real production use.

(Tip: To ensure your scans are optimized for real-time environments, check out our ).

Our Takeaway

What makes 3DGS in Godot exciting is not simply that splats can now be rendered.

It is that the ecosystem is starting to move beyond isolated viewer demos and toward actual scene integration. Once splats can sit more naturally in the scene tree, participate in depth correctly, and import without excessive manual cleanup, they become much more relevant to real development cycles.

That still does not replace meshes. Meshes will continue to carry physics, animation, and gameplay structure for the foreseeable future. But it does make hybrid real-time pipelines feel much more practical than they did even a year ago.

A real-world capture example from KIRI Engine, reflecting how scan quality now depends not only on reconstruction fidelity, but also on how cleanly output can move into practical engine workflows.

For platforms like KIRI Engine, that shift matters. The priority is no longer only reconstruction quality in isolation, but also delivering clean, engine-friendly outputs that fit into the tools people actually build with.

FAQ

Can Godot render 3D Gaussian splats?

Yes. Open-source Godot projects can already render Gaussian splats using approaches such as compute-driven rasterization and compositor-based integration.

What is the difference between a 3DGS viewer and a Godot 3DGS plugin?

A viewer mainly proves that splats can be rendered in isolation. A plugin aims to make them part of an actual engine environment, including scene placement, editor interaction, and depth-aware compositing with standard meshes.

Can Gaussian splats have physics collisions in Godot?

Not directly. Because splats do not provide usable mesh topology, developers typically rely on invisible proxy meshes or standard collision shapes for physics and gameplay interactions.

Why does engine integration matter for scanning tools like the KIRI Engine?

Because it changes what “good output” means. The goal is no longer only accurate reconstruction, but also clean handoff into real-time DCC and engine ecosystems.