🧵 Sync Sibling Weights (UV-seam unification)

Hollow, see-through gashes on a rigged character that look fine in the bind pose. That's the symptom. The cause is subtler than it looks and it isn't your rigging.

To texture a generated mesh you first have to UV unwrap it, and the standard tool for that (xatlas) cuts the mesh along UV seams. Cutting means duplicating vertices: two vertices sit at the exact same 3D position, share the same skin, and differ only in their UV coordinate. If your auto-rigger scores them independently - and a bone-distance weighting pass will, because it's working vertex by vertex - the two halves of the seam can end up on different bones. Animate, and they move at different rates. The seam rips.

In the author's own verification run, 662 of 2,799 sibling groups had mismatched joints or weights. That's a lot of rips waiting.

RaySyncSiblingWeights walks through and forces coincident siblings to agree.

How it works

It reads the GLB binary with NumPy - no Blender, no GPU, no torch - groups vertices by their 3D position rounded to five decimals, and for every group with more than one member it merges the (joint, weight) pairs from all siblings, sums the weights per joint, keeps the top four, renormalises, and writes those identical values back to every vertex in the group. Same shape and dtype, so it's an in-place overwrite of the JOINTS_0 and WEIGHTS_0 buffers. The GLB is rebuilt and written to output/stage4a2_sync_weights.glb.

It's a 40-line idea and it's the correct one. Two vertices that occupy the same point should never disagree about which bone moves them.

Where it fits: right before the animation is applied. In this pack's weight-surgery pair, RayCleanWeights handles the anatomical errors and this one handles the topology-induced ones - so clean first, sync second.

Inputs and output

Required: rigged_glb_path, a STRING socket for a SOMA-rigged GLB. Wired, not typed.

Output: output_path, a STRING pointing at output/stage4a2_sync_weights.glb. From there, KimodoExportFBX.

If you don't have a rig/weights yet, this node is inert - it needs JOINTS_0 and WEIGHTS_0 present on the first mesh primitive. It's a post-rigging, pre-animation step, not part of making the rig.

Install

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/JayDataEngineer/melite-autorig-nodes.git

Restart ComfyUI, or use Manager and search "melite". The pack lists trimesh, scipy and requests in requirements.txt; this node uses none of them, so it runs on a stock install. No Blender binary required.

Where people get burned

"Coincident" means exactly coincident. Grouping rounds positions to five decimals. If your exporter dithered the duplicated vertices slightly - or you passed the mesh through a tool that applied a tiny transform - the groups won't form and the node does nothing visible. It's not silent about it, though: the log prints how many sibling groups it synced. If that number is 0 and your mesh definitely has seams, that's your answer.

First mesh, first primitive, first skin. Same limitation as every binary-surgery node in this pack. Multi-part GLBs get one part processed.

Fixed output filename. stage4a2_sync_weights.glb, overwritten on every run. Rename it if you want to keep a before/after pair on disk.

Order matters more than you'd think. Doing this after the cleanup pass is the safe sequencing, because a sync can pull a torso vertex's weights toward an arm-heavy sibling. Run clean, then sync, then animate. It's also cheap enough - pure NumPy on a mesh-sized array - that you can just leave both nodes in the graph permanently rather than remembering them.

It cannot fix a bad rig, only an inconsistent one. If both siblings agree on the wrong bone, they'll move in perfect, seamless unison - in the wrong direction. This pass makes seams move together; RayCleanWeights is what decides where they should move, and neither of them substitutes for a look at the thing animating.