Any3R: Feedforward 3D Reconstruction from Any Camera Type

Introduction

Recovering the 3D structure of a scene from a set of images is a fundamental problem in computer vision. Geometry foundation models such as VGGT [57], $\pi$ [61], MapAnything [25], VGGT-$\Omega$ [58] and Depth Anything 3 [34] now solve it with a feed-forward network [4, 13, 29, 56, 59, 60, 65, 74]. A regular camera sees only a narrow part of a scene in each view, so covering a whole room or street takes many views captured densely and carefully.

The direct way to cover more of a scene per view is a wider lens, and wide-angle and panoramic cameras are already common in autonomous driving [33, 72] and indoor scanning [1, 5]. Feed-forward models cannot use such images as they are, because they read every frame as a pinhole image. Recent work adapts them to particular lenses, with a discrete token for the camera model, an adapter around a frozen backbone, a pairwise alignment stage, a conversion of the input to a cubemap, or retraining on equirectangular images [3, 12, 18, 19, 22, 31], but each supports only a fixed list of camera models, so an unseen camera needs retraining or a new conversion step. Mixing cameras of different types in one reconstruction, such as a pinhole view, a fisheye frame and a panorama of one scene as in Figure 1, is harder still. Wid3R [22] and Fisheye3R [12] mix only the camera types they support, CAM3R [19] reconstructs two views at a time and aligns them afterwards, and the panoramic models accept panoramas alone. MapAnything [25] and OmniVGGT [39] take the intrinsics of each view as input and could mix cameras in principle, but a pinhole intrinsic matrix cannot describe a field of view of 180° or more, the range of many fisheye lenses and every panorama.

Both limits trace back to the backbone’s positional encoding, which none of these methods changes: it locates each patch by its pixel index [49]. On a pinhole camera, the index tells the backbone roughly where the patch looks; on a fisheye, each pixel covers a wider angle, so the same index points somewhere else (Figure 2(ii)). The training loss has a similar problem: it weights every pixel equally, but a fisheye pixel near the edge sees a different amount of the scene than one at the center (Figure 2(i)).

We present Any3R, which removes the pinhole assumption by giving the ray direction of every pixel to both the encoding and the loss (Figure 2(iii)). In pinhole, fisheye and panoramic cameras, all rays pass through one point. Such central cameras are fully described by the ray direction of each pixel, whatever the lens. Angular coordinates position a patch by the angle of its ray instead of its index, so one unit of position means the same angle on every camera. Solid-angle weighting scales the loss by how much of the scene each pixel sees, so every part of the scene counts equally whatever the lens. Because each view carries its own ray field, Any3R reconstructs from any central camera without rectification, and views from different cameras can be processed together, in any number. On three public datasets imaged through thirteen camera models, where every method reconstructs with its own predicted camera poses, Any3R gives the most accurate reconstruction and camera poses on wide-angle and panoramic lenses and is

on par with the strongest pinhole baseline at 90°. It also outperforms the methods built for wide-angle or panoramic lenses on every lens they take, and its pose estimates on real pinhole photographs are competitive with the strongest pinhole baselines. Its margin over the pinhole models is smallest at 90° and much larger on the wider lenses.

Our contributions are threefold:

• A feed-forward model that reconstructs from views of any mix of central cameras, with no calibration search, no undistortion and no retraining per lens.

• Angular coordinates and solid-angle weighting, two modules that condition the positional encoding and the training loss on the dense ray field, so that one set of weights serves every central camera.

• State-of-the-art reconstruction and camera pose on three public datasets imaged through thirteen central camera models, where every method reconstructs with its own predicted camera poses, with the largest margins on wide-angle and panoramic lenses.

Related Work

3D Geometry Foundation Models

Classical structure-from-motion recovers geometry by optimising correspondences and poses jointly [43], and per-scene neural representations [26, 37] keep that optimisation while changing what is optimised. DUSt3R [60] instead trained one network to regress a pointmap in a common frame, removing the optimisation loop and the need for known intrinsics, and MASt3R [29] added a matching head to the same backbone [11, 38, 62, 63].

Extending two views to many has taken several forms: a global stage on top of the pairwise backbone [4, 13], a latent state that lets views be streamed [56, 59], and set-level attention that fuses hundreds at once [65]. VGGT [57] predicts poses, depth, pointmaps and tracks together, $\pi$ [61] removes the dependence on a reference view, VGGT-$\Omega$ [58] scales the recipe, and MonST3R [74] adapts it to moving scenes. Depth Anything 3 [34] reaches the same outputs from the monocular depth line [2, 24, 40, 66, 67, 71], and the same shift has occurred in SLAM [53] and in feed-forward radiance fields [6, 7, 20, 47, 68, 76]. MapAnything [25] and OmniVGGT [39] add optional conditioning on intrinsics, extrinsics or depth, which is the closest prior setting to ours. All of them assume pinhole input: the focal length may vary, the projection model may not.

3D Reconstruction for Different Camera Types

A central camera is described by its ray field, parameterised compactly for rectilinear, fisheye and catadioptric optics [16, 23, 36, 42, 48, 54, 78]. Learning pipelines instead rectify the image to a rectilinear grid, which is lossy at wide field of view and impossible past 180°, so work on panoramic and fisheye input changes the operator instead: spherical convolutions [9, 10, 15, 50, 52], resampled charts [8, 14], monocular panoramic depth [21, 32, 41, 44, 51, 55, 73, 80] and multi-view fisheye depth [27, 28, 33, 64, 72]. Each fixes one projection, so a change of lens is a change of model.

Recent feed-forward methods attach the camera at the backbone’s periphery, by retraining on one projection [18, 31], a token [22], an adapter [12], pairwise alignment [19] or a cubemap [3], or train on renderings through many lenses [30], but keep the pinhole meaning of a rotary coordinate [49] inside the attention, which is what a change of lens alters. RayTun3R [45] reaches the same diagnosis but adapts per sequence at test time. G-ray [77] parameterises the rotary phase by camera-local ray angles and evaluates it on pinhole and fisheye crops, while we mix eight central camera models from 90° to 360°. OmniPoint [69] encodes the ray field of the same three projection families from a single image, without relative pose or cross-view attention. Ray and Plücker coordinates have also served as geometric position [46, 75]. Reusing a pretrained rotary encoding adds a requirement that a freshly trained one lacks: wherever the pretrained coordinate already agrees with the ray angle, it must be reproduced exactly, or a valid prior is lost.

Method

Preliminary

The input is a set of $S$ views $V=\{(I_s,C_s)\}_{s=1}^{S}$, where $I_s\in\mathbb{R}^{H\times W\times3}$ is an image, $C_s$ its calibration and each view may come from a different camera model, and a feed-forward network predicts the camera-to-world pose $T_s\in SE(3)$ of every view and a point for every pixel. A camera is central when all its rays pass through one point, so it is described completely by the map $\mathcal{R}:\mathcal{D}\to\mathbb{S}^2$ that sends each pixel $u=(u,v)$ of the image domain $\mathcal{D}$ to the unit direction of its ray, expressed in the camera frame with $x$ to the right, $y$ down and $z$ along the optical axis. We take this map, sampled at the pixel centres, as the camera,

where the ray field $R$ holds the unit ray $R_u=\mathcal{R}(u)$ of every pixel and $M_u=1$ marks the pixels at which $\mathcal{R}$ is defined, so views of different cameras share one grid. The network sees no lens type and no distortion coefficient, only $R$, which is computed once from the calibration and, as a sample of a differentiable map, has derivatives. The dense head predicts one distance $d_u$ per pixel, read along the pixel’s ray,

so one decoder serves every camera, including rays at 90° or more from the optical axis.

Any3R is trained to read the ray field of each view (Figure 3). Of the panoramic training samples, half are native panoramas and half are views synthesised by resampling a panorama through a randomly drawn camera, sampled uniformly over eight central models, pinhole, Brown–Conrady, equidistant, Kannala–Brandt, MEI, double sphere, equirectangular and cropped equirectangular, with field of view in $[30^\circ, 360^\circ]$ and rectilinear models capped below the $180^\circ$ asymptote. A fresh camera is drawn per view, so one sample routinely mixes a narrow rectilinear crop with a wide fisheye and a full sphere, and the view count $S$ is drawn from $\{2,\ldots,8\}$. The objective is the pretrained backbone’s own, with camera, depth and point terms as in [57], every term masked by $M$, the point weight replaced by the solid-angle weight below and no auxiliary loss.

The backbone is a vision transformer with alternating intra- and inter-frame attention [57] over a grid of $H_p \times W_p$ patches, and we write $m = \max(H_p,W_p)$. Two of its parts rely on the pixel grid, the rotary positional encoding and the per-pixel training loss, and Any3R gives $\mathbf{R}$ to both, as Figure 3 shows.

Angular Coordinates

The backbone’s rotary encoding [49] locates a patch by its index (Figure 2(ii)), and Any3R locates it by the angles of its ray instead, the angular coordinates at the top left of Figure 3. The patch in row $i \in\{0,\ldots,H_p-1\}$ and column $j \in\{0,\ldots,W_p-1\}$ receives the normalised indices

and the query and key of that patch are rotated by the angles $\omega_k c_{ij}^{\mathrm{lat}}$ and $\omega_k c_{ij}^{\mathrm{lon}}$, each in its own channel pair, with frequencies $\omega_k = 2\pi\cdot100^{-k/16}$ for $k = 0,\ldots,15$. On a pinhole the index tells roughly where the patch looks, but on a wider lens the same index points elsewhere. We take the coordinates from the ray field instead. Let $\bar{\mathbf{r}}_{ij} = (\bar{r}_x,\bar{r}_y,\bar{r}_z) \in\mathbb{S}^2$ be the mean ray of the patch, obtained by averaging $\mathbf{R}$ over its pixels and renormalising, with elevation $\theta_{ij} = \arcsin(-\bar{r}_y) \in[-\frac{\pi}{2},\frac{\pi}{2}]$ and azimuth $\phi_{ij} = \operatorname{atan2}(\bar{r}_x,\bar{r}_z) \in(-\pi,\pi]$. The coordinates are

and every other component of the attention is unchanged. One unit of coordinate then stands for the same angle on every camera, so the frequencies $\omega_k$, which all views share, mean the same angle in every view of a mixed batch.

The prefactors $H_p/m$ and $W_p/m$ are the unique choice under which Eq. (4) reproduces Eq. (3) on an equirectangular grid, the input on which patch index and ray angle agree, since substituting its patch-centre angles $\theta_i = \frac{\pi}{2} - \frac{\pi(i+0.5)}{H_p}$ and $\phi_j = \frac{2\pi(j+0.5)}{W_p} - \pi$ returns Eq. (3) term by term, so the pretrained encoding is kept on panoramas. Eq. (4) is evaluated with $\mathbf{R}_s$ for each view $s$, so every view of a batch is encoded with its own lens rather than with that of the first view. The released model applies Eq. (4) to the eight lowest frequencies, $k \ge8$, and for the other eight divides by the half extents $\hat{\theta} = \frac{H_p}{H_p-1}\max_{ij}|\theta_{ij}|$ and $\hat{\phi} = \frac{W_p}{W_p-1}\max_{ij}|\phi_{ij}|$ of the view instead of by $\frac{\pi}{2}$ and $\pi$, so that these coordinates span each camera’s own field of view, as Eq. (3) does. On an equirectangular grid $\hat{\theta} = \frac{\pi}{2}$ and $\hat{\phi} = \pi$, so exactness holds for the split as well, and because the encoder averages the rays of a patch rather than taking its centre, the coordinates of our $518 \times1036$ panoramas differ from Eq. (3) by at most $4.3\%$ of a patch step. The backbone also adds $\alpha(\mathbf{f}_{ij})$ to the token of patch $(i,j)$ before every attention block, with $g$ an MLP, $\alpha$ a learned scalar and $\mathbf{f}_{ij} = [-\sin\theta,\cos\theta,\sin\phi,\cos\phi]$ evaluated at the equirectangular angles of the patch grid. We keep $g$ and $\alpha$ and evaluate $\mathbf{f}_{ij}$ at the angles of $\bar{\mathbf{r}}_{ij}$, so the absolute position of every token also follows its ray (Figure 3).

Solid-Angle Weighting

A pixel also covers a different part of the scene on every lens (Figure 2(i)), as the solid-angle band at the bottom of Figure 3 shows on the panorama. The backbone’s point loss compares the predicted point $\mathbf{X}_u \in\mathbb{R}^3$ of each pixel, in the camera frame of its view, with the ground truth $\mathbf{X}^{\mathrm{gt}}_u$ and weights each pixel by its radial distance alone,

with the sums over the pixels of all views and $\lambda$ the scale, one per sample, that best aligns the prediction with the ground truth under the same weights, since the backbone predicts geometry up to scale. We also weight each pixel by the solid angle it covers, so the loss integrates over the sphere rather than over the pixel grid of each lens (Figure 3). In view $s$ this is the area on $\mathbb{S}^2$ onto which $\mathbf{R}_s$ maps the pixel, the norm of the cross product of its partial derivatives, so it needs no camera model and no extra input,

and normalising by $\langle\mathrm{d}\Omega\rangle_M$, the mean over the valid pixels of the same view, puts $\tilde{w}$ and $w$ on one scale, so the magnitude of (5) and with it the learning-rate schedule are unchanged and only the distribution of supervision moves. Derivatives are finite differences of $R$, central inside the image and one-sided at its border, the weight carries no gradient, and before normalising we clamp $\mathrm{d}\Omega$ to the 1st and 99th percentiles of the valid pixels in the batch.

Experiments

Setup

We train Any3R for 40 epochs on 32 GH200 GPUs over about 27 hours, on Matterport3D [5], Stanford2D3DS [1], Structured3D [79], PanoCity and DL3DV [35] videos, holding out all test scenes. We evaluate on two indoor datasets, Matterport3D and Stanford2D3DS, and one outdoor dataset, PanoCity, with 24 held-out scenes per dataset and 3 views per scene. Every scene is rendered through 13 central camera models, the eight used in training and five held out, from the same panoramas and view directions, so two results differ by the lens alone, and Tabs. 1 and 3 report the eight.

Every method fuses its views into one point cloud with its own predicted camera poses, and we measure both the

cloud and the poses. Accuracy (Acc) is the mean distance from a reconstructed point to its nearest ground-truth point after the similarity alignment and ICP refinement of the PanoVGGT evaluation [18], the point-cloud accuracy used across feed-forward reconstruction [59, 61]. Pose accuracy is the area under the curve (AUC) of the pairwise pose error, the angle of the relative rotation error and the translation-direction error, up to 15° and 30°, as in [57, 61]. Any3R receives the ray map, MapAnything a pinhole intrinsic matrix on the pinhole cameras, Wid3R the true ray field and the other methods images alone, and MapA-ray is MapAnything given the true ray field on every camera.

Comparison with the State of the Art

Camera-aware methods. Tab. 1 compares Any3R with the methods built for other cameras on the same scenes and views, and each of them covers part of the table. Wid3R represents each camera by one of a few classes, which hold only the pinhole, equidistant, MEI and equirectangular cameras exactly and none of the 200° lenses, and it receives the ray field only after the transformer, where it can correct the decoded points but neither the attention nor the poses. OmniVGGT conditions on a pinhole field of view below 180°, which cannot describe these lenses, so it runs on images alone and reads them through VGGT’s in- @references♀♀♀♀♀♀ dex encoding. PanoVGGT and Argus are built for panoramas, and off the panorama PanoVGGT reads every frame as one while Argus cannot run. MapAnything accepts a dense ray map, and MapA-ray gives it the true one on every camera, but the map is added to the image features after a pinhole encoder has read the frame on its pixel grid, and its accuracy stays close to that of MapAnything without it in Table 3. On every camera and dataset that each of these methods can take, Any3R is more accurate and better posed in all three measures, including the equirectangular frame of the panoramic models, where our coordinates coincide with the stock encoding, so the other lenses were added without taking anything from it. In the typical scenes of Figure 4, whose Acc for Any3R lies between the quartiles of its cell, PanoVGGT bends a pinhole frame into a bowl and MapA-ray still folds the equirectangular room despite the true ray field, while Any3R returns the room on every lens. Beyond these comparisons, Any3R is one general model, and the same weights fill every column of Table 1, where each method built for one family of lenses covers a subset.

Method	Pin. 90°	B–C 90°	Equi. 180°	ERP-C 180°	MEI 180°	KB4 200°	DS 200°	ERP 360°	Pin. 90°	B–C 90°	Equi. 180°	ERP-C 180°	MEI 180°	KB4 200°	DS 200°	ERP 360°
Acc↓ ($m$)
OmniV [39]	0.250	0.201	0.326	0.318	0.329	0.355	0.350	0.406	2.875	2.676	3.313	2.804	3.703	3.941	3.670	1.479
Wid3R [22]	0.144	–	0.141	–	0.146	–	–	0.101	2.278	–	2.121	–	2.252	–	–	2.330
PanoV [18]	0.282	0.272	0.259	0.348	0.265	0.251	0.265	0.072	2.256	2.708	2.498	3.633	2.433	2.405	2.473	0.751
Argus [31]	–	–	–	–	–	–	–	0.094	–	–	–	–	–	–	–	1.517
MapA-ray [25]	0.092	0.146	0.277	0.254	0.239	0.274	0.258	0.405	1.484	1.558	2.368	2.686	2.029	2.523	2.579	1.894
Any3R	0.076	0.091	0.058	0.052	0.059	0.056	0.060	0.054	1.160	1.243	0.866	0.811	0.854	0.863	0.901	0.663
AUC@15° ↑ (%)
OmniV [39]	6.3	1.8	1.9	12.1	0.6	0.9	2.9	0.7	1.9	0.7	3.7	8.5	3.2	3.1	5.4	4.2
Wid3R [22]	46.4	–	59.4	–	59.5	–	–	85.3	8.1	–	25.5	–	22.9	–	–	0.0
PanoV [18]	2.2	2.5	21.7	21.5	23.6	36.2	46.9	89.2	10.8	10.1	37.5	42.0	38.1	51.0	58.6	93.5
Argus [31]	–	–	–	–	–	–	–	88.4	–	–	–	–	–	–	–	81.9
MapA-ray [25]	53.6	31.2	10.4	6.5	15.5	12.4	12.0	4.1	56.3	45.0	17.5	10.0	27.8	15.1	20.0	2.1
Any3R	74.8	64.8	90.6	86.0	90.5	81.2	80.5	94.5	61.5	51.0	85.0	87.4	85.2	79.5	81.0	97.2
AUC@30° ↑ (%)
OmniV [39]	13.9	5.4	6.6	26.2	5.4	4.8	7.0	4.1	9.6	4.8	9.0	19.3	9.3	10.2	13.2	6.1
Wid3R [22]	67.0	–	76.4	–	76.4	–	–	89.0	22.8	–	47.9	–	42.6	–	–	0.0
PanoV [18]	10.1	11.8	50.1	42.6	52.2	63.5	69.7	93.2	25.2	25.9	61.0	62.7	62.0	73.9	78.2	96.8
Argus [31]	–	–	–	–	–	–	–	91.3	–	–	–	–	–	–	–	90.5
MapA-ray [25]	72.8	55.5	25.5	19.7	34.9	30.2	32.8	14.1	74.7	61.6	33.3	23.1	49.4	31.9	39.4	6.3
Any3R	85.0	78.3	93.9	91.6	94.6	89.6	88.5	96.6	80.7	74.2	92.5	93.7	92.6	89.4	90.5	98.6

