Hunyuan3D V1 - Views2Mesh

This is the last node in the chain and the one you actually care about, because it's where a pile of flat images becomes a 3D model you can open in Blender, print, or drop into a game engine. Everything upstream of it - the image loader, the text-to-image stage, the multi-view diffusion - exists to feed this thing. And it's the node with the most knobs, plus the pack's one famous footgun.

The inputs are the outputs of the previous stages, so if you're building the image-to-3D workflow from scratch you wire it like this: Image Loader → Image2Views → Views2Mesh, carrying the views_grid_pil, cond_img, and config along. Text-to-3D is the same chain with a Text2Image stage in front of the loader. This node's job is to take those 3×2 views and reconstruct an actual mesh via Tencent's SVRM - a sparse-view reconstruction model.

How it works

The Views2Mesh Pipeline Load node behind this one loads svrm.safetensors (the SVRM weights) from the pack's weights/svrm/ folder. When you hit Run, the node takes the six views plus the conditioning image - seven inputs, each resized to 504px - and places them on a virtual turntable with cameras 60° apart. The model reconstructs the geometry, remeshes it to a target polygon count, and writes mesh.obj into the run's output folder. Texture mapping (if enabled) unwraps the object and bakes the views onto it; rendering (if enabled) spins the finished mesh through 120 frames at 30fps with pytorch3d and saves output.gif.

Here's the footgun, and it's a genuine "where people get burned": the node's only output, preview, is not a picture of the mesh. The code literally converts the input views grid back into an IMAGE tensor and returns that. Your real result lives on disk at ComfyUI/output/Hunyuan3D-1/<timestamp>/mesh.obj - plus output.gif if do_render is on. Don't stare at the preview waiting for a render. Open the folder.

The inputs that matter

• target_face_count (default 90000, range 10000–500000) - how many triangles the reconstructed mesh is remeshed to. Higher = more detail, more VRAM, slower. For a game-ready low-poly prop you'll go way down from the default; for a hero asset you might push up.
• do_texture_mapping - bakes the multi-view images onto the mesh as UV texture. Sounds mandatory, but here's the catch: the README says texture mapping and GIF output don't work when you install with ComfyUI's bundled Python. They only work if you run ComfyUI in a conda environment (the pack's "recommended" install route). If you're on the bundled-python path, leave this off or you'll get errors.
• do_render - spins up the pytorch3d GIF renderer. Same availability caveat applies. Nice-to-have, and it's the only way to eyeball your result without leaving ComfyUI.

Then seed, views_grid_pil, cond_img, config, and pipeline_config are the pass-through plumbing from upstream stages.

Install

Installing this pack is a project, not a click. It's not in ComfyUI Manager's easy path (the README says so outright), and the requirements are heavy: Python 3.12, C++ build tools, pytorch3d (built from source - the README's own build recipe is worth following), an Open3D development wheel for py3.12, nvdiffrast, Ninja, plus the pack's requirements.txt. Tencent's Hunyuan3D-1 weights and the HunyuanDiT text-to-image model have to be pulled manually with huggingface-cli. A fresh ComfyUI install is strongly recommended so none of this breaks your working setup.

Troubleshooting

The known issue is real and it lives here: torch.OutOfMemoryError: Allocation on device hits randomly during mesh generation - the README shows it, the community hits it. It's a flaky-allocator thing, not your setup: rerun with the same seed and it usually goes through. Setting target_face_count lower reduces peak memory, and the use_lite toggle on the pipeline load nodes is the proper low-VRAM path. The other common failure is a config mismatch - if config didn't come from the same upstream node that made the views, the mesh stage can't find its output folder. Keep the chain linear.