TripoSG Sampler ⚡

This is the actual generation step in a TripoSG graph: an image goes in, a shape latent comes out, and everything visually interesting about your final mesh is decided here. It's also the node where TripoSG stops looking like Stable Diffusion - no sampler names, no scheduler dropdown, no CFG rescale. Just steps, guidance, and a token count.

The mechanism

Under the hood there are two models working in sequence. First the image encoder - DINOv2, the same family DINOv3 supersedes elsewhere in this pack - plus its matching feature extractor, producing conditional tokens from your prepared image. The unconditional side isn't a text embedding or an empty prompt; it's zero tokens, which is TripoSG's trained null condition. That's why there's no negative prompt socket: the model has exactly one "nothing" and you don't get to describe it.

Then the rectified-flow DiT integrates a straight-line path from noise to shape latent, with classifier-free guidance applied against that zero-token unconditional. No ancestral noise, no scheduler trickery - rectified flow is a much tamer sampler than the epsilon-prediction stuff, and the step counts show it.

Output is shape_latent, a CCTECH_TRIPOSG_LATENT - not a mesh, not an image. It only means anything to TripoSG Decode Mesh, which is the next node and the one that turns it into triangles.

The five inputs

• triposg_model - from the Model Loader. Duh, but note both this and the decoder need it; it's one socket per node, from one loader.
• image - the tooltip is explicit: output of TripoSG Prepare Image. A raw photo will run, and you'll get a shape of the photo's framing rather than of the object.
• seed - 42 by default, with the standard regenerate-after-run control. Seed matters here: two different seeds on the same image give two different plausible back-sides, because nothing in a single view constrains them.
• steps - 50 by default, up to 500. This is the one number people get wrong in both directions. 50 is what the reference pipeline runs, and dropping to 20 doesn't halve your time so much as soften the surface. Going to 100 buys very little.
• guidance_scale - 7.0 by default. The tooltip states the rule plainly: 1 or less disables CFG. Below that you get a more average, blobbier shape faster; above about 10 the reconstruction starts over-committing to the visible silhouette and inventing worse geometry behind it.
• num_tokens - 2048 shape latent tokens, in multiples of 256. This is your resolution dial, and it's the honest one: more tokens means more surface detail and more VRAM at decode time. One practitioner in the corpus reports pushing to 4096 tokens to get usable octree resolution out of a custom TripoSG pipeline; on a 24GB card, try 4096 and see whether you like what happens.

The node shows a progress bar per step and - importantly - checks for interrupt between steps, so you can cancel a 50-step run that's clearly going nowhere without killing ComfyUI.

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

Manager search "ComfyUI-GGUF-Loader" also works. The TripoSG family needs scikit-image (for the decode node's marching cubes), and the pack's requirements.txt has it. Budget about 10 GB of VRAM at float16 with the POC's defaults.

Where it goes wrong

Expecting a mesh out of this socket. shape_latent won't connect to SaveGLB, Decimate Mesh, or anything else 3D. It's a latent. Decode first. This is the single most common moment of confusion with the TripoSG family, because every other 3D pack hands you a MESH and calls it a day - TripoSG deliberately splits at its stage seams so you can inspect or swap the middle.

Texture hopes. TripoSG has no texture model at all. Whatever comes out of the decoder is untextured geometry. Paint it with core's UV and texturing nodes, or accept grey.

Reducing steps to make it faster, then blaming the model. At 20 steps the result reads as "TripoSG is worse than Hunyuan3D" when a return to 50 usually fixes it. Rectified flow is forgiving but not free; the reference value is the reference value for a reason.

Same seed, same image, different result. Shouldn't happen - the generator is seeded and the encode is deterministic - but if you've got the CPU/GPU dtype flipping between runs (a dtype change on the Model Loader), small numerical differences can push the sample somewhere else. Keep dtype fixed while you're comparing seeds.

If you want the wider picture of where TripoSG sits in the image-to-3D field - shape quality, topology, the retopology bill you pay afterwards - that's the context worth reading before you build a pipeline around it. The sampler is the easy part; the mesh is where the opinions are.