Solv3R

Abstract

Classical structure-from-motion reconstruction proceeds iteratively, refining camera poses and scene geometry from a current estimate. This allows maps to easily expand without recomputing already computed views, or geometry estimates to improve as more observations are provided. Most geometric foundation models, however, predict entire geometry in a single forward pass or update a recurrent state as frames arrive sequentially, making this expansion and refinement non-trivial. We introduce Solv3R, a looped transformer that learns to continue solving multi-view geometry from its current state. Importantly, its update operator is independent of the iteration count, allowing previously refined and newly introduced views to be jointly updated regardless of how “solved” they are. We train the operator to preserve accurate reconstructions under continued iteration and correct inaccurate states, enabling refinement of fixed image collections and integration of new observations. Representations of solved views can also be cached once and reused as geometric context across iterations, enabling compact and efficient key-value caching. We analyze the solver dynamics and compare it with the state-of-the-art, demonstrating that a single learned solver supports offline reconstruction, incremental reconstruction, relocalization, and streaming without task-specific training or modules.

TL;DR Solv3R turns a looped transformer into a learned multi-view solver—the same solver logic across diverse reconstruction settings.

One solver for every setting

One model. One block. One solve.

Solv3R block

Offlineall photos at once

Streaminga video, frame by frame

Arbitrary orderphotos join in a random order

Keep solving, whatever arrives next

A geometric foundation model makes one prediction for a fixed set of photos. Solv3R keeps solving. The panels below play by themselves and show what this changes.

Any order, no matter.

One solver, whether views arrive all at once, in batches, or in any order.

We turn a looped Transformer into a multi-view solver

The same learned update, regardless of when views arrive or how far they have been refined. Decoding the states gives each view's camera and depth at any call. The update does not depend on the call index, so new views can join while the others are being solved.

photos

Solv3R block

view states

decoded 3D

The method figure of the paper

Left: the stationary update, a single Transformer block with frame attention, global attention and state normalization, applied in a loop to the view states, starting from the encoded initial state. Right: view states go from initial to refined over calls, new views join at any stage and in any order, and decoding gives cameras, depth maps and ray maps of the solved scene.

What was solved. Stays solved.

Solv3R stays accurate beyond its training horizon and stops when its state stabilizes. DéjàView degrades beyond its fixed schedule.

ETH3D, DTU, ScanNet++ and Tanks and Temples windows, the protocol of the paper's stability analysis.

New photos also correct the old ones

New views join the ongoing solve and improve earlier camera estimates. DéjàView fails to jointly refine new and previously solved views.

Solved first

Join at call 8

DéjàView

Solv3R

camera colouraccurateofffirst photosnew photos

New views can join at any call

New observations can improve earlier estimates, even after the initial solve has stabilized.

Initial views, median rotation error

with new views–

solved alone–

call–

Loading 3D…

One frame out at every call (pipelining)

Because the update does not depend on the step, one call can refine frames at different stages. A video can then flow through a fixed window. Each call adds the newest frame and releases the oldest one, which has had its 16 calls. A step-conditioned solver keeps all frames at the same step, so it solves the window again for every new frame. Solv3R thus releases a frame at every call, 16× throughput at the same latency.

One cache for every call

With KV caching, solved views can stay fixed as reusable context. Layer-wise models need one cache per layer, and DéjàView one per step. Solv3R reuses the same cache at every call.

Results

Paper Table 1: offline camera pose and geometry benchmarks across DTU, ETH3D, 7-Scenes, ScanNet++, and nuScenes. — Table 1. Offline reconstruction.

Acknowledgements

We thank Zan Gojcic, Haithem Turki, and Dmytro Mishkin for their valuable feedback on the paper.

BibTeX

@article{solv3r2026,
  title   = {Solv3R: 3D Looped Transformer as a Multi-view Solver},
  author  = {Kwak, Jeong-gi and Tagliasacchi, Andrea and Kagami, Sho and Ono, Yuki and Yi, Kwang Moo},
  journal = {arXiv preprint},
  year    = {2026}
}

Solv3R : 3D Looped Transformer as a Multi-view Solver