FL CoTracker

FL_CoTracker wraps Meta's actual CoTracker model - the node's own description points straight at facebookresearch/co-tracker - and puts point tracking inside a normal ComfyUI graph. Give it a sequence of frames and it'll follow points across them: where a point moved, whether it stayed visible or got occluded, frame by frame. This isn't a generative node; it's a measurement tool that feeds other nodes.

The obvious use case is motion-controlled video generation. Track a point (or a grid of points) across a source clip, and hand that trajectory data downstream to a model that accepts motion conditioning - trajectory-based control for something like WAN, or a mask built from where a tracked region stays visible for masked sampling later in the pipeline. It shows up in exactly that kind of pipeline in the wild too: people building motion-transfer workflows chain WAN, a trajectory-control step, CoTracker, SAM2, and VACE together to move objects around a scene frame-accurately. It's plumbing, not a generator - but it's the plumbing a lot of "make this object move along this path" workflows are actually built on.

The inputs that matter. images is your frame sequence. grid_size (0–100, default 20) auto-seeds a grid of tracking points across the frame - set it to 0 if you'd rather rely entirely on hand-specified points or a mask instead of an automatic grid. tracking_points is a text field for specifying points manually. max_num_of_points caps how many points get tracked at once, which matters directly for memory. On the optional side, tracking_mask restricts where grid points get seeded, min_distance and confidence_threshold filter which auto-seeded points survive, enable_backward runs tracking in both time directions for more robust results (at extra compute cost), and force_offload - on by default - unloads the model from VRAM once it's done, which is the right default to leave alone unless you're chaining several CoTracker calls back-to-back.

Two outputs: tracking_results, the raw track data as a string for whatever downstream node consumes it, and image_with_results, a visualization with the tracked points drawn onto your frames - worth checking before you trust the raw data going anywhere important.

Installing it follows the same pattern as the rest of Fill-Nodes: search "Fill-Nodes" in ComfyUI Manager, or clone by hand -

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

• then restart ComfyUI. This one's heavier than most of the pack's utility nodes, since it's a real deep model rather than a plain image-processing wrapper: expect the first run to pull down CoTracker's checkpoint from Meta's repo before it can track anything.

Where people get burned. The node's own tooltip says it outright: if you hit an out-of-memory error, lower grid_size - fewer tracked points means less memory, and it's the single knob most worth reaching for first. That's not a hypothetical either; a public tutorial chaining WAN, ATI, CoTracker, SAM2, and VACE for motion-controlled animation specifically flagged "memory errors" as one of the recurring troubleshooting moments in that kind of stacked pipeline, which tracks with how heavy multi-model video workflows tend to run in general. If you're combining CoTracker with several other heavy nodes in the same graph, budget VRAM headroom accordingly and leave force_offload on rather than turning it off to save a few seconds between runs. And if your tracking results look noisy or unstable, min_distance and confidence_threshold are your filtering knobs before you touch anything upstream - a tighter confidence_threshold throws out the shakier auto-seeded points rather than trying to track everything the grid found.