Remesh GPU (backend)

This is the fastest remesh in the pack, because it's the only one that's not just fast - it's GPU-accelerated. The gpu_cumesh backend runs CuMesh, the CUDA mesh library that powers Microsoft's TRELLIS2 image-to-3D pipeline. Same algorithm, same remesh_narrow_band_dc dual-contouring call, now exposed as a plain remesh node. If your pipeline already touches TRELLIS-style 3D and you want a remesher that keeps up, this is the one.

There's a hard requirement attached: it needs a CUDA-capable NVIDIA GPU, torch, and the cumesh package. The node literally asserts device.type == "cuda" - no CPU fallback, no Apple Silicon path. If you don't have a CUDA GPU, this node will error out and one of the CPU backends (PyMeshLab, Geogram, PMP) is your move.

It's the gpu_cumesh option of the main Remesh dispatcher, dev-only in the schema like the rest of the backends.

How it works

Two stages, both on the GPU. First, dual-contouring: the mesh is rasterized into a fixed 512³ grid (hardcoded, same as TRELLIS2), and the surface is re-extracted from that grid using dual contouring with a configurable narrow band. This gives you a clean, watertight-ish, uniformly dense surface regardless of how broken the input was - the grid rebuild just erases most sins. Second, the result is simplified back down to a target face count. The remesh_band parameter controls the width of the dual-contouring band: wider = smoother, narrower = more detail captured. After simplification, orientations are unified so the output has consistent normals.

Inputs and outputs

• trimesh (TRIMESH) - the mesh to remesh.
• target_face_count (default 500000) - faces after simplification. The default is big; drop it to ~50k–100k unless you genuinely need half a million triangles.
• remesh_band (default 1.0) - band width for dual contouring. Higher = smoother but may lose fine detail; lower = sharper but noisier.

Outputs: remeshed_mesh (TRIMESH) and info (STRING). The info string is unusually detailed here - it reports the pre-simplify face count and the post-simplify count, which is useful for tuning.

Installing

Pack install is the standard route - ComfyUI Manager → GeometryPack, or:

cd ComfyUI/custom_nodes
git clone https://github.com/PozzettiAndrea/ComfyUI-GeometryPack.git
cd ComfyUI-GeometryPack
pip install -r requirements.txt --upgrade
python install.py

Restart after. But that's only half of it for this node: the install.py step builds the isolated comfy-env environment that contains the CUDA toolchain and cumesh, and that environment is where GPU installs most often go wrong. Verify your torch build actually sees your GPU (python -c "import torch; print(torch.cuda.is_available())"), because this node inherits every CUDA/version-mismatch problem your machine already has.

Troubleshooting

• "cumesh requires CUDA" - no CUDA GPU, or torch doesn't see it. This is a hard stop for this node, not a bug.
• Crash on huge meshes - the code itself skips the orientation-unify pass above 2M faces because CuMesh can choke there; if you're feeding it monsters, decimate first.
• Environment build failures - CUDA + cumesh inside an isolated env is the most fragile install in the pack. Re-run python install.py, check the repo Discussions.
• Output face count way off - target_face_count is a target, and the simplify pass lands "close." Tune from the info string's reported counts.
• Stale-workflow validation errors are the pack-wide gotcha - if the Remesh node throws, delete and re-add it, re-pick gpu_cumesh.

The honest take: if you're a CPU-only user this node is decoration. If you have the GPU for it, it's the closest thing in the pack to "remesh and don't think about the time."