One image produces five geometry outputs
MoGe takes 1 RGB image and returns a 3D point map, depth map, camera intrinsics, validity mask, and optional normal map. That is a wider output set than a depth-only estimator provides. The command-line tool can save maps, PLY point clouds, and textured GLB files, while the Python class exposes tensors for an application pipeline. If the horizontal field of view is known, callers can provide it instead of making the model estimate that camera property.
The repository contains 123 files, roughly 68,362 source lines, and 13.7 MB at commit 74fbce0. It carries MoGe-1, MoGe-2, and MoGe-3 code in one package. Published model choices range from a 35M-parameter MoGe-2 variant to a 1.25B-parameter MoGe-3 checkpoint. That range gives researchers room to trade model size for output detail, but it also makes the model name and checkpoint part of every reproducible result.
MoGe-3 applies three refinement steps by default
MoGe-3 adds sparse volumetric refinement and defaults to 3 refinement steps after its initial prediction. The API can return each intermediate step, and the CLI accepts a different step count. It also lets users adjust a resolution level from 0 through 9 or supply a token count in the suggested 1,200 to 2,500 range. Those settings affect inference work and fine detail, so a production wrapper should expose them as pinned configuration instead of relying on shifting defaults.
MoGe-2 remains relevant because it has several ready model sizes, pretrained normal-map variants, and documented ONNX exports. MoGe-3 requires an explicit checkpoint path, while v1 and v2 can load named Hugging Face models. The 113-package environment can therefore serve several experiments, yet stored outputs must record the model generation and checkpoint. A depth map from v2 is not an interchangeable artifact with a refined v3 point map.
What happened when we ran it
Our sandbox installed 113 Python packages in 107 seconds and used 5,176 MB on disk. The build finished successfully in 6 seconds. Pip-audit reported 0 known vulnerabilities for the installed dependency set. The large footprint arrived before any pretrained checkpoint was counted, so teams building containers or ephemeral workers need extra space for both the Python environment and the model file they select.
There was no test command or target to run, so our harness skipped tests. The checkout also had 0 CI workflow files and no tests directory. A passing 6-second build establishes that packaging completed in the stated Debian container; it says nothing about prediction correctness, GPU execution, exported geometry, or compatibility with a camera dataset. Those need application-level checks, especially because monocular geometry can look plausible while carrying the wrong scale or field of view.
CUDA 13.0 is the default uv choice
Python 3.10 or newer is required. The recommended uv sync route pins torch and torchvision to the CUDA 13.0 wheel index, which helps repeat one supported environment but may not match an installed NVIDIA driver. The README tells users targeting another CUDA version to change the index or reinstall PyTorch with a selected backend. Plain pip does not read uv's index settings, so its PyTorch choice must be managed separately.
Our default environment ended at 5,176 MB across 113 packages, a useful warning for developers who see the 13.7 MB checkout and expect a light library. MoGe-3 also depends on FlexGEMM, which builds on Triton. The project explicitly excludes macOS because Triton does not publish macOS wheels. Although the CLI accepts a device string, anyone planning a CPU service should prove that exact model and dependency path on the target host before designing around it.
ONNX omits MoGe-2 post-processing
The ONNX guide covers MoGe-2 with opset 14 or newer, dynamic image resolution, and variable token counts. Its exported graph contains the raw forward pass. The guide says focal recovery, shift handling, reprojection, and other .infer() post-processing are outside the graph. An ONNX deployment must re-create those steps and compare its final maps against PyTorch, rather than checking only whether the runtime accepts the model file.
MoGe's evaluation code supports 10 documented benchmarks, metric and invariant depth groups, point metrics, local-detail measures, boundaries, and FOV. Running that evaluation requires downloading and unpacking a separate processed dataset. Open issue 153 reports an undefined read_meta name in one baseline evaluation path. With 0 CI workflow files and no repository test target, downstream teams should preserve a small known-image set that checks shapes, finite values, scale, camera intrinsics, and exported geometry.
August activity continues without formal GitHub releases
GitHub recorded the last push on August 19, 2026, and issue 161 received activity on August 26 about MoGe-3 refinement loss. The repository had 2,864 stars and 83 combined issues and pull requests when fetched. GitHub's latest-release endpoint returned no release, so adopters should pin a commit and checkpoint instead of expecting a tagged package release to define the whole deployment.
The lack of a release feed does not make MoGe dormant: MoGe-3 landed in August 2026 and current issue discussion followed it. The weaker signal is verification. Our 107-second install and 6-second build passed, but no upstream test target challenged the 68,362-line checkout. MoGe deserves a trial for research and carefully checked 3D tools. It should not be the uncalibrated measuring instrument behind robotics, surveying, or safety decisions.