MapAnything: Meta's Feed-Forward Metric 3D Reconstruction Framework

What MapAnything solves, and for whom

Reconstruction pipelines usually mean chaining tools. A structure-from-motion stage produces poses, a multi-view stereo stage produces dense geometry, a separate depth model handles single images, and a registration step stitches the results. Each stage has its own input conventions, its own output format and its own failure behaviour. MapAnything's claim is that one end-to-end trained transformer can regress the factored metric 3D geometry of a scene from images alone, or from images plus calibration, poses or depth, and that the same weights cover more than 12 tasks, among them multi-image sfm, multi-view stereo, monocular metric depth estimation, registration and depth completion.

The audience is narrower than the task list suggests. The README calls MapAnything an open-source research framework, and the repository layout backs that up: benchmarking/, data_processing/, configs/, scripts/ and train.md sit next to the model package. This is aimed at people who train or benchmark reconstruction models, and at engineers who want to compare architectures without rewriting their data loader for each one. A product team looking for a single supported command that turns a folder of photos into a mesh will find the surface area larger than they want.

One interface over VGGT, DUSt3R, MASt3R, MUSt3R and Pi3-X

The mechanism worth understanding is not the transformer itself but the abstraction around it. The README describes a modular design in which different 3D reconstruction models can be used interchangeably through a unified interface, and names VGGT, DUSt3R, MASt3R, MUSt3R and Pi3-X as the external models already wired in. The optional dependency groups in pyproject.toml make that concrete: dust3r, mast3r, must3r, pi3, vggt-omega, depth-anything-3 and others each pull their upstream repository from git, and pyproject.toml notes that the all extra installs external model support.

That is the real value proposition. If you are benchmarking reconstruction approaches, the input loading, the output container and the profiling harness stay fixed while the model behind them changes. The README documents a unified output format for external models, and a profiling section with a command-line interface and named output files, so comparisons are meant to be run the same way each time.

The cost is dependency weight. Pulling several research repositories from git at install time means the all extra is a large, loosely pinned environment, and the README explicitly says PyTorch and CUDA versions are not pinned. Two people installing the same commit can end up with different CUDA stacks. That is a deliberate choice, and it is the right one for a framework meant to run on many machines, but it moves version resolution onto you.

Installing MapAnything and running a first reconstruction

The README gives a conda-based install. The base install pulls the core dependencies from pyproject.toml, and the all extra adds the external model packages. Note that the README does not pin PyTorch or CUDA, so install those for your system before or after this step.

git clone https://github.com/facebookresearch/map-anything.git
cd map-anything
conda create -n mapanything python=3.12 -y
conda activate mapanything
pip install -e .

The README also suggests the all extra when you want external model support, and pre-commit install for the development hooks:

pip install -e ".[all]"
pre-commit install

For a first inference run, the README's image-only example sets an allocator option, loads the model through the Hugging Face hub, and calls infer on a list of views. The model identifier matters: the README states that facebook/map-anything-apache is the Apache 2.0 licensed model, while facebook/map-anything is the default checkpoint. Loading requires internet access or a pre-populated hub cache.

import os
os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "expandable_segments:True"

import torch
from mapanything.models import MapAnything
from mapanything.utils.image import load_images

device = "cuda" if torch.cuda.is_available() else "cpu"
model = MapAnything.from_pretrained("facebook/map-anything").to(device)
views = load_images("path/to/your/images/")
predictions = model.infer(views)

load_images accepts a folder path or a list of image paths. What you get back from infer is the factored geometry the model regresses; the README's example is truncated at that point, so the shape of the output dictionary is not spelled out there. Read the source under mapanything/ before you write code against it. If you would rather click than script, the README links a Hugging Face Space demo and documents local Gradio and Rerun demos.

Where MapAnything is the wrong tool

The clearest limitation is that this is a research framework, and its documentation is organised like one. The README has a long table of contents covering training, data processing, benchmarking, COLMAP export and Gaussian splatting integration, but several sections are pointers rather than walkthroughs. Training is covered by train.md rather than in the README itself. The image-only inference example is cut off mid-call. If your team needs a documented, stable API with a migration guide per release, this is not that, and the version history supports the reading: v1.1.1 in March 2026, v1.1.2 in May, v1.1.3 in July, with pyproject.toml already at 1.1.4. Small, frequent increments are normal for research code and painful for pinned consumers.

The second limitation is the checkpoint licence split. The code is Apache-2.0, but the README distinguishes facebook/map-anything-apache from the default facebook/map-anything checkpoint. Code licence and weights licence are separate questions, and the README does not resolve the second one.

Third, the dependency model. Optional extras install upstream research repositories directly from git branches rather than released versions. A force-push or a renamed module upstream breaks your environment with no version number to pin to. If reproducibility across machines matters more than breadth, install only the extras you actually benchmark against.

MapAnything compared with VGGT and Depth Anything

The comparison people search for is MapAnything against VGGT, and the repository answers it structurally rather than in prose. VGGT appears as an external model in the available models list and as the vggt-omega optional dependency, which means MapAnything can run VGGT through its own interface rather than compete with it head to head. The difference in approach is that VGGT is a model, while MapAnything is the framework around a model: data processing, training, inference, profiling and export to COLMAP and Gaussian splatting formats. If you want a checkpoint to call, VGGT is the shorter path. If you want to measure several checkpoints on the same data with the same output format, MapAnything is the layer that makes that repeatable.

Against Depth Anything the split is different again. Depth Anything produces depth; MapAnything's task list includes monocular metric depth estimation but places it alongside multi-view stereo, sfm and registration, and the depth-anything-3 extra shows it can also be run as one of the interchangeable backends. The word doing the work here is metric. A depth map in relative units and a metric reconstruction with poses and scale are different outputs, and picking the wrong one is a common way to waste a week.

Licence, releases and what an upgrade costs

The repository is Apache-2.0, and setup.py carries the Meta copyright header with the Apache License, Version 2.0 reference. That covers the code. It does not automatically cover the weights: the README points to a separate facebook/map-anything-apache model for Apache 2.0 use, which implies the default checkpoint is governed by something else. Check the model card on the hub for the checkpoint you actually download. Nothing here is legal advice, and the distinction between a permissive code licence and a model licence is exactly the kind of thing to route through whoever handles licensing at your organisation.

The upgrade cost is dominated by the git-sourced extras. Core dependencies in pyproject.toml are mostly pinned or bounded, with opencv-python-headless fixed at 4.10.0.84, uniception at 0.1.7, pycolmap at 3.10.0 and rerun-sdk at ~=0.24.1. The external model groups are not: dust3r, mast3r, must3r, pi3, pow3r, vggt-omega and depth-anything-3 all install from git references. Upgrading MapAnything therefore means re-resolving those upstream repositories, and a break there looks like a MapAnything bug until you trace it. The last push to the default branch was on 2026-08-07, and the most recent release listed is v1.1.3 from 2026-07-17.

Editorial conclusion

Adopt MapAnything if you need one interface across several reconstruction models, or if you want training, data processing, inference and profiling in the same repository, and you are comfortable reading the configuration files to find the entry points. Do not adopt it if you need a supported product with a documented command for every task, or if you cannot accept the checkpoint licence split. Verify first which checkpoint licence covers your use: the README points to facebook/map-anything-apache for the Apache 2.0 model, while the default facebook/map-anything checkpoint carries its own terms.

Frequently asked questions

Official sources

1. facebookresearch/map-anything on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases