Get Mesh Filename

Here's a workflow problem that sounds trivial until you hit it: you load a folder of fifty meshes, run them all through the same remesh and repair pipeline, and then you want to save each result under its original name. If you just dump them to a folder you get mesh_0001.obj through mesh_0050.obj and you've lost the mapping forever. Get Mesh Filename is the node that hands the original name back out as a string, so your save step can use it.

It's part of ComfyUI-GeometryPack ("ComfyUI libigl"), and the code is upfront about its inspiration: the author modeled it on CADGetFilename from CADabra, a well-known node that does the same trick for CAD-oriented packs. Where CAD loads store a name in their own metadata, this one reads the file_name that GeometryPack's own loaders stamp into the mesh's metadata dict when they load it.

How it works

You feed it a mesh, it looks at mesh.metadata['file_name'], strips the extension, and gives you back the bare name. Wire it after any loader - Load Mesh, Load Mesh Batch, Load Mesh (Path), Load Mesh (Glob) - since they all record where the file came from. If a mesh somehow has no recorded name, you get "unknown" instead of a crash.

The output, filename, is a STRING list. That's deliberate: the node's INPUT_IS_LIST flag means it accepts a list of meshes in and returns a list of names out, one per mesh, in the same order. So in a batch pipeline you get matching meshes and filenames lists that stay index-aligned - pair filename[i] with mesh[i] and you can reconstruct the original naming scheme.

The one input that matters

Just mesh - a TRIMESH, or a list of them. No knobs, no options. It's about as simple as a node gets, which is exactly why it's easy to skip and painful to miss.

Where it pays off:

• Batch save with real names - feed its output into the pack's Save Mesh Batch node so every processed mesh keeps its source name.
• Logging / bookkeeping - wire filename into a string node or the console to know which mesh a given quality metric belongs to.
• Filename-based logic - you could split the list on names to route certain meshes down different branches, though at that point you're building flow control in a graph and should be honest with yourself about how far to go.

Install and context

It ships in GeometryPack, so install is the pack's standard routine: search "GeometryPack" in ComfyUI Manager, or clone and run the manual steps:

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 ComfyUI afterward. The pack leans on the experimental comfy-env installer (it pulls pixi and builds an isolated environment with heavy 3D dependencies on first launch), so give the first startup time. It's also GPL-3.0-or-later - free to use commercially, share-alike if you redistribute modified copies.

The only real gotcha is ordering: this node reads metadata written by GeometryPack loaders. If you construct a mesh some other way - say, a bare TRIMESH from a primitive or a conversion node with no file behind it - there's nothing to read and you get "unknown". That's not a bug, it's the nature of the job.

Unglamorous, zero-config, and the difference between "I can find my files" and "I have fifty meshes named output_1 through output_50." Add it to the batch templates that matter.