Tripo: Multiview to Model

The classic image-to-3D failure mode: the front looks great, and the back is mush. Tripo's multiview node exists to fix exactly that. You feed it up to four views of the same subject - front, left, back, right - and it reconstructs a model that's consistent all the way around. It's the node you reach for when you're generating a character or a product and you need the silhouette to survive a 360° rotation.

Like every node in ComfyUI's partner/3d family, this is not local. It's Tripo's paid cloud API, proxied through Comfy Org, billed in credits. But for game-asset work it's often the difference between a mesh you can actually use and a prop with a hole where the reference never showed.

How it works

The front image is required; left, back, and right are all optional - but the node won't run unless you supply at least one of them. All provided views are uploaded to Comfy's cloud and forwarded to Tripo's multiview_to_model task, which fuses the views into one geometry and (by default) textures it. Comfy polls until the task lands, then writes the GLB to your output folder as <task_id>.glb. Budget a minute or two of polling, more if you enable the detailed quality options.

The inputs that matter

• image - the front view. Required.
• image_left, image_back, image_right - optional side views. At least one is required, and the better your coverage, the better the geometry. Keep the subject framed the same way in each shot or the fusion gets confused.
• texture / pbr - both default true. Same cost math as the single-image node: PBR maps cost extra credits.
• model_version - the generation in use. Leave at default.
• face_limit - -1 lets Tripo choose; a fixed number gives you a known triangle budget for games.
• geometry_quality / texture_quality - standard/detailed, each bump costing more credits.
• quad - ignore it. The tooltip says it plainly: "This parameter is deprecated and does nothing." It's still in the schema, but it's a fossil.

Outputs: model_file (STRING path), model task_id (MODEL_TASK_ID, wires into Tripo's refine/rig/texture siblings), and GLB.

Common issues

The classic mistake is inconsistent framing - a zoomed-in front shot and a distant side shot won't fuse into anything coherent. Keep the same camera distance and lighting across all four views. Second gotcha: people assume the back view is optional-optional, but the node explicitly errors if you feed only the front. And remember the cost math from the single-image node still applies: stacking detailed texture, detailed geometry, and PBR can roughly double the base 20-credit price.

If you're trying to dodge the paid cloud entirely, the local Hunyuan3D and TRELLIS nodes can reconstruct from images too - but multiview consistency is Tripo's party trick, and it's the reason this node keeps its fans even among the "API bullshit" skeptics.