Long Holes Finder

What it's actually for

There are two kinds of hole in a generated mesh, and they need different treatment. Little ones - a few triangles missing where the reconstruction got vague - you just fill. Big ones are structural: the model never reconstructed the bottom, or the whole back of the head is a curtain. Fill those and you get a weird stretched membrane that ruins the silhouette.

LongHoles is the diagnostic for the second kind. Point it at a mesh and it tells you the size of every boundary loop, in vertices. It's the node you run before remeshing a scan or a generated asset, so you know whether "it's got holes" means "two of them, 8 vertices each" or "one of them is 4,000 vertices long and you should be deleting it, not closing it".

How it works

Boundary detection is done the cheap, reliable way: sort every edge, count the occurrences, and any edge used by exactly one face is a boundary edge. That set gets pushed into a networkx graph, and cycle_basis pulls out the closed loops - one entry per hole, with one vertex per position on the loop.

Then it does one of two things:

• fill_holes off (default) - the mesh comes back geometrically identical, but the vertices on any loop with at least min_edges vertices are painted red. That highlight is the output. Load the mesh in the pack's 3D preview and the bad boundaries light up in place, so you can see where they are rather than counting them.
• fill_holes on - it calls trimesh.repair.fill_holes and closes everything it can, reporting Holes filled. No highlighting, no discrimination: every loop gets a lid.

The report string lists every loop it found with its vertex count, e.g. Hole 0: 412 vertices. That's the actual product. Read it.

The inputs that matter

• mesh - your TRIMESH.
• min_edges (default 3, 3-1000) - the threshold for "long enough to care about". Only loops at or above this many vertices get highlighted. Raise it to 100 and you're only seeing the structural gaps, which is the useful view on a messy scan.
• fill_holes (default off) - flips the node from diagnostic to repair. Keep it off while you're investigating.

Outputs are mesh and report. To actually use the highlight, the mesh has to go somewhere that renders vertex colours - the pack's own 3D view save/load node (Ultimate3DViewSaveLoad) does.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Antonioilev/ComfyUI_Antonioilev_Lightpack.git
# restart ComfyUI

Manager search: "Antonioilev Light Pack". There's no requirements.txt in the repo and __init__.py swallows import errors, printing only a loaded/failed count - so a missing dependency looks like a missing node. This one needs networkx:

pip install networkx

Where people get burned

• Hundreds of loops means the mesh is split, not holed. On an unwelded mesh, every UV chart boundary reads as a boundary edge loop. Weld with AntonioilevUVWatertight first, then re-run - the count usually drops from hundreds to a handful.
• Filling a structural gap makes things worse. A 4,000-vertex boundary is not a hole, it's a missing side. Fill it and you'll get a big flat or crumpled lid that no remesher will fix. Delete the offending region, or accept the open shell, or remesh from a different source image.
• Vertex-colour-based output needs a viewer that reads it. If you pipe the highlighted mesh into something that ignores vertex colours, you'll see the original mesh and conclude the node did nothing.
• min_edges filters the highlight, not the report. All loops are listed in the report string regardless, which is handy - you get the full census even when you only painted a few.