Method	Indoor Pin. 90°	Indoor B–C 90°	Indoor Equi. 180°	Indoor ERP-C 180°	Indoor MEI 180°	Indoor KB4 200°	Indoor DS 200°	Indoor ERP 360°	Outdoor Pin. 90°	Outdoor B–C 90°	Outdoor Equi. 180°	Outdoor ERP-C 180°	Outdoor MEI 180°	Outdoor KB4 200°	Outdoor DS 200°	Outdoor ERP 360°
Acc↓ ($m$)
$\pi^3$ [61]	0.084	0.119	0.171	0.287	0.164	0.189	0.183	0.414	1.479	1.711	2.093	2.426	2.036	2.394	2.271	1.628
MapA [25]	0.092	0.149	0.273	0.269	0.267	0.283	0.294	0.386	1.485	1.633	2.066	2.861	2.236	3.297	2.789	1.833
DA3 [34]	0.313	0.294	0.361	0.288	0.363	0.396	0.379	0.402	4.360	5.689	6.656	2.717	6.844	6.463	6.477	3.149
VGGT [57]	0.270	0.282	0.361	0.274	0.379	0.356	0.374	0.398	4.153	3.940	6.296	3.078	6.886	6.623	6.430	1.902
V-Ω [58]	0.149	0.161	0.252	0.265	0.250	0.281	0.302	0.403	1.711	1.572	2.162	2.455	2.490	2.680	2.544	1.876
Any3R*	0.282	0.283	0.274	0.278	0.278	0.279	0.298	0.054	2.079	2.525	2.370	3.324	2.463	2.420	2.552	0.663
Any3R	0.076	0.091	0.058	0.052	0.059	0.056	0.060	0.054	1.160	1.243	0.866	0.811	0.854	0.863	0.901	0.663
AUC@15° ↑ (%)
$\pi^3$ [61]	76.9	53.5	42.1	18.0	43.1	35.2	34.6	3.5	44.6	34.0	18.8	15.9	20.0	14.4	16.0	2.3
MapA [25]	53.6	28.5	13.2	9.0	10.8	8.8	8.4	6.4	56.5	20.6	19.6	10.6	17.1	16.9	13.8	0.1
DA3 [34]	7.8	2.7	0.9	22.1	1.2	0.4	0.7	7.0	4.8	3.0	6.4	7.7	4.9	3.4	4.6	5.5
VGGT [57]	23.3	9.9	5.2	14.2	5.3	5.0	2.9	3.3	15.1	2.6	3.7	9.5	6.5	5.5	7.3	0.9
V-Ω [58]	63.5	50.4	31.3	15.0	29.6	24.0	19.5	6.9	45.5	44.4	15.8	8.1	15.6	13.8	8.8	3.9
Any3R*	24.0	43.8	48.3	41.7	48.2	55.0	58.5	94.5	20.1	36.0	45.0	29.9	47.3	48.8	50.1	97.2
Any3R	74.8	64.8	90.6	86.0	90.5	81.2	80.5	94.5	61.5	51.0	85.0	87.4	85.2	79.5	81.0	97.2
AUC@30° ↑ (%)
$\pi^3$ [61]	82.7	66.0	61.9	37.1	62.7	56.4	58.9	14.1	61.7	47.1	36.1	28.3	37.3	30.0	35.0	4.8
MapA [25]	72.8	52.3	31.3	23.2	29.6	27.6	24.8	16.2	74.8	36.1	41.9	25.0	39.7	34.2	30.1	3.1
DA3 [34]	17.8	10.3	5.7	46.2	7.2	5.5	5.1	16.8	13.6	11.5	14.8	22.1	10.2	9.8	10.6	11.3
VGGT [57]	50.0	25.6	18.8	32.2	16.6	16.4	13.9	10.6	32.8	11.0	8.8	24.3	13.9	13.2	17.3	3.5
V-Ω [58]	76.9	69.7	53.8	34.6	52.3	47.1	42.0	17.8	55.3	54.7	33.8	23.6	34.8	31.4	24.4	8.5
Any3R*	47.5	66.2	71.3	65.8	72.0	75.9	77.5	96.6	38.9	58.3	67.7	53.7	69.6	72.3	72.2	98.6
Any3R	85.0	78.3	93.9	91.6	94.6	89.6	88.5	96.6	80.7	74.2	92.5	93.7	92.6	89.4	90.5	98.6

Geometry foundation models.

Table 3 compares Any3R with $\pi^3$, MapAnything, DA3, VGGT and V-GT-$\Omega$, which are built for pinhole images, so the 90° columns are their home ground and the place where a model that serves every lens would pay for its generality. Any3R does not pay there, and it is more accurate and better posed than every one of them on every camera, indoors and outdoors, except for the AUC at 15° on the indoor pinhole, where $\pi^3$ leads because it is ahead on Stanford2D3DS. Away from that ground their pose collapses, with an AUC at 30° below a fifth at 360°, and indoors each of them is least accurate at 360°, whereas Any3R is more accurate on every wider lens than at 90°. A pinhole model can infer where a patch looks only from its index, through the tangent mapping of the images it was trained on, so it reads a wider lens as a pinhole and places the rays that look sideways only backwards inside its frustum, whereas a wider lens only gives our angular coordinates more of the room to place. In the typical scenes of Figure 6, from 180° on they place the parts of a frame that look sideways or backwards in front of the camera, flattening the room or folding it into a shell, and VGGT and DA3 often lose the relative pose as well. Any3R^*, our model without its ray map, assumes an equirectangular grid and reads every frame as a panorama, and its error rises sharply on every lens but the equirectangular one, where that assumption holds and the two rows coincide, so the gain comes from the ray map; in Figure 6 it bends a pinhole frame into a bowl.

Zero-Shot Real Lenses

The cameras above are rendered from panoramas, so Table 2 also tests real lenses on two datasets that are not in our training data, under the same protocol. ScanNet++ [70] records each scene with a DSLR fisheye of about 146°, and we take one view triplet from each scene of its validation split, with ground truth from the laser-scanned mesh. FIORD [17] records with a 200° fisheye whose image reaches beyond 90° from its axis, and we take 24 view triplets from two of its scenes, with ground truth from a terrestrial laser scan. Any3R, MapA-ray and Wid3R receive the ray field of the calibrated lens. On FIORD, Any3R is the most accurate and the best posed of the methods compared, with an AUC at 30° about half again that of the next one, and Wid3R cannot represent the lens. On ScanNet++, Any3R is second only to Wid3R and ahead of every other method in all three measures. Without its ray map, Any3R* falls far behind on both datasets, so on real lenses as well the gain comes from the ray map. In Figure 5, the other zero-shot methods bend the FIORD rooms into curved shells, while Any3R stays close to the ground truth.

Method	ScanNet++ Acc↓	ScanNet++ @15↑	ScanNet++ @30↑	FIORD Acc↓	FIORD @15↑	FIORD @30↑
OmniV [39]	0.097	18.6	41.5	0.363	18.6	40.3
Wid3R† [22]	0.039	85.3	92.6	–	–	–
PanoV [18]	0.277	1.8	9.7	0.511	29.4	51.2
MapA-ray [25]	0.093	18.5	43.6	0.396	19.4	36.5
$\pi^3$ [61]	0.086	20.6	46.6	0.378	15.7	36.7
MapA [25]	0.099	19.3	40.2	0.399	17.7	37.2
DA3 [34]	0.118	17.2	41.5	0.380	9.1	25.8
VGGT [57]	0.118	18.0	41.7	0.442	15.6	35.3
V-$\Omega$ [58]	0.112	16.7	42.9	0.451	19.9	38.9
Any3R*	0.273	7.5	22.9	0.480	28.3	47.5
Any3R	0.055	62.7	79.7	0.274	63.8	78.4

Ablation

The angular coordinates, the absolute pathway and radial decoding read the same ray field and cannot be switched off one at a time, so Any3R* in Table 3, without the ray map, is their joint ablation, and Table 4 isolates the two remaining choices on full panoramic sequences under the PanoVGGT protocol. Per-view evaluation concerns what the angular coordinates read in a sample whose views come from different cameras. With it, the coordinates of each view are computed from that view’s own ray field, and without it, from the ray field of the first view, which all views of the sample then share. Every test view of Table 4 is a panorama, so the two inputs give identical coordinates there, and the difference between the rows was learned in training, where the shared field assigns every view but the first the angles of a lens it was not taken with and the network learns to relate views through wrong angles. Reading each view’s own field gives the largest pose gain on the indoor datasets, and on PanoCity it lowers the median rotation error but also the AUC. On its own, solid-angle weighting gives a smaller gain by counting each direction of the scene once instead of each pixel. The pose gains cost some depth accuracy, most of it with per-view evaluation, which raises the mean $\log_{10}$ depth error on Matterport3D from 0.033 to 0.045. We accept this trade for the larger gain in pose.

Component			M3D		S2D3DS		PanoCity
Per-Ang.	Solid-view	ang.	AUC↑	$\overline{R}_{\mathrm{med}}$ ↓	AUC↑	$\overline{R}_{\mathrm{med}}$ ↓	AUC↑	$\overline{R}_{\mathrm{med}}$ ↓
–	–	✓*	0.619	4.61	0.636	4.18	0.854	0.77
✓	–	–	0.364	9.26	0.381	8.94	0.653	1.88
✓	–	✓	0.380	8.25	0.395	8.50	0.686	1.72
✓	✓	–	0.488	6.36	0.527	6.44	0.633	1.41
✓	✓	✓	0.492	7.13	0.528	6.90	0.669	1.41

Conclusion

Geometry foundation models typically assume pinhole cameras, an assumption embedded in their positional encoding and training objectives. Any3R conditions

Acknowledgments

This work was supported by the U.S. National Science Foundation under Grant No. 2316400. This work was also supported by the Wallenberg AI, Autonomous Systems and Software Program (WASP) funded by the Knut and Alice Wallenberg Foundation. The computations and data handling were enabled by the Arrhenius HPC resource provided by National Academic Infrastructure for Supercomputing in Sweden. The authors also acknowledge the South Dakota State University High Performance Computing (SDSU HPC) team for providing access to and support for the university’s high-performance computing resources.

Evaluation Details

Each of the 24 scenes of a dataset is a set of three views drawn without replacement, whose view directions are fixed by a pre-registered rule on the $90^\circ$ pinhole and reused for every camera. The thirteen camera models are the eight used in training and five held out from it, FOV/ATAN at $150^\circ$, stereographic at $180^\circ$, equisolid and EUCM at $200^\circ$ and cylindrical at $360^\circ$. Structured3D is evaluated in the same way on all 16 of its test scenes and reported only in this supplement, since the views of a scene share no content and relative pose cannot be recovered there.

