TripoSR: single-image 3D reconstruction you can run locally

What TripoSR reconstructs, and for whom

TripoSR takes a single RGB image and produces a 3D model. The README describes it as a feedforward reconstruction model developed by Tripo AI and Stability AI, built on the principles of the Large Reconstruction Model. There is no per-object optimization loop and no multi-view capture rig: one image goes in, a mesh comes out.

The intended audience is stated fairly plainly. The project says its goal is to let researchers, developers and creatives work with 3D generative AI, and the repository ships an interactive Gradio app alongside the inference script, which tells you it expects people who want to try it before wiring it into anything. If you are generating placeholder assets for a game prototype, testing an image-to-3D step inside a larger pipeline, or producing meshes for a research comparison, the shape of the tool fits. If you need a watertight, retopologized, production-ready asset, this is a research model and the README does not claim otherwise.

The feedforward path from pixels to mesh

The repository layout is small and readable: run.py for inference, gradio_app.py for the UI, tsr/ for the model code, examples/ for sample inputs, and requirements.txt for dependencies. The model itself is a feedforward transformer-style reconstruction network in the LRM family, which means the heavy lifting happens in one forward pass rather than through an iterative fitting process.

Speed is the headline claim. The README states the model generates high-quality 3D models in less than 0.5 seconds on an NVIDIA A100 GPU. That number is tied to that specific card and to the default settings; the same README says the default options take about 6GB of VRAM for a single image input. Those two facts together define the deployment envelope: a datacenter-class GPU is the reference point, and a consumer card with enough memory is the practical floor.

Mesh extraction is where the dependency list gets interesting. requirements.txt pins torchmcubes from a GitHub URL rather than PyPI, and the troubleshooting section exists almost entirely because that package fails to compile with CUDA support in common setups. Output is vertex-colored by default. Passing --bake-texture switches to a texture, and --texture-resolution sets the pixel resolution of that texture. Baking is optional, which is a sensible default: vertex colors avoid the extra xatlas and moderngl work, both of which appear in requirements.txt.

Installing TripoSR and running a first reconstruction

The README requires Python 3.8 or newer and a CUDA installation if you have a supported GPU. Install PyTorch for your platform first, following the official selector, and note the warning in the README: the locally installed CUDA major version must match the CUDA major version the PyTorch wheel was built against. If you have CUDA 11.x installed, install a PyTorch build compiled for CUDA 11.x. Mismatches are the root cause of the errors documented later.

With PyTorch in place, upgrade setuptools and install the remaining dependencies. The setuptools version matters because torchmcubes is compiled from source.

pip install --upgrade setuptools
pip install -r requirements.txt

The requirements file pins omegaconf, Pillow, einops, transformers, trimesh, rembg, huggingface-hub, imageio with the ffmpeg extra, gradio, xatlas and moderngl, and pulls torchmcubes directly from its GitHub repository. Expect that last step to be the slow one.

The first real use is a single command against one of the bundled examples. The README gives this exact invocation:

python run.py examples/chair.png --output-dir output/

The reconstructed 3D model is written into output/. You can pass more than one image path, separated by spaces, in the same command. For a textured result instead of vertex colors, add --bake-texture, and set --texture-resolution to control the output texture size in pixels. The full flag list is available through the help command.

python run.py --help

If you would rather click than type, the repository includes a local web interface. Starting it requires no arguments beyond the script name.

python gradio_app.py

Run this from the repository root so the tsr package and the example assets resolve correctly.

The torchmcubes failure and other hard limits

The most common failure is documented in the README's troubleshooting section, and it is worth reading before you install anything. Two error messages appear: AttributeError: module 'torchmcubes_module' has no attribute 'mcubes_cuda', or a message saying torchmcubes was not compiled with CUDA support and the CPU version will be used instead. The cause is a torchmcubes build without CUDA support, and the fix is to uninstall and reinstall it from source after confirming that the CUDA major versions match and that setuptools is at least 49.6.0.

