Retargeting & Rigging (AnimoFlow)

Up to this point in an AnimoFlow workflow, you've got motion data - a BVH skeleton doing a walk cycle in a void. AnimoFlow_Rig is where it becomes a character: it takes your BVH plus a rigged character FBX and retargets the motion onto that character's skeleton, producing an FBX with the animation baked onto a real mesh. Type a prompt, get a rigged animation on an actual person - that's the promise the pack's README leads with, and this node is where it's fulfilled.

The retargeting runs in Blender, shelling out to a real Blender binary on the ComfyUI machine. That's the single most important fact about this node: it needs Blender installed and findable, or it fails with blender: command not found. On macOS the fix is usually setting BLENDER_BIN in .env to /Applications/Blender.app/Contents/MacOS/Blender. The retargeting script derives from the KeeMap Blender retargeting addon by Nick Keeline (GPL-3.0), and it handles the SMPL↔character mapping inside the retargeter container plus the native Blender-side retarget - the character FBX is the template your skeleton gets squashed into.

Inputs that matter

• bvh_b64 - the ANIMOFLOW_BVH from AnimoFlow_IK (or straight from AnimoFlow_Kimodo in 22-joint rig mode).
• character - a dropdown listing every .fbx in the pack's characters/ folder. Ships with Y_bot; drop any Mixamo-rigged FBX in there and it auto-appears in the dropdown, textures included.
• output_dir - where the FBX lands, default /tmp/animoflow-output.
• job_id - a free-form identifier, mostly useful for organizing output on shared setups; leave blank and it just uses whatever's handy.
• physics_tracking - optional, default off. Toggles a physics-based tracking pass for the retarget; leave it off unless your character has cloth or hair you need to follow the motion.

Outputs

fbx_filename (a path string) and character - and the character is deliberately re-emitted so that downstream nodes like AnimoFlow_GLBExport are wired to the one selection you made here rather than asking you to pick it again. That wiring detail is why changing the character only reruns the Rig and export stages - the model and IK outputs are cached and reused, which is a nice speed win when you're A/B-testing characters on the same motion.

The pipeline and gotchas

AnimoFlow_IK (bvh_b64) → AnimoFlow_Rig (fbx_filename) → AnimoFlow_GLBExport (glb_filename) → AnimoFlow_FBXToPreview3D → 3D viewport

The exported FBX is the raw animated character; it's the GLB that carries the production polish (snap-to-ground, trajectory restore, brand tint), so preview the GLB, not the rig FBX - the preview node's own docs spell this out, and it matters because three.js parses GLB natively while loading a Mixamo FBX in the browser can stall the tab for seconds.

The classic failure here, after blender: command not found, is a character that never appears in the dropdown. The characters_init service syncs the shipped characters into the shared volume on ./install.sh up, so if you cloned the repo after your containers started, restart them. And a note on the import trick: like AnimoFlow_IK, this node loads its retargeter lazily into the ComfyUI process - it's a native node, not a container call, and it needs the pack's requirements.txt installed. Container healthy doesn't help this node; Blender does.