Each method’s per-view points are placed with its own predicted poses and fused, and 40,000 pixels are sampled per scene. The evaluation function of PanoVGGT then fits one similarity transform on the pixel correspondences between the predicted and the ground-truth points, refines it by point-to-point ICP with a maximum correspondence distance of 0.1 m indoors and 1.0 m on PanoCity, and reports Acc, the mean distance from a reconstructed point to its nearest ground-truth point, and a cell’s value is the mean over its scenes. The AUC follows the authors’ pose evaluation, taking for every pair of views the larger of the relative rotation error and the translation-direction error, in $1\sigma$ bins, and dropping pairs whose ground-truth translation is below 0.01. Baselines with two input options, $\pi^3$, VGGT and VGGT-$\Omega$ at their native or their official resolution and MapAnything with or without the pinhole intrinsics, are shown with the option of lower median Acc in each cell, and Table 17 lists both. MapAnything accepts a dense ray map, but its released preprocessing fits a pinhole intrinsic matrix to any ray map before cropping, so MapA-ray takes the images through that preprocessing and then receives, for every processed pixel, the true ray of the camera, which enters its ray encoder unchanged.

Table 17. Both inputs of the two-input baselines. Median per-scene $\operatorname{Acc}\downarrow$ (m) for the native and the official input of $\pi^3$, VGGT and VGGT-$\Omega$ and for MapAnything without and with pinhole intrinsics; every other table uses the bold one.

Camera	Matterport3D $\pi^3$ nat.	Matterport3D $\pi^3$ off.	Matterport3D VGGT nat.	Matterport3D VGGT off.	Matterport3D V-$\Omega$ nat.	Matterport3D V-$\Omega$ off.	Matterport3D MapA $-K$	Matterport3D MapA $+K$	Stanford2D3DS $\pi^3$ nat.	Stanford2D3DS $\pi^3$ off.	Stanford2D3DS VGGT nat.	Stanford2D3DS VGGT off.	Stanford2D3DS V-$\Omega$ nat.	Stanford2D3DS V-$\Omega$ off.	Stanford2D3DS MapA $-K$	Stanford2D3DS MapA $+K$
Pinhole (90°)	0.050	0.041	0.279	0.252	0.128	0.101	0.125	0.069	0.045	0.041	0.291	0.239	0.118	0.087	0.119	0.062
Brown–C. (90°)	0.080	0.072	0.295	0.274	0.175	0.126	0.151	–	0.071	0.068	0.338	0.247	0.177	0.122	0.121	–
FOV/ATAN (150°)	0.119	0.127	0.286	0.279	0.155	0.158	0.221	–	0.115	0.108	0.352	0.333	0.206	0.211	0.236	–
Equidist. (180°)	0.161	0.139	0.347	0.313	0.211	0.195	0.265	–	0.141	0.141	0.415	0.383	0.257	0.265	0.296	–
Stereogr. (180°)	0.121	0.118	0.332	0.333	0.249	0.245	0.272	–	0.131	0.152	0.406	0.397	0.295	0.304	0.296	–
ERP-Cr. (180°)	0.243	0.249	0.243	0.245	0.239	0.250	0.212	–	0.282	0.268	0.265	0.251	0.245	0.274	0.268	–
MEI (180°)	0.150	0.139	0.353	0.332	0.201	0.216	0.249	–	0.130	0.134	0.376	0.389	0.263	0.258	0.268	–
KB4 (200°)	0.180	0.146	0.351	0.339	0.231	0.240	0.239	–	0.150	0.151	0.389	0.366	0.317	0.323	0.287	–
Equisolid (200°)	0.218	0.187	0.335	0.336	0.231	0.262	0.221	–	0.178	0.163	0.370	0.353	0.294	0.327	0.272	–
Double-Sph. (200°)	0.151	0.144	0.353	0.331	0.256	0.268	0.266	–	0.146	0.153	0.386	0.397	0.334	0.335	0.323	–
EUCM (200°)	0.159	0.148	0.346	0.335	0.265	0.265	0.271	–	0.149	0.156	0.381	0.389	0.325	0.314	0.309	–
ERP (360°)	0.387	0.374	0.348	0.352	0.351	0.376	0.347	–	0.405	0.382	0.388	0.413	0.392	0.401	0.428	–
Cylind. (360°)	0.342	0.274	0.302	0.337	0.361	0.347	0.310	–	0.356	0.370	0.374	0.400	0.360	0.370	0.334	–
Camera	Structured3D $\pi^3$ nat.	Structured3D $\pi^3$ off.	Structured3D VGGT nat.	Structured3D VGGT off.	Structured3D V-$\Omega$ nat.	Structured3D V-$\Omega$ off.	Structured3D MapA $-K$	Structured3D MapA $+K$	PanoCity $\pi^3$ nat.	PanoCity $\pi^3$ off.	PanoCity VGGT nat.	PanoCity VGGT off.	PanoCity V-$\Omega$ nat.	PanoCity V-$\Omega$ off.	PanoCity MapA $-K$	PanoCity MapA $+K$
Pinhole (90°)	0.476	0.595	0.485	0.575	0.380	0.531	0.410	0.522	1.053	1.078	4.222	3.724	1.553	1.344	1.532	1.161
Brown–C. (90°)	0.419	0.341	0.469	0.532	0.484	0.515	0.469	–	1.339	1.319	3.782	3.976	2.054	1.321	1.477	–
FOV/ATAN (150°)	0.496	0.516	0.562	0.468	0.489	0.496	0.403	–	1.795	1.720	6.213	5.701	1.852	1.927	1.904	–
Equidist. (180°)	0.355	0.358	0.592	0.497	0.484	0.568	0.427	–	2.171	2.000	6.639	5.861	2.184	2.244	2.023	–
Stereogr. (180°)	0.456	0.521	0.451	0.490	0.487	0.479	0.432	–	1.893	1.765	5.925	5.615	2.386	2.190	2.300	–
ERP-Cr. (180°)	0.546	0.581	0.538	0.443	0.522	0.511	0.480	–	2.509	2.641	3.072	3.250	2.773	2.694	3.031	–
MEI (180°)	0.326	0.386	0.584	0.498	0.523	0.561	0.417	–	2.143	1.966	5.992	6.418	2.295	2.277	2.128	–
KB4 (200°)	0.345	0.356	0.492	0.511	0.464	0.469	0.417	–	2.781	2.226	7.146	6.388	2.686	2.708	2.459	–
Equisolid (200°)	0.326	0.334	0.463	0.459	0.433	0.524	0.412	–	2.229	3.054	6.697	6.098	2.984	3.244	2.179	–
Double-Sph. (200°)	0.398	0.409	0.463	0.451	0.449	0.442	0.414	–	2.519	2.141	6.047	6.218	2.387	2.531	2.390	–
EUCM (200°)	0.447	0.402	0.589	0.469	0.509	0.417	0.395	–	2.543	2.138	7.112	6.369	2.450	2.492	2.556	–
ERP (360°)	0.381	0.504	0.383	0.511	0.432	0.453	0.322	–	1.097	0.853	1.046	0.978	1.073	1.105	0.905	–
Cylind. (360°)	0.414	0.449	0.369	0.419	0.423	0.449	0.372	–	3.132	2.011	2.812	2.537	2.063	1.884	1.838	–

The zero-shot samples of Table 2 use the calibrated Kannala–Brandt model of each lens, inverted per pixel, with the images resized to the size of the rendered cameras of similar field of view. On ScanNet++ the views are the DSLR images of every scene of the validation split, the full set with ground truth since the test splits publish no laser scan, posed by its COLMAP reconstruction, which lies in the frame of the laser scan, and the ground truth is the range along each ray to the scanned mesh. On FIORD the views are those of the second lens of the rig, posed by its COLMAP reconstruction brought into the frame of the laser scan by a similarity transform, and the ground truth is the laser cloud $z$-buffered into each view; the scenes are meetingroom and parkenhaus, and upstairs is left out because its reconstruction does not register to its scan. In each scene the second view is the first one after an anchor that differs from it by at least $15^\circ$ or 0.3 m and sees at least 30% of its ground truth, and the third the first such view before the anchor that also overlaps the second, a rule fixed before any method was run. Wid3R receives the lens through its Fisheye624 class, which contains this model, and the rays it consumes are checked per pixel against the calibrated ones. Where this supplement counts a method as best in a cell, a pre-registered one-sided per-scene sign test also separates it from the runner-up at $p < 0.05$.

Further Results on the Eight Camera Models

Table 5 gives the Acc of Table 3 on each dataset separately, together with PanoVGGT and with Structured3D as a fourth dataset. Table 6 gives the median over scenes on which each verdict of Table 5 is decided. Table 7 averages Table 5 over the narrow and over the wide cameras. On Matterport3D, Stanford2D3DS and PanoCity, Any3R is more accurate on the wide cameras than on the narrow ones, while no perspective-native baseline improves towards the wide end. On Structured3D, whose three views share no content, every method is more accurate on the wide cameras, and Any3R gains the most. Structured3D shows what remains when no view can help another. Its views share no content, so no method can relate them and the comparison rests on how each method reads a single view; on the pinhole cell this favours the pinhole models, and DA3, which comes from monocular depth estimation, has the lowest mean error. From $180^\circ$ on Any3R leads every Structured3D cell of Table 5, so its advantage on wide lenses does not depend on relating views but lies already in how a single view is read. Table 10 gives the relative rotation error of each arm shown in Table 5, so every Acc can be read against the poses it was fused with.

Method	Matterport3D 90°	Matterport3D ≥ 180°	Stanford2D3DS 90°	Stanford2D3DS ≥ 180°	Structured3D 90°	Structured3D ≥ 180°	PanoCity 90°	PanoCity ≥ 180°
Any3R (ours)	0.0826	0.0517	0.0838	0.0614	0.7317	0.3449	1.2019	0.8265
$\pi^3$ [61]	0.1132	0.2253	0.0896	0.2439	0.7331	0.5266	1.5954	2.1415
MapAnything [25]	0.1196	0.2634	0.1221	0.3269	0.7226	0.5527	1.5591	2.5135
DA3 [34]	0.2922	0.3557	0.3139	0.3738	0.6907	0.5728	5.0245	5.3842
VGGT-$\Omega$ [58]	0.1501	0.2601	0.1607	0.3243	0.7866	0.6062	1.6416	2.3678
VGGT [57]	0.3042	0.3464	0.2472	0.3678	0.7129	0.5744	4.0461	5.2024
PanoVGGT [18]	0.2709	0.2326	0.2838	0.2540	0.7917	0.4973	2.4818	2.3655

