A head-to-head of the three open 3D generators people actually run locally: architecture, mesh fidelity, VRAM and time budgets, licence terms and ComfyUI node support, plus a decision framework you can apply to your own images.
Ask which open 3D generator to run locally in 2026 and the shortlist usually settles on three names: TRELLIS 2, Hunyuan3D 2.x and TripoSR. All three accept a single image and return a mesh you can open in Blender, and the first two also document multi-view conditioning. Beyond that they diverge sharply in representation, memory footprint, texture handling and licence terms.
Everything below comes from the project repositories, vendor pages and the ranges users report on consumer GPUs. Where a figure is a range, it is deliberate: resolution settings, attention backend, PyTorch and CUDA versions, and whether the texture stage runs in the same process all move the number.
The three models were published roughly two years apart, and the architecture choices show it. One decodes a structured latent into explicit geometry, one splits the job into a shape stage and a paint stage, and one predicts a triplane field in a single forward pass. That explains most of the contrasts below: memory footprint, texture handling, and how much repair the mesh needs before a slicer or game engine accepts it.
TRELLIS 2 continues the line of work Microsoft published on structured 3D latents. The project documentation describes a model that learns a sparse voxel structure with local feature vectors, then generates them with a rectified-flow transformer conditioned on the input image. Decoding supports several output forms; for mesh work you use the mesh decoder, which extracts geometry and carries texture information. The practical result is clean silhouettes and a mesh that arrives with UVs and texture maps rather than bare vertex colours, though thin structures and concave areas still show the usual latent-model artefacts: softened edges, floaters, and interior shells you have to delete.
Tencent's Hunyuan3D 2.x ships as two independent models. The shape model is a diffusion transformer that produces an implicit geometry field from the input image, converted to a mesh with marching cubes; version 2.1 added multi-view input and improved geometry. The paint model is a multi-view diffusion model: it renders the shape from several angles, synthesises consistent views, and bakes them into a texture, with PBR maps in 2.1. Because the stages are separate, you can run shape only and skip the cost of texturing, or point the paint model at any other mesh.
TripoSR is the oldest of the three and the easiest to reason about. A transformer encoder reads the image, a triplane-NeRF decoder predicts density and colour, and the mesh is extracted from that field. There is no diffusion sampling loop, so inference is fast and reproducible for a given seed, and the pipeline fits in a small amount of video memory. The cost is fidelity: broad shapes come out smooth, fine structure goes missing, and the output carries vertex colours rather than a UV-mapped texture, so material work moves downstream to Blender, Substance Painter or an AI texturing pass.
Fidelity is the easiest thing to fake in a comparison like this, so here is the plain version: all three return meshes that need work before printing or shipping in a game. Interior geometry, duplicate vertices and non-manifold edges are normal, and anything that will be animated needs retopology regardless of which generator produced it.
| Model | What it returns | Texture | Typical cleanup |
|---|---|---|---|
| TRELLIS 2 | Mesh decoded from structured latents | UV-mapped texture maps | Delete floaters and shells, merge vertices, decimate to a polycount budget |
| Hunyuan3D 2.x | Implicit shape field converted with marching cubes | Baked texture, PBR maps in 2.1 | Even out dense triangle soup, weld seams, rebuild UVs for clean islands |
| TripoSR | Triplane field meshed in one pass | Vertex colours only | Retopology and a UV unwrap before texturing |
The figures below are ranges that turn up repeatedly in project issues, ComfyUI discussions and vendor documentation, not measurements from one machine; treat them as a budget, not a promise. A 12 GB card runs the shape stage of all three; the ceiling usually bites in the paint stage of Hunyuan3D 2.x. Attention backend, fp16 versus bf16 weights and encoder offloading all shift the figure.
| Model | Comfortable VRAM | Time per asset | What pushes it up |
|---|---|---|---|
| TRELLIS 2 | 16 GB in most reports; 12 GB with tiled or low-VRAM settings | Tens of seconds per image | Higher decode resolution, several results resident, larger texture maps |
| Hunyuan3D 2.x | 10-16 GB for shape; 16-24 GB with the paint stage in the same session | One to two minutes for shape, several minutes with texturing | Multi-view input, marching-cubes resolution, number of paint views |
| TripoSR | 6-8 GB is usually enough | A few seconds per image on a modern GPU | High marching-cubes resolution, large batches |
This is where most comparisons go vague. Code and weights are often published under different terms, and a permissive code licence says nothing about the weights. All three publish code under permissive terms, and at least one weight release carries a vendor community licence with territorial limits and user-scale thresholds. That is not a reason to avoid it, but it is a reason to read the model card before building a commercial pipeline on the output.
| Model | Code licence | Weight licence | Check before commercial use |
|---|---|---|---|
| TRELLIS 2 | MIT | Set by the model card | Weight terms and attribution requirements |
| Hunyuan3D 2.x | Repository licence file | Tencent community licence, territorial and user-scale limits | Whether your region and company size fit the grant |
| TripoSR | MIT | MIT | Little beyond keeping the notice; verify the current model card |
If you would rather not commit to one model, push the same image through several engines and compare before exporting. Open3DAI does exactly that: it runs one local procedural generation engine and can connect to third-party engines through adapters using your own API keys. It does not train or host those third-party models, and it does not do retopology, UV unwrapping, rigging or animation, so a production character still ends up in Blender. What it does cover is text-to-3D, image-to-3D and multi-view input, AI texturing, side-by-side comparison of connected engines, and export to GLB, glTF, OBJ, STL, PLY and 3MF, plus 48 format converters, 12 browser tools and a REST API for build pipelines.
Engine availability, credit pricing and third-party terms change. Verify the current licence text, node requirements and pricing on the vendor page before committing a budget; repository details here reflect the projects at the time of writing.
On fidelity, no: it is the oldest of the three, it loses fine structure, and it returns vertex colours instead of a UV-mapped texture. On cost and speed it still wins comfortably, since it needs far less VRAM and has no sampling loop. Teams often keep it as a fast blockout or prompt-testing baseline and switch to one of the newer models for the final asset.
None of them reliably. All three return closed-ish but imperfect geometry that usually contains interior shells, non-manifold edges or very dense triangle soup. Budget a repair pass in Blender or Meshmixer, check wall thickness against your nozzle, and treat the generator as the first step of the print pipeline rather than the last.
No. TripoSR runs comfortably in 6-8 GB, and the shape stages of TRELLIS 2 and Hunyuan3D 2.x typically fit in 10-16 GB. The heavy case is Hunyuan3D 2.x with the paint stage in the same session, where 16-24 GB is the comfortable range. Lower resolution settings and offloading bring the ceiling down at the cost of time.
As static props, usually yes, after decimation to your polycount budget and a pass to remove interior geometry. For anything that will be rigged and animated, no: the output topology is dense triangle soup, so you still need retopology and a fresh UV layout before skinning. Game-ready characters remain a DCC job.
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.
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.
Hunyuan3D 2.x is a shape diffusion model plus a separate texturing stage, and ComfyUI can drive both. Here is how the graph is wired, what each route costs in VRAM, and what the usual error messages mean.
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.