UniRig Load Mesh ⚡

ComfyUI can save a 3D file easily. Loading one back in as a usable MESH is the awkward gap - core's Load3D wants an interactive viewport, and most of the auto-rigging graphs out there assume the mesh came straight from a generator node in the same run. This node closes that gap: give it a filename, get a MESH.

What it does

It reads a GLB, glTF, OBJ or STL from either ComfyUI's input/ or output/ folder and parses it into core's MESH type using the same parser core's Get3DComponents uses - so vertices, faces, and whatever normals/UVs the file carries arrive in exactly the form every other core 3D node expects. The plugin does not implement its own importer, which is the right call: parsing glTF is a solved problem and re-solving it badly is how 3D packs get their reputation.

Two widgets:

• source_folder - output (default) or input. There's no file browser here, just the two roots.
• file_path - a path relative to that folder, default 3d/triposg_00001_.glb, which is exactly what a SaveGLB node produces (save_prefix 3d/triposg, counter appended). Type or paste; there's no picker.

Output: mesh, ready for Extract Skeleton and for any core 3d/mesh node.

The sandbox, and why it's a feature

The path is resolved against the folder root and the result must stay inside it. Try ../../etc/passwd and you get "outside the output folder". That's not paranoia for its own sake - this is a node that takes a typed string, and a ComfyUI graph can be loaded from a stranger's JSON, so a path that escapes the model/input tree is a real thing to refuse.

Two practical consequences. First, absolute paths don't work; strip the leading part of /home/you/ComfyUI/output/3d/thing.glb down to 3d/thing.glb. Second, a missing file fails at execution with the full resolved path in the message, which is genuinely helpful:

UniRig Load Mesh: no such file /home/you/ComfyUI/output/3d/triposg_00001_.glb

If the path in that error looks right and the file exists, you're probably running ComfyUI with a different --output-directory than you think.

It re-runs when the file changes

The node reports the file's modification time as its cache key, so editing the GLB on disk and re-queuing actually re-reads it instead of serving the cached mesh. Small detail, big quality-of-life when you're iterating on a mesh in Blender and re-running the rig inside ComfyUI every few minutes - which is exactly the workflow the community describes for auto-rigging: model in Blender, rig in ComfyUI, back and forth.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ChrisColeTech/ComfyUI-GGUF-Loader
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF-Loader/requirements.txt

Manager → search "ComfyUI-GGUF-Loader" → restart. No model files needed for this node; the parsing is core's, so nothing new to download.

Where it fits

The obvious chain is SaveGLB (from a TripoSG or TRELLIS.2 run, or anything else) → this node → UniRig Extract Skeleton → Apply Skinning → Rig to GLB. That's why the default path says 3d/triposg_00001_.glb: it's the pack's own example chain, example_workflows/triposg_to_unirig_rigged_glb_api.json.

Less obvious but more useful: this is how you bring in a mesh from outside ComfyUI. Blender export, a marketplace asset, something you sculpted - drop it in input/, point the node at it, and the rest of the rigging graph doesn't care where it came from.

Traps

One mesh at a time is what the rigging nodes want. This node will happily load a multi-object GLB, but Extract Skeleton warns and rigs batch item 0 only. If your file has a body, a sword and a hat as separate objects, decide what you're rigging before you get there.

No material or texture in the mesh pipeline. The geometry survives; the appearance doesn't travel through the rig - Rig to GLB writes a skinned bind-pose mesh, not a textured one. Keep the original file if you need its materials downstream.

FBX isn't on the list. GLB, glTF, OBJ, STL. FBX is the one format people assume is supported because Blender speaks it; convert first.