InstantMeshLoader

Let's get the awkward part out of the way first: the repo behind this pack is archived. The author, jtydhr88, stopped maintaining it because MrForExample's ComfyUI-3D-Pack absorbed InstantMesh - the README literally tells you to go there. If you're starting from scratch, do that instead. But if you already have this pack installed, or you loaded a workflow that names InstantMeshLoader, the good news is it still runs. Which is why this page exists.

What it does

InstantMeshLoader is the boring, indispensable half of a two-node pipeline. On its own it does nothing visible - it loads a reconstruction model and hands it to InstantMeshRun, the node that actually turns your image into a 3D mesh. Think of it as the CheckpointLoader for the image-to-3D world: pick a model, wait for the weights, wire the outputs onward.

It's built on TencentARC's InstantMesh, the "efficient 3D mesh generation from a single image" project. The loader's job is to pick which of the four InstantMesh model variants to spin up, download the checkpoint if you don't have it, and get it sitting in VRAM waiting.

The one input that matters

config_name is the entire config surface, and it has four choices:

• instant-mesh-base - smaller model (12 transformer layers), faster, lower quality
• instant-mesh-large - the one you actually want; best quality, still quick
• instant-nerf-base / instant-nerf-large - the paper's NeRF ablation variants. These render neural fields and don't go through the FlexiCubes mesh-extraction path, so for anything you want to export as an OBJ, skip them.

Realistically you pick instant-mesh-large and never think about it again. Base exists if you're VRAM-starved.

How it works

The node loads a YAML config, instantiates the model architecture described in it, then checks for the checkpoint locally. On first run it downloads the matching .ckpt from the TencentARC/InstantMesh repo on Hugging Face - instant_mesh_base.ckpt or instant_mesh_large.ckpt, a couple of GB. Subsequent runs use the cached copy, so the load time is just model + memory.

It returns two things: model (type InstantMeshModel) and config (type InstantMeshConfig). Both plug straight into InstantMeshRun's first two inputs. There's no third thing to wire - you connect a LoadImage, a couple of wires from this node, and you're done.

One thing to know before you build around it: this is CUDA-only. The code pins torch.device('cuda') - there's no CPU path, no Apple Silicon path. You need an NVIDIA GPU.

Installing it - the honest version

This is where people get hurt. The pack doesn't just clone and restart; it sits on top of ComfyUI-3D-Pack, which is notoriously the hardest thing in the ecosystem to install. In a community thread listing "nodes people love but can never install," this pack and its dependency both made the list, and one commenter reported it "completely effed my ComfyUI install." Don't attempt it on a working setup without a backup.

The README's flow, for Windows portable:

cd ComfyUI/custom_nodes
git clone https://github.com/MrForExample/ComfyUI-3D-Pack
cd ComfyUI-3D-Pack
install_windows_portable_win_py311_cu121.bat
:: then, still stopped:
cd ..\ComfyUI-InstantMesh
git clone https://github.com/jtydhr88/ComfyUI-InstantMesh
install_windows_portable_win_py311_cu121.bat

You also need Visual Studio Build Tools installed, because 3D-Pack compiles native extensions. The InstantMesh half's own requirements.txt is mercifully short - pytorch-lightning==2.1.2 and rembg - but it installs into the same shared Python environment as everything else, so version conflicts are a real risk. ComfyUI Manager can find the pack by searching "ComfyUI-InstantMesh," but Manager can't fix the 3D-Pack prerequisite for you.

If that all sounds like a lot, it is - and it's the exact reason the author archived this in favor of 3D-Pack's integrated support. My take: this loader only earns its install if you're already on 3D-Pack. If you're not, you're installing two heavy dependencies to run one archived pair of nodes. Modern you can do better.