Camera (FoV)	Matterport3D Any3R	Matterport3D $\pi^3$	Matterport3D MapA	Matterport3D DA3	Matterport3D V-$\Omega$	Matterport3D VGGT	Matterport3D PanoV	Stanford2D3DS Any3R	Stanford2D3DS $\pi^3$	Stanford2D3DS MapA	Stanford2D3DS DA3	Stanford2D3DS V-$\Omega$	Stanford2D3DS VGGT	Stanford2D3DS PanoV
Pinhole ($90^\circ$)	3.91	9.84	13.55	56.33	14.94	23.82	35.08	11.00	7.30	23.29	55.28	12.52	23.80	38.99
Brown–C. ($90^\circ$)	11.68	14.92	21.13	68.61	14.31	41.34	26.91	11.08	26.68	38.14	64.58	21.61	51.50	33.58
Equidist. ($180^\circ$)	8.61	12.20	33.63	55.00	18.92	47.20	13.11	4.82	18.93	43.03	67.73	34.08	49.77	18.56
ERP-Cr. ($180^\circ$)	8.40	24.13	36.10	22.10	26.86	30.50	16.66	5.23	33.80	52.67	21.25	35.16	41.16	22.83
MEI ($180^\circ$)	1.47	11.62	33.56	59.84	19.45	47.58	11.31	4.92	18.75	43.39	61.79	35.53	52.14	22.03
KB4 ($200^\circ$)	3.10	14.96	32.54	49.45	20.85	47.60	9.21	6.13	25.88	41.89	50.54	36.78	47.09	15.95
Double-Sph. ($200^\circ$)	9.99	12.77	37.66	55.73	22.79	46.71	8.44	6.11	17.77	44.65	62.40	36.46	47.91	10.83
ERP ($360^\circ$)	1.12	50.34	51.76	56.19	42.46	47.96	1.90	4.88	52.03	59.17	44.77	43.22	54.41	4.90
Camera (FoV)	Structured3D Any3R	Structured3D $\pi^3$	Structured3D MapA	Structured3D DA3	Structured3D V-$\Omega$	Structured3D VGGT	Structured3D PanoV	PanoCity Any3R	PanoCity $\pi^3$	PanoCity MapA	PanoCity DA3	PanoCity V-$\Omega$	PanoCity VGGT	PanoCity PanoV
Pinhole ($90^\circ$)	70.02	64.23	49.02	92.82	45.28	45.78	60.91	6.89	39.65	13.84	51.53	33.01	39.13	35.32
Brown–C. ($90^\circ$)	71.91	59.20	52.76	98.18	45.03	68.74	43.66	8.55	53.79	49.55	61.55	45.35	73.91	39.09
Equidist. ($180^\circ$)	29.54	39.78	41.73	95.54	38.66	101.77	16.84	2.69	34.73	27.59	38.12	33.50	60.06	12.06
ERP-Cr. ($180^\circ$)	36.67	76.71	54.07	47.66	62.22	45.78	49.17	2.61	50.30	39.31	35.63	44.94	43.18	8.17
MEI ($180^\circ$)	28.13	43.08	46.78	86.50	37.23	100.93	18.17	2.75	32.62	26.79	40.40	32.61	48.48	11.83
KB4 ($200^\circ$)	12.72	37.52	49.66	96.91	40.27	115.44	30.47	3.49	37.06	41.86	38.78	39.31	55.71	7.45
Double-Sph. ($200^\circ$)	13.36	38.38	45.52	91.02	41.41	92.37	32.09	3.35	31.10	48.14	45.99	39.76	44.66	6.20
ERP ($360^\circ$)	1.26	60.96	77.63	63.73	74.99	45.36	1.87	0.51	83.70	85.15	55.74	79.83	79.65	1.37

Table 8 feeds three different cameras into one forward pass, view $k$ of each scene through the $k$-th camera listed. With Brown–Conrady, double sphere and the cropped equirectangular frame, Any3R is best on all three datasets. With pinhole, KB4 and the full equirectangular frame, PanoVGGT has the lowest median on all three, Any3R ties it on Matterport3D and Stanford2D3DS, and Any3R is behind on PanoCity. Table 9 lists both inputs of the baselines that have two.

Dataset	Cameras	Any3R	$\pi^3$ [61]	MapA [25]	DA3 [34]	V-$\Omega$ [58]	VGGT [57]	PanoV [18]
Matterport3D	Pinhole + KB4 + ERP	0.108	0.343	0.444	0.357	0.377	0.357	0.114
Matterport3D	Brown–C. + Double-Sph. + ERP-Cr.	0.057	0.278	0.254	0.325	0.268	0.355	0.290
Stanford2D3DS	Pinhole + KB4 + ERP	0.116	0.359	0.374	0.399	0.405	0.433	0.133
Stanford2D3DS	Brown–C. + Double-Sph. + ERP-Cr.	0.064	0.244	0.306	0.358	0.341	0.395	0.329
PanoCity	Pinhole + KB4 + ERP	1.282	1.821	1.438	3.242	1.791	2.538	1.085
PanoCity	Brown–C. + Double-Sph. + ERP-Cr.	1.215	2.568	2.329	4.944	2.543	3.842	3.006

Dataset	Cameras	$\pi^3$ nat.	$\pi^3$ off.	VGGT nat.	VGGT off.	V-$\Omega$ nat.	V-$\Omega$ off.	DA3 fixed canvas	MapA fixed canvas
Matterport3D	Pinhole + KB4 + ERP	0.345	0.328	0.314	0.324	0.354	0.348	0.315	0.351
Matterport3D	Brown–C. + Double-Sph. + ERP-Cr.	0.249	0.256	0.313	0.362	0.244	0.251	0.335	0.251
Stanford2D3DS	Pinhole + KB4 + ERP	0.378	0.357	0.447	0.424	0.401	0.433	0.378	0.379
Stanford2D3DS	Brown–C. + Double-Sph. + ERP-Cr.	0.242	0.243	0.383	0.399	0.300	0.331	0.359	0.346
PanoCity	Pinhole + KB4 + ERP	2.513	1.238	4.019	1.844	1.277	1.109	2.831	3.128
PanoCity	Brown–C. + Double-Sph. + ERP-Cr.	3.004	2.830	3.890	3.329	2.616	2.716	5.053	5.014

Figure 6 in the main text draws a different scene in each row, which shows the range of content the benchmark covers but means that rows cannot be compared with one another. other: a difference between two rows mixes a change of camera with a change of scene. Figure 7 holds the scene fixed and varies only the camera, so the vertical axis isolates field of view. The two figures are produced by the same code path and the same alignment; only the scene assignment differs.

Down each column, the perspective-native methods stay plausible while the lens is narrow and flatten or fold the room once it is not, and VGGT and DA3 lose the relative pose on most rows, whereas Any3R keeps the room on every lens and the panoramic baseline keeps it only on the full equirectangular frame. This is the qualitative form of the split reported in Table 7, which is computed over all 32 cells of Table 5 rather than the single scene shown here.

Camera-Aware Methods per Camera

Table 11, Table 12 and Table 13 give the methods of Table 1 per camera and dataset, the panoramic methods on the equirectangular frame and OmniVGGT on all thirteen cameras with images alone, and Table 14 gives MapAnything with the true ray field beside MapAnything as run in Table 5. On Structured3D, whose views share no content, MapA-ray is more accurate than Any3R on the pinhole and MEI cameras.

Camera	Method	M3D	S2D3DS	S3D	PanoCity
Pinhole 90°	Any3R	0.069	0.083	0.757	1.160
	Wid3R ray fld.	0.150	0.139	0.770	2.278
	Wid3R pred.	0.199	0.183	0.818	2.182
Equidistant 180°	Any3R	0.056	0.061	0.443	0.866
	Wid3R ray fld.	0.111	0.172	0.568	2.121
	Wid3R pred.	0.124	0.184	0.608	2.100
MEI 180°	Any3R	0.054	0.064	0.436	0.854
	Wid3R ray fld.	0.126	0.166	0.597	2.252
	Wid3R pred.	0.138	0.188	0.607	2.274
ERP 360°	Any3R	0.045	0.064	0.128	0.663
	Wid3R ray fld.	0.069	0.133	0.444	2.330
	Wid3R pred.	0.070	0.134	0.448	3.878

Dataset	Any3R	Argus [31]	PanoVGGT [18]	Wid3R [22]
M3D	0.045	0.094	0.077	0.069
S2D3DS	0.064	0.094	0.066	0.133
S3D	0.128	–	0.144	0.444
PanoCity	0.663	1.517	0.751	2.330

Camera	M3D Any3R	M3D Omni.	S2D3DS Any3R	S2D3DS Omni.	S3D Any3R	S3D Omni.	PanoCity Any3R	PanoCity Omni.
Pinhole 90°	0.069	0.263	0.083	0.237	0.757	0.764	1.160	2.875
Brown–C. 90°	0.096	0.225	0.085	0.178	0.706	0.657	1.243	2.676
FOV/ATAN 150°	0.051	0.311	0.053	0.288	0.522	0.723	0.929	2.898
Equidist. 180°	0.056	0.308	0.061	0.343	0.443	0.530	0.866	3.313
Stereogr. 180°	0.060	0.329	0.069	0.340	0.451	0.519	0.917	3.181
ERP-Cr. 180°	0.051	0.302	0.053	0.333	0.428	0.594	0.811	2.804
MEI 180°	0.054	0.311	0.064	0.347	0.436	0.516	0.854	3.703
KB4 200°	0.050	0.338	0.061	0.371	0.294	0.447	0.863	3.941
Equisolid 200°	0.056	0.329	0.055	0.352	0.310	0.506	0.893	3.425
Double-Sph. 200°	0.055	0.339	0.065	0.362	0.340	0.531	0.901	3.670
EUCM 200°	0.054	0.335	0.067	0.357	0.345	0.495	0.896	3.855
ERP 360°	0.045	0.409	0.064	0.403	0.128	0.449	0.663	1.479
Cylind. 360°	0.082	0.373	0.098	0.411	0.275	0.430	1.298	3.021

