TripoSR Model Loader

This is the boring-but-necessary first node in a genuinely fun little pipeline: single image in, 3D mesh out. TripoSR Model Loader doesn't do any reconstruction itself - it just gets the TripoSR checkpoint sitting in memory so the Sampler node downstream can actually query it. Every TripoSR workflow starts here, and if this node is broken or empty, nothing else in the pack works.

What TripoSR actually is

TripoSR is a feedforward 3D reconstruction model from Tripo AI and Stability AI, and "feedforward" is the important word. There's no denoising loop, no steps slider, none of the iterative sampling you're used to from image generation. You give it one photo, it runs a single forward pass through a transformer, and out comes a triplane representation of the object's geometry - which the Sampler node then converts into an actual mesh. It's closer to running a single inference pass through a segmentation model than it is to running a KSampler.

The ComfyUI wrapper was built by flowtyone (the person behind flowt.ai) the same week TripoSR itself dropped in March 2024 - a same-day "I felt like I had to make a node for this" project that's still the standard way to run TripoSR inside ComfyUI. Worth knowing going in: TripoSR reconstructs geometry from one viewpoint, so it's genuinely good at getting a rough, centered subject into 3D fast, and it is not going to nail the back of an object it never saw. Community reception on the base model has always been split for exactly that reason - some people get clean, usable meshes, others get a distorted mess, and the difference usually comes down to the input image (more on that in the Sampler article).

Inputs and outputs

Two required fields, and you'll only ever touch one of them regularly:

• model - a dropdown populated from whatever's sitting in ComfyUI/models/checkpoints. If it's empty, that's not a bug - it means you haven't downloaded the checkpoint yet (see Installing, below).
• chunk_size - an integer, default 8192, range 1–10000. This controls how many points the model's renderer evaluates per batch when it converts the learned representation into density values for mesh extraction. It's a pure memory/speed trade-off: drop it if you're VRAM-constrained, raise it if you've got headroom and want it done faster. It doesn't change reconstruction quality.

The single output is TRIPOSR_MODEL, which plugs directly into the model input on the TripoSR Sampler node. That's the only place it goes - there's no other consumer in the pack.

Installing it

Through ComfyUI Manager: search ComfyUI-Flowty-TripoSR, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/flowtyone/ComfyUI-Flowty-TripoSR.git
cd ComfyUI-Flowty-TripoSR
pip install -r requirements.txt

Then the part people skip and immediately regret: download model.ckpt from the official TripoSR HuggingFace repo and drop it into ComfyUI/models/checkpoints. Restart ComfyUI, and it'll show up in the model dropdown.

Where people get burned

The real friction isn't this node, it's pip install -r requirements.txt. TripoSR's mesh extraction leans on torchmcubes, a package that compiles a CUDA/C++ extension rather than shipping a prebuilt wheel - and that's the step that blows up on people, especially on Windows without a working build toolchain. If you see a CUDA kernel failed error the first time you actually run a reconstruction (not at load time - this node itself rarely errors), that's torchmcubes compiled against a CUDA version that doesn't match your installed PyTorch, and the fix is reinstalling with a matching CUDA toolkit rather than anything in this node's settings. Beyond that, the only other thing to check is the obvious one: empty dropdown means no checkpoint in models/checkpoints, and the original demo reports the default settings run comfortably in around 6GB of VRAM, so chunk_size is rarely something you need to touch on anything newer than a low-end card.