Anyone who has scanned the same space twice knows the problem. You capture a room in September and again in November. The walls are identical; the furniture moved, the plants grew, someone painted a door. Reconstruct them separately and you have two unrelated models. Reconstruct them together and the changed parts turn into smeared artefacts, because the solver is trying to satisfy contradictory observations.
ChronoFuseGS, posted 25 September 2026, handles this properly. The authors are Tobias Batik, Diana Marin, Peter Kán and Hannes Kaufmann.
What it does
The approach takes multiple separately trained Gaussian Splatting models — each representing a distinct timestep, and partially overlapping in geographic coverage — and merges them into a single combined model.
The key move: Gaussians from one timestep are allowed to contribute to the reconstruction at other timesteps. So the parts of the scene that didn’t change get refined using data from every capture, rather than only the one they came from.
And it encodes, for each Gaussian primitive, at which timesteps it exists. That per-splat persistence record is what makes the rest possible.
It also supports incremental extension — new timesteps can be added while preserving the existing merged reconstruction, rather than retraining from scratch.
Why per-splat persistence is the good idea
Tagging each primitive with its temporal existence gives you three things at once, which is unusually economical:
Better geometry for free. A wall observed across four captures has four times the data. Nothing about the wall changed, so all of it is valid evidence, and the merged model is sharper than any single capture could be.
Change detection falls out of the representation. You don’t need a separate diffing algorithm. A Gaussian that exists at timestep 1 and not at timestep 3 is a change. The model’s own structure answers “what’s different” — hence the change visualisation in the title.
Time becomes a parameter you can render. With persistence per primitive, you can render the scene as it was at any captured timestep from the merged model, rather than keeping and switching between separate reconstructions.
What this is actually for
The paper’s framing is reconstruction, but the applications are concrete and mostly not artistic:
- Construction and site monitoring — what changed on site this week
- Heritage and conservation — documenting deterioration across years
- Facilities and inspection — spotting what moved or failed
For creative and installation work the interesting uses are different:
A space as a record of its own use. Scan a gallery weekly through an exhibition and you have a model that encodes what moved — which is a portrait of how people used the room, derived from geometry rather than from cameras watching them. That’s a genuinely appealing property for anyone uneasy about surveillance-based audience data.
Rendering time as a dimension. Being able to fade between captures, or render only the persistent skeleton of a place, or show only what’s ephemeral, is a compositional possibility rather than a technical one.
Incremental capture. Not having to rebuild when you add a session makes long-term scanning projects practical. That’s the difference between a one-off scan and an ongoing practice.
The honest caveat: this is a research paper, not a tool. There’s no Nerfstudio flag or ComfyUI node for it. The transferable idea — that persistence should be a property of the primitive, not of the model — is worth carrying into how you think about temporal capture regardless.
Related Reading
- ChronoFuseGS: Multi-Temporal Gaussian Fusion with Per-Splat Persistence and Change Visualization — arXiv:2609.31339
- 3D Gaussian Splatting for Real-Time Radiance Field Rendering — Inria
- φ-RIE: From Photorealistic Reconstruction to Interactive Environments — arXiv:2609.26795
- Nerfstudio
- arXiv cs.GR — Graphics listings