Camera	M3D Any3R	M3D MapA	M3D MapA-ray	S2D3DS Any3R	S2D3DS MapA	S2D3DS MapA-ray	S3D Any3R	S3D MapA	S3D MapA-ray	PanoCity Any3R	PanoCity MapA	PanoCity MapA-ray
Pinhole 90°	0.069	0.089	0.089	0.083	0.095	0.095	0.757	0.774	0.675	1.160	1.485	1.484
Brown–C. 90°	0.096	0.150	0.142	0.085	0.149	0.149	0.706	0.671	0.706	1.243	1.633	1.558
FOV/ATAN 150°	0.051	0.229	0.262	0.053	0.243	0.270	0.522	0.533	0.548	0.929	1.930	2.201
Equidist. 180°	0.056	0.246	0.271	0.061	0.299	0.282	0.443	0.773	0.496	0.866	2.066	2.368
Stereogr. 180°	0.060	0.269	0.281	0.069	0.295	0.258	0.451	0.549	0.509	0.917	2.383	2.346
ERP-Cr. 180°	0.051	0.242	0.241	0.053	0.296	0.268	0.428	0.555	0.522	0.811	2.861	2.686
MEI 180°	0.054	0.245	0.226	0.064	0.289	0.251	0.436	0.527	0.425	0.854	2.236	2.029
KB4 200°	0.050	0.246	0.256	0.061	0.320	0.292	0.294	0.519	0.500	0.863	3.297	2.523
Equisolid 200°	0.056	0.226	0.255	0.055	0.291	0.281	0.310	0.624	0.495	0.893	2.268	2.525
Double-Sph. 200°	0.055	0.259	0.237	0.065	0.328	0.278	0.340	0.502	0.572	0.901	2.789	2.579
EUCM 200°	0.054	0.261	0.259	0.067	0.331	0.279	0.345	0.544	0.507	0.896	2.690	2.640
ERP 360°	0.045	0.342	0.350	0.064	0.430	0.460	0.128	0.440	0.404	0.663	1.833	1.894
Cylind. 360°	0.082	0.312	0.294	0.098	0.367	0.410	0.275	0.421	0.446	1.298	2.680	3.001

Table 11 keeps four of the thirteen cameras, pinhole, equidistant, MEI and equirectangular, whose mapping into Wid3R’s camera classes is exact, and omits the other nine. Wid3R’s Fisheye624 class and its EUCM class both pin $z > 0$, so neither represents a frame reaching past 90° from the axis, which rules out the four 200° lenses, and the radial polynomial of its Brown–Conrady class is not invertible outside the inscribed circle. For the field-of-view, stereographic, cropped equirectangular and cylindrical models we have no exact mapping into its classes. We report the cells it can express and name the ones it cannot rather than scoring it on a frame its parameterisation truncates or approximates. Every kept cell’s parameter mapping is checked against our own ray field before use, per pixel and not per lens label, with both the median and the 99th percentile of the angular difference required to pass.

Wid3R trains at 518×336 while our frames are native-resolution, so we run it at both sizes, and Table 11 shows the one with the lower median Acc in each cell, the training size in 19 of the 32 pairs of cell and ray-field mode.

Per-Cell Accuracy on All Thirteen Cameras

The five cameras marked † were added because the original eight leave two axes confounded. Equisolid and stereographic pair with Kannala–Brandt and equidistant at the same field of view, which isolates the radial mapping from the angular extent and gives Table 18 its pairs. Cylindrical covers 360° horizontally like equirectangular but maps elevation through a tangent, which separates panoramic extent from the equirectangular grid itself. Figure 8 draws how each of the thirteen models projects, as a section through the camera centre and as the ray field it gives on the sphere.

Table 18. Two radial mappings at the same field of view. $\operatorname{Acc}\downarrow$ (m) of two camera pairs covering the same solid angle (KB4 and Equisolid at $200^\circ$, Equidistant and Stereographic at $180^\circ$), with the $\bar{R}_{\mathrm{med}}$ (degrees) of the same arms below, so a change of Acc can be read against its change of pose.

	Matterport3D KB4	Matterport3D Eqs.	Matterport3D Eqd.	Matterport3D Str.	Stanford2D3DS KB4	Stanford2D3DS Eqs.	Stanford2D3DS Eqd.	Stanford2D3DS Str.	Structured3D KB4	Structured3D Eqs.	Structured3D Eqd.	Structured3D Str.	PanoCity KB4	PanoCity Eqs.	PanoCity Eqd.	PanoCity Str.
Method
$\operatorname{Acc}\downarrow$ (m)
Any3R	0.050	0.056	0.056	0.060	0.061	0.055	0.061	0.069	0.294	0.310	0.443	0.451	0.863	0.893	0.866	0.917
DA3 [34]	0.388	0.382	0.360	0.349	0.404	0.364	0.363	0.384	0.563	0.519	0.539	0.613	6.463	6.336	6.656	6.398
VGGT [57]	0.344	0.371	0.343	0.340	0.368	0.362	0.380	0.399	0.635	0.541	0.623	0.636	6.623	6.280	6.296	5.684
$\pi^3$ [61]	0.175	0.201	0.166	0.144	0.203	0.213	0.177	0.177	0.508	0.467	0.531	0.582	2.394	2.425	2.093	1.991
VGGT-$\Omega$ [58]	0.243	0.254	0.215	0.246	0.320	0.305	0.288	0.328	0.653	0.643	0.693	0.636	2.680	3.065	2.162	2.624
MapAnything [25]	0.246	0.226	0.246	0.269	0.320	0.291	0.299	0.295	0.519	0.624	0.773	0.549	3.297	2.268	2.066	2.383
PanoVGGT [18]	0.240	0.233	0.248	0.262	0.261	0.250	0.270	0.293	0.568	0.512	0.542	0.615	2.405	2.316	2.498	2.501
$\bar{R}_{\mathrm{med}}\downarrow$ (°) of the same arm
Any3R	10.53	7.36	8.61	9.03	6.13	2.73	4.82	5.26	12.72	12.75	29.54	23.21	3.49	3.74	2.69	3.47
DA3	49.45	58.80	55.00	59.44	50.54	42.27	67.73	48.43	96.91	86.65	95.54	88.26	38.78	39.03	38.12	41.40
VGGT	47.60	60.52	47.20	36.31	47.09	52.73	49.77	40.01	115.44	91.15	101.77	81.11	55.71	47.36	60.06	52.56
$\pi^3$	14.96	14.59	12.20	10.89	25.88	29.76	18.93	16.22	37.52	42.28	39.78	43.62	37.06	80.55	34.73	26.32
VGGT-$\Omega$	20.85	20.71	18.92	22.08	36.78	35.62	34.08	35.88	40.27	39.13	38.66	34.43	39.31	51.54	33.50	34.36
MapAnything	32.54	34.02	33.63	33.86	41.89	44.74	43.03	43.40	46.96	59.14	41.73	44.40	41.86	34.06	27.59	43.24
PanoVGGT	9.21	13.41	13.11	8.89	15.95	20.03	18.56	19.27	30.47	19.23	16.84	26.58	7.45	10.20	12.06	10.03

Table 15 averages all thirteen cameras by field of view. On every dataset our error is lower at every wider lens than at 90°, and the best pinhole model fares worse against us at each of them than at 90°.

FoV	Matterport3D								Stanford2D3DS
	Any3R	DA3[34]	VGGT[57]	$\pi^3$[61]	V-$\Omega$[58]	MapA[25]	PanoV[18]	Any3R	DA3	VGGT	$\pi^3$	V-$\Omega$	MapA	PanoV
90°	0.083	0.292	0.304	0.113	0.150	0.120	0.271	0.084	0.314	0.247	0.090	0.161	0.122	0.284
150°	0.051	0.330	0.331	0.139	0.176	0.229	0.259	0.053	0.309	0.344	0.133	0.261	0.243	0.281
180°	0.055	0.334	0.329	0.184	0.229	0.250	0.273	0.062	0.355	0.363	0.207	0.297	0.295	0.302
200°	0.054	0.376	0.361	0.177	0.261	0.248	0.242	0.062	0.381	0.378	0.203	0.328	0.317	0.265
360°	0.063	0.366	0.383	0.380	0.364	0.327	0.246	0.081	0.390	0.390	0.393	0.408	0.399	0.275
	Structured3D							PanoCity
	Any3R	DA3	VGGT	$\pi^3$	V-$\Omega$	MapA	PanoV	Any3R	DA3	VGGT	$\pi^3$	V-$\Omega$	MapA	PanoV
90°	0.732	0.691	0.713	0.733	0.787	0.723	0.792	1.202	5.024	4.046	1.595	1.642	1.559	2.482
150°	0.522	0.614	0.623	0.683	0.678	0.533	0.730	0.929	5.700	6.161	1.856	1.944	1.930	2.368
180°	0.440	0.578	0.602	0.562	0.631	0.601	0.573	0.862	5.654	5.486	2.136	2.433	2.387	2.766
200°	0.322	0.573	0.596	0.516	0.621	0.547	0.566	0.888	6.366	6.607	2.368	2.725	2.761	2.425
360°	0.201	0.510	0.456	0.457	0.486	0.431	0.340	0.980	3.654	2.780	2.207	2.490	2.256	2.484

Reading Table 16 by column shows the effect of the lens on one method, and reading it by row shows the ordering of the methods under one lens. Table 17 lists both inputs of the baselines that have two, on all thirteen cameras. On the three datasets of the paired pool Any3R is best in 32 of the 39 cells and tied in six, five of them at 90° and the sixth the cylindrical PanoCity cell, and it is behind $\pi^3$ on the Stanford2D3DS pinhole cell. On the 13 Structured3D cells it is best in nine and tied in three, the Brown–Conrady, FOV/ATAN and Equisolid cells, and it is behind VGGT-$\Omega$ and MapAnything on the pinhole cell.

