📦 Load Mesh (Scanner + FBX)

What it's actually for

So you generated a mesh, or downloaded one, and now you want to work on it inside ComfyUI instead of shipping it to Blender and back. This node reads it off disk and hands it to the graph - .glb natively, .fbx via a conversion hop - and it prints a scan of what it found, which is more useful than it sounds.

It's the "start here" node of the pack's mesh half. Everything downstream (remesh, weld, UV, hole tools) wants a TRIMESH, and this is one of the few ways to get one without a 3D generator in the graph.

How it works

You give it a path string. It strips quotes, and - the detail that tells you where this was written - any Windows-style path like L:/AI_3d/foo.glb gets rewritten to /mnt/l/AI_3d/foo.glb, so it works from a WSL ComfyUI with the drive mounted. Then:

• .glb / .gltf / other → straight through trimesh.load(..., process=False), deliberately not reprocessing the mesh.
• .fbx → shells out to the Assimp CLI (assimp export in.fbx tmp.glb), loads the temp GLB, and deletes it. No Assimp on your PATH, no FBX.

If the file loads as a trimesh.Scene (the usual case for GLB with multiple parts), every geometry in the scene is concatenated into one mesh so you get a single object downstream.

Then comes the scanner, and this is the part worth knowing about. It walks the vertex attributes of each geometry looking for joints, weights, or joint_indices, plus skeleton/skin metadata, and reports:

Mesh: 48213v | Skin Data: STRICT_YES

If you're feeding a rigged character into a pipeline, that line is your only warning that you're about to throw the rig away - everything downstream here works on a plain trimesh and none of it carries skinning.

Finally it does a deliberately minimal cleanup: NaN/inf vertices are zeroed, out-of-range face indices are dropped, and the mesh is rebuilt with process=False. It specifically does not remove unreferenced vertices, because the author wanted feature-map/curvature arrays to stay index-aligned with the vertex list. If the face list ends up empty, it substitutes a dummy triangle rather than letting a downstream Open3D call hard-crash.

The inputs that matter

• mesh_path - the tooltip says it plainly: "Path to .glb or .fbx". Plain filesystem string, not a ComfyUI input/ filename. Point it at an absolute path.

Outputs are mesh and info. The info string carries vertex count and the skin-data verdict.

Watch the types. The node declares its output as the core MESH type, but what it builds and returns is a plain trimesh.Trimesh. The pack's own processing nodes all want TRIMESH. If a socket refuses to connect to a TRIMESH input, that's why, and you'll need whichever converter node your graph uses for that.

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 and __init__.py catches import errors with a printed count, so the node simply not appearing means a Python dependency is missing. Here, trimesh. And for FBX you need a system binary, not pip:

# Debian/Ubuntu
sudo apt install assimp-utils
# or grab the assimp CLI from https://github.com/assimp/assimp/releases
assimp version   # verify it's on PATH for the user ComfyUI runs as

Where people get burned

• File not found on an FBX that clearly exists - usually Assimp isn't installed, or isn't on the PATH of the ComfyUI process (different users and systemd services are the usual culprits).
• The WSL path rewriting is one-way. Windows drive letters get converted for you; a Linux path is used as-is. Mixed setups are where paths go weird, so use absolute paths and skip the ambiguity.
• Reloading the same file can look like a no-op. ComfyUI caches node output; if you edit the mesh in Blender and re-run, force a re-execution or the cached result comes back.
• Backslashes in pasted Windows paths. Quotes are stripped, but forward slashes are the safe input.