UltraShape Load Coarse Mesh From Trimesh
Feed UltraShape a mesh that's already in memory
- model
- trimesh
- coarse_mesh
This is the version of Load Coarse Mesh for people who don't want to touch disk. It does the exact same job - sample a coarse mesh, voxelize it, hand the refiner something to work with - but instead of a file path it accepts a TRIMESH object directly. If your graph already has a mesh in memory, you skip the save-then-load dance entirely.
It's one of four TRIMESH-interop nodes the pack added in 0.2.0, and it's where the pack deliberately reaches into the Trellis2 ecosystem. The natural flow: Trellis 2 generates a mesh → you get it as a TRIMESH socket → this node converts it to the pack's ULTRASHAPE_MESH → Refine sharpens it → Output To Trimesh hands it back to the texture pipeline. No intermediate .glb written to output/ and re-imported, which is both faster and one less thing to break.
What you feed it
Two required inputs:
model- theULTRASHAPE_MODELfrom Load Model. Non-negotiable; the refiner's weights have to be in memory before anything is sampled.trimesh- anyTRIMESHsocket. That's the socket type Trellis2-family nodes speak (the source explicitly names Trellis2 exports as the intended source), and UltraShape Load Mesh produces it too, if your coarse mesh is sitting on disk.
The optional inputs are identical to the file-path sibling: normalize_scale (0.99), num_sharp_points (204,800), num_uniform_points (204,800), and num_latents (0 = use the config default, usually 32768; more = more detail, more VRAM). Same sharp-edge sampling, same normalization, same voxelization. The only real difference is the input side - the mechanism downstream is byte-for-byte the same code path.
Why you'd pick this over Load Coarse Mesh
Honestly? Convenience and robustness. The file-path version is perfectly fine, but its mesh_path string has a whole resolution rulebook (input/ prefix vs output/ prefix vs absolute, and a bare filename silently defaulting to input/). This node has none of that - a mesh comes in, it's already loaded, there's no path to mis-type and no "Mesh file not found" to debug. The moment your coarse mesh is already inside the graph as a TRIMESH (Trellis 2 output, a Load Mesh result, whatever), this is the node you reach for.
It's also the node to use when you want to chain refinements: take a refined mesh (via Output To Trimesh), run it back through here, and refine again. Each pass gets you a different flavor of detail, and in-memory transport makes the loop trivial.
Install and caveats
Same pack install as everywhere in this family:
cd ComfyUI/custom_nodes
git clone https://github.com/jtydhr88/ComfyUI-UltraShape1
cd ComfyUI-UltraShape1
pip install -r requirements.txt
Restart, drop ultrashape_v1.pt into ComfyUI/models/UltraShape/ from infinith/UltraShape on HuggingFace, and you're set. ComfyUI Manager finds it under ComfyUI-UltraShape1.
Two things to keep in mind. First, the TRIMESH socket is a pack-to-pack contract - it only lights up if you also have a pack that produces TRIMESH sockets (Trellis2 nodes, or this pack's own Load Mesh). If nothing offers a TRIMESH output, that's why the socket is dark. Second, it inherits every VRAM consideration of the file-path version: the sampled surface goes to GPU, and num_latents is the dial to pull back if you're near the edge. And same as its sibling, a pathologically simple source mesh can throw tensor-size mismatches that the pack auto-pads - you'll get a result, just not a detailed one.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| model | ULTRASHAPE_MODEL | — | |
| trimesh | TRIMESH | — | |
| normalize_scaleopt | FLOAT | 0.990.5–1 | — |
| num_sharp_pointsopt | INT | 20480010000–500000 | — |
| num_uniform_pointsopt | INT | 20480010000–500000 | — |
| num_latentsopt | INT | 00–131072 | Number of latent tokens. 0=use config default (usually 32768). Higher=more detail but more VRAM |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| coarse_mesh | ULTRASHAPE_MESH | — |