Camera (FoV)	Matterport3D							Stanford2D3DS
	Any3R	DA3[34]	VGGT[57]	$\pi^3$[61]	V-$\Omega$[58]	MapA[25]	PanoV[18]	Any3R	DA3	VGGT	$\pi^3$	V-$\Omega$	MapA	PanoV
Pinhole (90°)	0.069	0.300	0.288	0.109	0.161	0.089	0.281	0.083	0.325	0.252	0.059	0.138	0.095	0.284
Brown–C. (90°)	0.096	0.284	0.320	0.117	0.139	0.150	0.261	0.085	0.303	0.243	0.120	0.184	0.149	0.284
FOV/ATAN† (150°)	0.051	0.330	0.331	0.139	0.176	0.229	0.259	0.053	0.309	0.344	0.133	0.261	0.243	0.281
Equidist. (180°)	0.056	0.360	0.343	0.166	0.215	0.246	0.248	0.061	0.363	0.380	0.177	0.288	0.299	0.270
Stereogr.† (180°)	0.060	0.349	0.340	0.144	0.246	0.269	0.262	0.069	0.384	0.399	0.177	0.328	0.295	0.293
ERP-Cr. (180°)	0.051	0.267	0.261	0.265	0.245	0.242	0.331	0.053	0.309	0.287	0.310	0.286	0.296	0.364
MEI (180°)	0.054	0.361	0.371	0.163	0.212	0.245	0.250	0.064	0.365	0.387	0.165	0.288	0.289	0.281
KB4 (200°)	0.050	0.388	0.344	0.175	0.243	0.246	0.240	0.061	0.404	0.368	0.203	0.320	0.320	0.261
Equisolid† (200°)	0.056	0.382	0.371	0.201	0.254	0.226	0.233	0.055	0.364	0.362	0.213	0.305	0.291	0.250
Double-Sph. (200°)	0.055	0.368	0.358	0.165	0.259	0.259	0.249	0.065	0.389	0.390	0.201	0.344	0.328	0.282
EUCM† (200°)	0.054	0.364	0.370	0.168	0.286	0.261	0.244	0.067	0.369	0.392	0.196	0.344	0.331	0.267
ERP (360°)	0.045	0.390	0.401	0.419	0.386	0.342	0.077	0.064	0.415	0.395	0.408	0.421	0.430	0.066
Cylind.† (360°)	0.082	0.343	0.364	0.342	0.342	0.312	0.415	0.098	0.366	0.385	0.377	0.396	0.367	0.484
	Structured3D							PanoCity
	Any3R	DA3	VGGT	$\pi^3$	V-$\Omega$	MapA	PanoV	Any3R	DA3	VGGT	$\pi^3$	V-$\Omega$	MapA	PanoV
Pinhole (90°)	0.757	0.665	0.781	0.819	0.729	0.774	0.812	1.160	4.360	4.153	1.479	1.711	1.485	2.256
Brown–C. (90°)	0.706	0.716	0.645	0.647	0.845	0.671	0.771	1.243	5.689	3.940	1.711	1.572	1.633	2.708
FOV/ATAN† (150°)	0.522	0.614	0.623	0.683	0.678	0.533	0.730	0.929	5.700	6.161	1.856	1.944	1.930	2.368
Equidist. (180°)	0.443	0.539	0.623	0.531	0.693	0.773	0.542	0.866	6.656	6.296	2.093	2.162	2.066	2.498
Stereogr.† (180°)	0.451	0.613	0.636	0.582	0.636	0.549	0.615	0.917	6.398	5.684	1.991	2.624	2.383	2.501
ERP-Cr. (180°)	0.428	0.610	0.513	0.611	0.622	0.555	0.601	0.811	2.717	3.078	2.426	2.455	2.861	3.633
MEI (180°)	0.436	0.549	0.637	0.523	0.572	0.527	0.533	0.854	6.844	6.886	2.036	2.490	2.236	2.433
KB4 (200°)	0.294	0.563	0.635	0.508	0.653	0.519	0.568	0.863	6.463	6.623	2.394	2.680	3.297	2.405
Equisolid† (200°)	0.310	0.519	0.541	0.467	0.643	0.624	0.512	0.893	6.336	6.280	2.425	3.065	2.268	2.316
Double-Sph. (200°)	0.340	0.624	0.597	0.543	0.602	0.502	0.596	0.901	6.477	6.430	2.271	2.544	2.789	2.473
EUCM† (200°)	0.345	0.587	0.612	0.545	0.587	0.544	0.586	0.896	6.189	7.097	2.381	2.613	2.690	2.504
ERP (360°)	0.128	0.553	0.442	0.445	0.496	0.440	0.144	0.663	3.149	1.902	1.628	1.876	1.833	0.751
Cylind.† (360°)	0.275	0.467	0.470	0.468	0.476	0.421	0.535	1.298	4.160	3.657	2.785	3.104	2.680	4.216

The cylindrical cell is the one place the format matters rather than the field of view. Our Acc there is higher than on the equirectangular cell in all four datasets, and on PanoCity it is the only wide cell where Any3R is tied rather than best. Equirectangular images are 83.6% of the training mixture, so a panoramic format that is not equirectangular is where that mixture shows.

Table 18 holds the field of view fixed and changes only how angle maps to radius. Any3R is best in 15 of its 16 cells and tied with $\pi^3$ in the remaining one, the Structured3D Equisolid cell. Each value also carries the method’s own pose error, and that error differs between the two members of a pair for every method, ours included, so under predicted poses the table ranks the methods under each mapping but does not isolate the effect of the mapping itself.

Per-Point Error

Figure 6 colours each point with the scene’s own texture, which shows what a reconstruction looks like but not how wrong it is. Figure 9 redraws the same cells with every point coloured by its distance to the ground truth, normalised by the scene radius, which is the quantity Acc averages. Two things are visible here that the averages in Table 5 cannot show. The first is that the error of the perspective-native baselines on the wide lenses covers whole walls rather than a few points, because each fused cloud carries its method’s own pose error and a misplaced view moves every point it contributes, while our error stays low across the room on the wide lenses. The second is that the failures are structured rather than noisy. On the wide cells the baselines return smooth surfaces that are confidently wrong, bent into a shell or folded inwards, rather than a scattered cloud.

The Ray Map Withdrawn

The last row is the part worth dwelling on. On equirectangular input the fallback and the true ray field coincide up to floating-point rounding, so the two columns are not merely close, they are the same computation, and their Acc agrees to three decimals on all four datasets. Everything the module does elsewhere therefore costs nothing on the input the backbone was pretrained for. Read together with the rest of the figure, the pair says that the gain is not a general improvement to the backbone but a correction that activates exactly where the pretrained assumption stops holding, and is inert where it still holds.

Table 19 gives the Acc of one checkpoint under three ray maps, and without the ray map its error grows on every dataset. A small CNN trained leave-one-dataset-out to predict each view’s camera type and field of view gives a far more accurate map than the fallback, yet recovers part of the gap only on Matterport3D and is worse than the fallback elsewhere, so the backbone needs an accurate map rather than an approximate one. The decoder places each point along its ray, so a direction error moves a point in proportion to its distance, which is largest on PanoCity, whose outdoor scenes the predictor never saw, and the predictor also replaces the exact map of the equirectangular frames, where the fallback needed no correction. Figure 10 shows two of them on the same frames. With no calibration the backbone falls back to assuming an equirectangular grid, so a $90^\circ$ pinhole image is treated as a full sphere, and the geometry is wrong over most of the frame. The bottom row is the internal control: on equirectangular input the fallback is the correct ray map, and the two columns are indistinguishable. That row is the exactness constraint of § 3.2 made visible.

Ray field	Ang. err.	M3D	S2D3DS	S3D	PanoCity
True	$0.0^\circ$	0.059	0.067	0.442	0.920
Predicted	$7.9^\circ$	0.192	0.278	0.621	3.378
ERP fallback	$35.8^\circ$	0.243	0.263	0.579	2.299

The Camera Models and How Their Images Are Made

Figure 11 images one panorama through each of the eight camera models, with a graticule drawn on the sphere before projection so the distortion each model applies is visible as a deformation of the grid. The fraction of the sphere each one observes is given under its panel, from 14.6% for a $90^\circ$ pinhole to the full sphere for equirectangular. The parameters behind those panels are the ones the benchmark releases: pinhole $r = f \tan\theta$, Brown–Conrady with $k_1 = -0.18$ and $k_2 = 0.02$, equidistant $r = f\theta$, Kannala–Brandt with a fourth-order polynomial truncated at $\theta_{\max} = 100^\circ$, MEI with $\xi= 1.6$, double sphere with $\xi= 0.25$ and $\alpha= 0.55$, and the two latitude–longitude grids at $\pm90^\circ\times\pm45^\circ$ and over the full sphere. Figure 12 shows how one such frame is produced. The camera model enters in exactly one place, when the ray map is built from the calibration; downstream every lens is the same tensor of the same shape. Pixels outside a model’s invertible domain are marked invalid and are never filled with a fabricated ray, which is what the validity mask in the second row carries.

The narrow-pinhole limit. For an ideal pinhole with focal length $f$ in pixels and $u$, $v$ measured from the principal point, $R(u) = (u, v, f)/\sqrt{u^2 + v^2 + f^2}$ gives $\mathrm{d}\Omega_u = \cos^3 \psi_u/f^2$, with $\psi_u$ the angle between the ray and the optical axis, so the solid angles of the centre pixel and of the pixel at the largest angle $\psi_{\max}$ differ by the factor $1/\cos^3 \psi_{\max}$, already 5.2 for the corner of a square $90^\circ$ frame. Eq. (6) therefore reduces to Eq. (5) only in the limit of a narrow pinhole.

Accuracy Against Field of View

Normalising each method by its own 90° value is what makes the comparison about the lens rather than about the method’s overall quality. A method that is uniformly weak but equally weak everywhere traces a flat line; a method that depends on the projection traces a rising one. Figure 13 plots the five field-of-view bands of Table 15 with each method divided by its own Acc at 90° and averaged over the three datasets of the paired pool, so the curves start together and only the slope is compared. A value below one means the method is more accurate on the wider lens than on the nar-

row one it was measured against.