pip uninstall torchmcubes
pip install git+https://github.com/tatsy/torchmcubes.git

The second limit is hardware. There is no CPU inference path documented in the README, and the 6GB VRAM figure is for a single image. Multiple images in one invocation will not reduce that per-image cost in any way the documentation describes. A machine without a supported NVIDIA GPU is not a supported target here.

The third limit is input scope. Every bundled example is a single, centered object: a chair, a flamingo, a hamburger, a horse, an isometric house, a marble, a police woman, a poly fox, a robot, stripes, a teapot, a tiger girl, a unicorn, and one captured photograph. The README does not describe scene-level reconstruction, background removal behaviour, or how the model handles occlusion between multiple objects. rembg is in the dependency list, which suggests some background handling exists, but the README does not document what it does to the output. Treat a cluttered photograph as an untested input rather than a supported one.

TripoSR against optimization-based image-to-3D tools

The natural alternative is a score-distillation approach in the DreamFusion lineage, where a 2D diffusion model is used as a prior and a 3D representation is optimized per object over many iterations. The difference in approach is structural, not a matter of tuning. TripoSR is feedforward: the network has learned a mapping from image to 3D representation during training, so inference is a single pass. Score distillation has no such trained mapping; it searches for a 3D object that renders consistently with the prompt or image under a frozen 2D model, which is why it takes minutes rather than fractions of a second.

That difference buys TripoSR its speed and costs it flexibility. A feedforward model can only produce what its training distribution supports, and the README makes no claim about generalizing to arbitrary inputs. An optimization-based method can, in principle, be steered by any prompt its 2D prior understands, at the price of a long per-asset run and a result that varies between seeds. For batch processing or interactive exploration, the per-object cost of optimization is difficult to justify. For a one-off object outside the training distribution, the feedforward shortcut may simply fail where optimization would grind toward something usable.

The README also notes that TripoSR outperformed other open-source alternatives in qualitative and quantitative evaluations across multiple public datasets, and points to the technical report for architecture, training and comparison details. Those comparisons are the authors' own; read the report before treating the claim as settled.

Licence, maintenance and the cost of upgrading

TripoSR is released under the MIT license. The README states that this covers the source code, the pretrained models and the interactive online demo, which is broader than many research releases that restrict weights separately. MIT is permissive, so redistribution and commercial use are generally allowed subject to the licence text. This is a description of what the repository says, not legal advice; read the LICENSE file and, if the stakes are high, a lawyer.

The last push to the default branch was on 2026-06-04. There are no retrieved releases, so there is no versioned upgrade path to follow: you track the main branch. That changes the upgrade calculus. Pinned dependencies in requirements.txt (omegaconf 2.3.0, Pillow 10.1.0, einops 0.7.0, transformers 4.35.0, trimesh 4.0.5, xatlas 0.0.9, moderngl 5.10.0) give you a reproducible environment today, but torchmcubes is fetched from a Git URL with no tag, so a rebuild months from now may compile a different revision than the one you tested. If reproducibility matters, pin that commit yourself in your own fork.

The upgrade cost is concentrated in the CUDA and PyTorch pairing. Because torchmcubes compiles against your local CUDA, any change to the CUDA toolkit, the PyTorch build, or setuptools can break the extension, and the README's own troubleshooting steps assume you will reinstall it from source. Budget for that whenever you move a working setup to a new machine or a new driver stack.

Editorial conclusion

Adopt TripoSR if you have an NVIDIA GPU with roughly 6GB of VRAM free, a single-object photo, and a need for a quick mesh rather than a production asset pipeline. Do not adopt it if your only machine is CPU-only, if you need texture baking at high resolution on modest hardware, or if your input is a cluttered scene rather than one isolated object. Before committing, verify three things: that your local CUDA major version matches the PyTorch build you install, that torchmcubes compiles with CUDA support, and that you are comfortable with the MIT terms covering the code, the pretrained weights and the demo.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. VAST-AI-Research/TripoSR on GitHub