🦴 Poser Bind Mesh (bind-pose vertices+faces)
The rest-pose body with no deformation, and why 'soma' needs it
- mesh
Sometimes you don't want a pose. You want the mannequin. Poser Bind Mesh loads the identity model's bind-pose mesh - vertices and triangle faces, no joint deformation applied - as a typed MESH value you can render, inspect, or hand to something that needs geometry rather than joints.
Its real job in the pack is being the escape hatch for the soma identity. The SOMA NPZ engine loads a static mesh and doesn't support linear-blend deformation at all, so PoserDeformSoma will fail on it. This node just returns the engine's loaded vertices and faces directly and moves on. If you're working with anny or mhr, you get the same convenience without the constraint.
How it works
It calls the pack's shared SkinEngine for the requested model and reads engine.vertices and engine.faces straight off it. Those attributes are the current state of the cached engine, loaded at construction for the NPZ path or reshaped by the parametric layer for anny/mhr - so what you're getting is the neutral bind pose at whatever identity the engine is holding.
It validates both arrays before returning: vertices must be (V, 3), faces must be (F, 3), and a wrong shape raises instead of handing garbage downstream. That's consistent with the rest of this pack, which is unusually loud about malformed geometry.
There's also a small UI payload (ui.poser with op/identity/vertex count/face count) so a front-end can show what got loaded. In plain ComfyUI you'll see it in the node's log output.
Inputs and outputs
identity_model- a combo, and the only input there is. Choices aresoma,anny,mhr, defaulting tosoma.
One output: mesh, typed MESH, as a (vertices, faces) tuple with vertices float32 (V, 3) in centimetres and faces int32 (F, 3).
Note what's not here: no coefficients, no detail morphs. If you want a shaped body you want PoserBindPose (joints) plus PoserDeformSoma (deform), not this. Poser Bind Mesh is the neutral rest state, which is exactly why it's the safe thing to render when you want a scale reference or a silhouette to compare a generated mesh against.
Install
cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/JayDataEngineer/melite-poser-nodes.git
Restart ComfyUI, or find it in ComfyUI Manager under melite-poser-nodes. py-soma-x[anny] comes in via requirements.txt - needed for anny and mhr, not for soma, which reads the NPZ directly. Either way, the identity weights have to be present locally or the engine won't construct.
Where people get burned
The engine is a singleton, so "the current state" is shared. get_engine() caches one SkinEngine per identity model for the life of the process and reuses it across every node execution. If something else in your graph has reshaped the identity, this node reads whatever the engine currently holds - the pack's own comment on the cached template loader makes the same point: treat shared arrays as immutable. Practically, don't wire PoserBindMesh into a graph where another branch is actively shifting shape coefficients and expect a pristine neutral every time.
Centimetres, again. Output is cm, matching the rest of the MESH contract in this pack and the input expected by PoserRender. Hand it to a tool expecting metres and you get a 100× scale surprise, not an error.
It's not an output node. No OUTPUT_NODE flag, so it only runs when something downstream actually consumes it. If you add it, wire nothing, and hit queue, nothing happens - that's expected, not broken.
mhr is the least-travelled option. SOMA and anny are the paths the pack's own pipeline exercises; mhr is supported by the engine's SUPPORTED set but you're off the tested road.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| identity_model | COMBO | soma | 3 options: soma, anny, mhr |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| mesh | MESH | — |