Any3R stays below one at every wider field of view, because the encoding and the objective both read the measured ray field, so a wider lens is simply more of the scene per view. PanoVGGT stays close to one and dips below it everywhere except at 180°, because its fixed equirectangular assumption is satisfied at the wide end and violated at the narrow end, which is the same failure as the perspective models with the axis reversed. Every perspective-native method rises above one in every band.

Real Pinhole Imagery

Every camera in the benchmark is rendered from a panorama, so a reader may reasonably ask whether the model has learnt something about resampled imagery rather than about cameras. Table 20 therefore evaluates camera pose on DL3DV [35], a capture set of real phone and camera video with no panoramic origin and no resampling step, over 60 scenes at three views each. On a pinhole the upper half of the rotary frequencies still spans the image as the stock encoding does, so the mechanism is meant to leave this regime close to the pretrained one. Our mean over scenes of the per-scene median rotation error is the lowest of the seven methods and our AUC at 30° the second highest, while DA3 leads the AUC at 5°. Any3R is thus at the level of VGGT on every measure, so the pinhole prior survives. PanoVGGT, trained on panoramas alone, makes the mirror error and reads every photograph as a panorama, so its rotation error is far larger than that of any other method.

Method	AUC@5$^\circ$ $\uparrow$	AUC@30$^\circ$ $\uparrow$	$\overline{R}_{\mathrm{med}} \downarrow$
DA3 [34]	0.9022	0.9543	3.32$^\circ$
MapAnything [25]	0.7567	0.9196	8.69$^\circ$
$\pi^3$ [61]	0.7400	0.9206	8.82$^\circ$
Any3R	0.7211	0.9313	3.00$^\circ$
VGGT [57]	0.7011	0.9300	3.06$^\circ$
VGGT-$\Omega$ [58]	0.6011	0.9135	3.34$^\circ$
PanoVGGT [18]	0.0000	0.0515	51.18$^\circ$

Figure 14 shows reconstructions on the same capture set. DL3DV provides no dense depth, so the only ground truth in the figure is the set of sparse tracks that places each cloud, and the clouds are compared by eye. The DL3DV frames also make visible a convention of the benchmark that the main text passes over. Each rendered camera is limited to the cone of its declared field of view, so the 90° pinhole cell of Figure 6 is an inscribed disc with dark corners and about $\pi/4$ of the frame carrying content, whereas a DL3DV frame is a full rectangle. The cone is what keeps the solid angle equal across camera models at a fixed field of view, so a row of Table 5 compares sampling rather than coverage, and accuracy there is computed over observed points only.

Matched Coverage

A wide lens shows more of a room than a narrow one, so a benchmark spanning 90° to 360° invites the reading that a method is credited for coverage rather than for geometry. This section removes the difference in coverage and asks the question again. Each input is centre-cropped and resized back to its original pixel count, so the patch count and the network are unchanged and the field of view is the only variable. Each variant is scored against the ground-truth points it can itself see, so a narrower view is not charged for the part of the room it no longer contains. Cropping to half the angular radius leaves 53° for the two rectilinear cameras, 90° for the equidistant fisheye, 100° for KB4 and 180° for the equirectangular frame.

Tab. 21 answers the question by the field of view left after cropping. Any3R is best in two of the ten cells, the cropped equirectangular frame on both datasets, and ties $\pi^3$ in four, the 90° equidistant and 100° KB4 crops. On the four 53° pinhole and Brown–Conrady crops it is behind, and VGGT-$\Omega$ or $\pi^3$ has the lowest median there. A narrow pinhole frame is what a perspective-native backbone was built for, and there it draws level or ahead, while the gap opens as the lens departs from that assumption. The advantage at the wide end therefore survives the removal of coverage, and it does not extend to narrow pinhole crops. Withdrawing the ray field on these cropped inputs still raises our error several times over in every cell, so the field carries weight at every field of view and not only at the wide end.

Dataset	Camera (FoV after crop)	Any3R $\pi^3$ [61]	MapAnything [25]	DA3 [34]	VGGT-$\Omega$ [58]	VGGT [57]	PanoVGGT [18]
Matterport3D	Pinhole ($53^\circ$)	0.0681	0.0619	0.0749	0.0669	0.0513	0.0927	0.2134
	Brown–Conrady ($53^\circ$)	0.0574	0.0488	0.0778	0.0575	0.0509	0.0841	0.2412
	Equidistant ($90^\circ$)	0.0622	0.0698	0.1332	0.0865	0.0872	0.1098	0.2178
	KB4 ($100^\circ$)	0.0720	0.0793	0.1205	0.0890	0.0976	0.1222	0.2224
	ERP ($180^\circ$)	0.0717	0.2182	0.2476	0.2890	0.2660	0.2512	0.2567
Stanford2D3DS	Pinhole ($53^\circ$)	0.0521	0.0403	0.0485	0.0391	0.0364	0.0910	0.2362
	Brown–Conrady ($53^\circ$)	0.0543	0.0413	0.1034	0.0481	0.0482	0.0794	0.2470
	Equidistant ($90^\circ$)	0.0785	0.0826	0.1301	0.1058	0.1135	0.1092	0.2352
	KB4 ($100^\circ$)	0.0780	0.0864	0.1426	0.1053	0.1216	0.1262	0.2475
	ERP ($180^\circ$)	0.0593	0.2466	0.3474	0.2839	0.2982	0.2972	0.3294

Figure 15 shows one scene, camera by camera and crop by crop. The room fills in as the crop widens, and at the narrowest crop every camera keeps only a fragment of it.

Figure 16 traces the other half of the same question, with the camera held fixed and the crop varied. Over the fifty pairs of camera and crop the rank correlation between field of view and error is $-0.57$, and the crops below $45^\circ$ have a higher mean error than those above $150^\circ$. The trend is not monotonic, since the median across the five cameras is lowest at the $0.75$ crop on both datasets and rises slightly at the full frame, and on Stanford2D3DS the $0.35$ crop is worse than the $0.20$ one. Narrow crops also weaken the pose, because narrow views of one room share less content. At the full frame the three views of every scene are connected by shared content and the median relative rotation error is $2.0^\circ$, while at the $0.20$ crop 46 of the 100 scene and camera pairs lose that connection and the error is $13.4^\circ$. Our Acc with predicted poses nevertheless stays within about a tenth of the same reconstruction placed with ground-truth poses at every crop, so the rise at the narrow end is not mainly a pose failure. Because each crop is resized back to the original pixel count, a narrower crop raises angular resolution while lowering coverage, so the direction of this trend places the weight on coverage rather than on resolution. That is the claim made in § 1 about a wide lens carrying more of the scene per exposure, measured here with the lens held fixed rather than exchanged for another.

Training Convergence

The released model is trained for 40 epochs from the original initialisation rather than from a warm start and is evaluated only at its selected checkpoint, so Figure 17 shows the per-epoch pose accuracy and depth error of an earlier full run from the same initialisation, trained on eight A100s, against the released panoramic baseline on the same protocol. That protocol is equirectangular input only, so it is a narrower question than the tables ask, and the outcome marks the boundary of the claim: final depth is below the baseline on three of the four datasets and level with it on the fourth, while final pose is slightly under it on three. Any3R is the better model across camera models, which is what Table 5 and Table 16 measure; it is not a better equirectangular model than one trained for equirectangular input alone.

The Frequency Split

The three arms differ in one switch and are otherwise the same training run, so the columns can be compared directly. On Matterport3D the constant-angle arm has the lowest median over scenes at $180^\circ$ and $200^\circ$, and the released split lands nearer the field-of-view arm. At $360^\circ$ the three medians are within a thousandth of each other on Matterport3D and Stanford2D3DS, which is what the split is designed to give, since the frequencies that carry the constant angle are the lower half and those are the ones an equirectangular grid barely exercises. At $90^\circ$ the constant-angle arm also has the lowest median on both indoor datasets. The released configuration is the split, which matches the field-of-view arm on pose while recovering part of the constant-angle arm’s advantage on geometry.

Table 22 isolates the split described in § 3.2 against the two arms that apply a single scale to all 16 frequencies. Over the camera models used here, one coordinate unit varies by a factor of 1.000 in elevation and azimuth on the constant-angle half and by 2.82 and 5.74 on the other half.

	Matterport3D			Stanford2D3DS			Structured3D			PanoCity
FoV	const.	FoV	split	const.	FoV	split	const.	FoV	split	const.	FoV	split
mean over scenes
90°	0.066	0.084	0.083	0.084	0.083	0.084	0.783	0.690	0.732	1.185	1.272	1.202
180°	0.042	0.054	0.053	0.049	0.065	0.059	0.334	0.431	0.436	0.734	0.839	0.844
200°	0.044	0.055	0.053	0.054	0.070	0.063	0.233	0.354	0.317	0.805	1.070	0.882
360°	0.047	0.045	0.045	0.069	0.053	0.064	0.126	0.197	0.128	0.645	0.760	0.663
median over scenes
90°	0.057	0.061	0.058	0.057	0.068	0.061	0.406	0.417	0.427	1.059	1.048	1.121
180°	0.039	0.051	0.048	0.038	0.047	0.047	0.151	0.293	0.323	0.657	0.803	0.804
200°	0.043	0.054	0.050	0.042	0.055	0.053	0.105	0.190	0.227	0.680	1.007	0.877
360°	0.044	0.045	0.045	0.042	0.043	0.042	0.046	0.086	0.048	0.600	0.648	0.587

Counting each individual camera rather than one per model family gives 5.92 and 12.01. The agreement at the patch centres derived in § 3.2 holds with the split in place.

The three checkpoints share every state-dict key and byte count, so they are distinguished only by their hashes, and they were trained identically apart from this switch. The pre-registered criterion was judged on the earlier measurement with ground-truth poses. There the split improved the median of every cell at 180° and at 200° against the field-of-view arm, and against the constant-angle arm it did not, with medians 14.0% and 15.9% worse at those two fields of view and no cell improved, while that arm’s pose accuracy collapses and the split’s does not. The criterion for adopting the split as a strict improvement was thus not met, and with predicted poses in Table 22 the constant-angle arm again has the lowest median at 180° and 200° on every dataset. We release the split configuration for its pose behaviour and record the geometry shortfall here.