Split Tracking Points

Split Tracking Points is the node that makes pose-driven DragNUWA work: it takes a pose keypoint sequence - loaded by Load Pose KeyPoints - and converts it into the tracking-points JSON that DragNUWA Run can eat. Its whole job is to read a person's joints across a window of frames and turn each joint's movement into a drag trajectory.

The mechanism is worth understanding because it explains the node's quirks. Each pose frame has per-joint 2D coordinates plus a confidence value. The node walks joint by joint across 14 frames of pose data (the split_index selects which 14-frame window you're in), and for each joint it builds a path: if the joint is visible and confident in a frame, the point goes in; if it's below confidence, the path is stopped rather than filled with garbage. Joints whose coordinates fall outside the width/height you declared also break the trajectory. The result is one JSON string listing the surviving joint paths, ready to paste into the run node. The optional last_pose_kps input exists to stitch the previous window's final pose onto the start of the next, so multi-window sequences stay continuous.

The inputs that matter

• pose_kps - the POSE_KEYPOINT value from Load Pose KeyPoints.
• split_index - which 14-frame window of the pose sequence to convert. Frame 0 means the first 14 frames; bump it to continue into the next chunk.
• width / height - the coordinate space, defaults 576x320. Points outside this box get dropped, so set them to match your checkpoint dimension.
• last_pose_kps - optional; a previous window's pose to anchor continuity.

Output

tracking_points - a STRING in the exact JSON format DragNUWA Run expects. Note this node is marked as an output node, so it also displays the text in the UI; that's convenient, since you can eyeball the trajectories before they hit the model.

Where the cracks are

This is the pack's roughest corner, and I'd tell you to set expectations accordingly. It assumes one person - it reads people[0] only - and it only follows joints that stay confidently visible, so occluded limbs just end their trajectory instead of being estimated. The pose JSON format is the OpenPose convention, but nothing here validates it: feed it a different schema and the node either silently produces an empty path or throws. The README documents none of this, and the pose half of the pipeline (producing the keypoint JSON in the first place) is entirely on you.

For a clean single-subject clip with visible joints, though, the pipeline works - pose in, drag paths out, and the character in your still follows the reference motion. It's the closest thing this pack has to "motion transfer," and if that's the effect you want, Split Tracking Points is the only door in. For everything else, the trajectory tool and instant brushes are far less fragile.