TripoSG Model Loader ⚡

TripoSG is VAST's 1.5B flow-matching image-to-3D model, the open one people actually tune: it turns a single prepared image into a shape latent that decodes to a genuinely decent watertight mesh. Running it takes three networks - a DINOv2 image encoder to read the picture, the rectified-flow DiT to imagine the shape, and an SDF VAE to make it into geometry. This node loads all three out of one folder so you can stop thinking about any of that.

Why three, and why one node

The upstream TripoSG release is a diffusers-shaped directory tree: transformer/, vae/, image_encoder_dinov2/, feature_extractor_dinov2/, scheduler/, plus a model_index.json tying them together. That's five subfolders for what is conceptually one model, and wiring each up separately in ComfyUI would be four loader nodes and a lot of ways to get it wrong.

This node takes the folder, resolves it, and returns a single triposg_model - which is a Python dict under the hood, carrying the transformer, VAE and image encoder as ComfyUI model patchers plus the feature extractor config and scheduler config as plain data. Every other TripoSG node in the pack consumes that one object, which is why the sampler and the decoder both want the same triposg_model socket even though they only touch different parts of it.

Nothing downloads at run time. No transformers, no diffusers, no hub calls - the pack vendors a pure-PyTorch port. That's the whole appeal if you've ever tried to get a 3D model running and spent the evening on dependency hell instead.

The two inputs

• model - a folder under ComfyUI/models/triposg/. The dropdown scans one level deep and only lists directories that look like a TripoSG tree, so it will show TripoSG once you've placed the split release.
• dtype - auto, float16, bfloat16, float32. auto means float16 on CUDA (the POC's default) and float32 on CPU, because half precision inference on CPU is a losing proposition.

Output: triposg_model. Wire it to the Sampler and to Decode Mesh. Both, from the same node - there's no separate VAE loader for TripoSG, which is one of the nicer things about the design.

The files

From ChrisColeTech/TripoSG on Hugging Face, the split/ folder:

huggingface-cli download ChrisColeTech/TripoSG \
  --include "split/TripoSG/*" "split/RMBG-1.4/*" --local-dir hf_triposg

Then move hf_triposg/split/TripoSG into ComfyUI/models/triposg/TripoSG - 7.9 GB, that's the model. The RMBG-1.4 folder is a separate node's business (176 MB, the background remover). models/triposg is registered for extra_model_paths.yaml under the key triposg if you keep models on another drive.

Budget roughly 10 GB of VRAM at float16. That's not a small model, but it's the same ballpark as the video models half this subreddit runs, and it's less than a 4B TRELLIS.2 cascade.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ChrisColeTech/ComfyUI-GGUF-Loader
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF-Loader/requirements.txt

ComfyUI Manager (search "ComfyUI-GGUF-Loader") is fine too. This family needs scikit-image for marching cubes - it's in requirements.txt, so the -r install covers it, but a bare pip install gguf does not. Restart afterwards.

Where people get burned

The folder predicate, not the folder name. The dropdown only lists paths that contain the TripoSG tree. If models/triposg/TripoSG/ has a nested TripoSG/TripoSG/ from a sloppy --local-dir, it won't appear. The scan is one level deep by design; flatten it.

float16 on CPU. Pick it explicitly on a CPU-only box and the node raises "float16 TripoSG inference on CPU is unsupported; use float32" - at least it's a clear error rather than a torrent of nan. Just take auto and let it decide.

Expecting textures. TripoSG is shape only. No UVs, no albedo, nothing you can render a pretty turntable with. The owner's sidecar paints with a Hunyuan3D-Paint stage that neither ComfyUI core nor this pack ships, so plan on core's UV and texture nodes, or just accept an untextured grey mesh. And expect face counts in the hundreds of thousands - budget a Decimate Mesh before you save anything.

If you're comparing, TripoSG sits where the KB puts it: an open 1.5B single-image generator that needs the shape right and gives you clean geometry in exchange, rather than the fast-and-disposable TripoSR end of the scale. For hard-surface props it's genuinely good. Organics, same as everything else in this field - the fingers will be wrong.