Single-image 3D generation has to invent the back of the object. This walkthrough covers how the TRELLIS 2 multiview stage in ComfyUI turns one picture into a ring of consistent angles, how to lay out the camera views, and how to decide whether the extra VRAM is worth it.
An image-to-3D model only sees the pixels you hand it. Give it one front view and it must invent everything behind the silhouette: back thickness, how the sides close, where the limbs meet. Some of that guessing lands well; some of it produces a hollow shell, stray geometry, or a back panel that looks nothing like the front.
Multiview input exists to shrink that guessing. The pipeline receives a ring of camera angles of the same object, all derived from your single image, and the reconstruction has to satisfy them at once. The payoff is usually a better back side, fewer holes and a silhouette that survives a turntable; the cost is more sampling time and more VRAM.
TRELLIS 2 is a structured-latent image-to-3D model: an image encoder produces conditioning, a sparse structure stage builds a structural representation, and decoders turn the resulting latent into geometry and texture. The multiview variant inserts one step before the shape is sampled, where a smaller view-generation model takes your input image plus a list of target camera poses and produces one image per pose. Those images condition the sparse structure and latent stages together, so their content sets the ceiling for the mesh: a hard shadow or a mismatched perspective becomes warped, flattened geometry. Multiview cannot invent detail that was never in the input, so a soft 512-pixel photo of a figurine stays a soft asset.
| Item | What is needed | Notes |
|---|---|---|
| GPU | 16 GB VRAM for the default multiview path | 24 GB suits 6 views at a higher view resolution; 8-12 GB needs resolution cuts and CPU offload |
| Toolchain | Recent ComfyUI, PyTorch with CUDA, TRELLIS 2 weights | Several stages use compiled CUDA extensions, so a working compiler matters more than GPU speed |
| Node pack | A ComfyUI pack exposing TRELLIS 2 multiview nodes | Node names differ between ports; check the pack README, not a screenshot |
| Disk | Tens of GB for weights plus ring images | Views are written to the output folder, and a long session fills it quickly |
| Stage | Typical node family | What to check |
|---|---|---|
| Load and preprocess | Image loader, background removal or crop | Square canvas, subject centered, clean alpha |
| Generate ring views | Multiview generation node with a pose list | Same object identity in every view, no baked shadow |
| Condition | Camera conditioning node pairing views with poses | Pose count matches image count, anchor view matches the input |
| Sparse structure | Structure sampling stage | Proportions read correctly from the front view alone |
| Structured latent | Latent sampling stage | Silhouette thickness holds from the side views |
| Decode and texture | Geometry decoder, texture stage, preview and export | Back surface is continuous, no floating fragments |
Two cost notes. The first run of a session also loads tens of GB of weights from disk, so that wall-clock time is not the per-asset time. VRAM scales with view count and view resolution, so if a run dies while sampling, halve the generated view resolution before touching any optimization switch.
| Views | Coverage | Cost adder | Fits |
|---|---|---|---|
| 3 | Front plus both sides, no rear information | Lowest | Near-symmetric objects read mostly from the front: busts, plates, reliefs |
| 4 | Front, back and two sides | Moderate | The default for game props, figurines and print miniatures |
| 6 | Fuller ring, better corners and chamfers | Highest of the three | Asymmetric or hollow objects, anything shown on a turntable |
| 1 | Front only | Baseline | Flat-backed pieces, textured panels, inputs too soft for invented views |
Treat those numbers as relative, not absolute. On a 24 GB card, four ring views at moderate resolution plus texturing commonly runs in a few minutes per asset, and six views add a noticeable share on top. The same job on an 8-12 GB card with offload stretches further, so measure on your own machine.
| Symptom | Usual cause | Fix |
|---|---|---|
| Back side comes out flat | Too few views, or every view at the same shallow elevation | Add two rear views and raise their elevation |
| Silhouette has notches | Ring views disagree on object width | Recheck crop and scale consistency, then regenerate |
| Mesh looks melted | Ring images carry contradictory shadows or perspective | Clean the background and regenerate from a flatter input |
| Texture has visible seams | Lighting or white balance drifted between views | Lock the prompt and light direction across the ring |
| Out of memory | Too many views at too high a view resolution | Halve the view resolution, then cut the view count |
Multiview earns its cost when the object will be seen from more than one angle and the back side matters: game props a player can walk around, figurines headed for a printer, anything destined for a turntable preview. It also earns its cost when the object is thin, hollow or full of openings, which is where a single view leaves the model free to guess badly.
It is not worth it for textured panels, reliefs and flat-backed pieces, where a second angle buys nothing but minutes. Nor is it a repair tool: if the input is soft or over-exposed, six generated views multiply the ambiguity, and one clean view plus a few minutes of mesh cleanup in Blender or Meshmixer is the better trade.
Running TRELLIS 2 locally means owning the node graph, the weights and the failures, and it gives you control over ring poses and every intermediate image. Open3DAI, the product this site documents, runs one local procedural generation engine plus optional third-party engine API adapters that you connect with your own API keys, and it accepts text-to-3D, image-to-3D and multiview input. It offers AI texturing and lets you run the same prompt or image through the available engines and compare results side by side before exporting to GLB, glTF, OBJ, STL, PLY or 3MF. That shortens the comparison loop: generate one subject single-view and multiview, compare the two back sides, then decide.
Multiview changes the conditioning, not the output format: what comes out is still a dense triangle mesh with baked texture maps that needs decimation, UV work or mesh repair before it is production-ready. Open3DAI does not train or host those third-party models either, and it does no retopology, UV unwrapping or watertight guarantees, so a desktop mesh tool stays in the pipeline.
One. The workflow takes a single image and generates the additional angles itself as an intermediate step, so you are not required to shoot or render a turntable first. What you do need is a clean, evenly lit input, because every generated angle inherits its framing and lighting from that one picture.
The model never saw the back. With one front view as the only constraint, the shape stage is free to produce thin walls, disconnected shells or stray fragments wherever the silhouette gives no evidence. Rear views constrain those regions from more than one direction, which usually reduces that class of artefact, though cleanup does not become optional.
More than single view, yes. Sampling time and memory both grow with the number of ring views and with the resolution they are generated at, and six views sit at the top of the useful range. On a 16 GB card, four views at moderate resolution is the comfortable default; if a run dies at the sampling stage, cut the view resolution first.
Almost always inconsistency between ring images rather than the texture stage itself. If one view is lit from the left and another from the right, or if white balance drifts, the albedo is averaged across those views and the difference shows up as seams. Keep the object prompt, framing, scale and light direction identical across the whole ring.
Send the same prompt or image to several engines, compare the meshes side by side, then export GLB, glTF, OBJ, STL, PLY or 3MF. Creating an account grants free credits and needs no card.
TRELLIS 2 is a 4B-parameter image-to-3D model, and its ComfyUI wrapper depends on compiled CUDA extensions that must match your Python, torch and CUDA versions. This hub covers what it produces, what a machine needs, and how both workflow builds are assembled.
A downloaded TRELLIS 2 workflow is one JSON file describing node types, links and widget values. Most first-load failures come down to four things: a missing node pack, a weight filename that no longer matches, widget values that shifted between pack versions, and a VRAM budget only the GGUF variant fits.
ComfyUI can run Hunyuan3D, TRELLIS and the lighter 3D models behind one node graph, but the weights, the VRAM budget and the trip from a voxel grid to a printable mesh are three separate problems.