Render OpenPose from SMPL Multiple

The pack has two ways to draw stick figures, and this is the good one. Render OpenPose from SMPL Multiple takes the SMPL_MULTIPLE_SUBJECTS output from Human4D_Img2SMPL and renders genuine OpenPose-format skeletons for every person, in every frame, with heads included. It's the "real openpose" the README contrasts with the fast pseudo-OpenPose preview - the one that actually matches the OpenPose format that ControlNet preprocessors expect.

The trade is cost. The pseudo-OpenPose path (via Motion Data Visualizer) is cheap but has no head and doesn't truly match the format. This node goes through the full SMPL estimation, so the skeletons are anatomically anchored to the recovered 3D body - and the README is candid that it's "better overall but requires gradient-based optimization" upstream (that's the SMPL fitting stage in Human4D_Img2SMPL).

How it works

When Human4D_Img2SMPL runs, it doesn't just keep meshes - it stores the HMR2.0 2D keypoints and detection boxes in the multi-subject metadata as a ready-made rendering function. This node simply calls that: it maps the 44 estimated keypoints onto OpenPose's 25-joint body layout, redraws each detected person's skeleton into their bounding box, and composites all subjects onto a per-frame canvas. Clever bit of plumbing - the render logic travels with the data.

The inputs that matter

• smpl_multi_subjects - the only input. It must come from Human4D_Img2SMPL, because that's where the render_openpose callback is baked in. Feed it a SpectreImg2SMPL output and the node raises NotImplementedError - there's no keypoint data for faces.

Output: IMAGE - one OpenPose frame per input frame, ready for an OpenPose ControlNet.

Installation

Part of Fannovel16/ComfyUI-MotionDiff. Install via ComfyUI Manager (search "ComfyUI MotionDiff") or clone into ComfyUI/custom_nodes, install requirements, restart. The upstream estimation stack is the heavy part - HMR2.0, YOLO, and their first-run downloads.

Gotchas

Two honest caveats from people who've actually run this. First, the joints can jump on individual frames - occasional keypoint flailing that shows up as a twitching skeleton. It's a known HMR/version-1 behavior, so if one frame's pose goes wild, either smooth it or regenerate that section. Second, it's not a shortcut: you must run the full image-to-SMPL estimation first, which is the slow, GPU-heavy part of the pipeline. Use the pseudo-OpenPose preview to check your idea cheaply, and save this node for when you genuinely need proper OpenPose conditioning.