Tora Encode Trajectory

This is the node that makes Tora fun. You give it a path - a set of coordinates tracing where you want motion to go - and it turns that path into features CogVideoX can actually follow. Draw a curve from bottom-left to top-right and your subject arcs across the frame the way you drew it. That's the "trajectory-oriented" part of Tora made concrete, and it's the reason people bother with CogVideoX for motion work.

How it works

Tora conditions the video model on a motion trajectory, and this node is where your drawn path becomes that condition. It takes the coordinates, rasterizes them across your target resolution and frame count into a flow field, then encodes that field through the VAE and the Tora model into trajectory features. The sampler reads those features and biases the generation so the subject moves along your line. Think of it as the motion equivalent of a ControlNet hint: not a hard constraint, a strong suggestion the model mostly honors.

The inputs that matter

The load-bearing input is the path itself:

• coordinates (a STRING) - the point list that defines your path. You don't type this by hand. It comes from a spline or point editor upstream (KJNodes' spline editor is the usual source), which lets you draw the curve on a canvas and outputs the coordinate string this node consumes. That's the whole interaction: draw, connect, render.
• width (720), height (480), num_frames (49) - these must match your generation. The path gets rasterized at this resolution over this many frames, so if these disagree with what the sampler produces, the motion lands in the wrong place. Keep them in sync with the rest of the workflow, and note 49 frames is CogVideoX's happy native length.
• strength (default 1) - how hard the model is pushed to follow the path. 1 is the honest default. Turn it down if the trajectory is overpowering the scene and making motion look robotic; the Tora authors' own sample workflows lean on fairly gentle guidance.
• start_percent (0) / end_percent (1) - the slice of the denoising schedule the trajectory is active over. Defaults apply it the whole way. Narrowing the window lets the path guide early structure and then hand off to the model, which can help when strict guidance is fighting natural motion.

There's one optional input, enable_tiling (default on), which tiles the VAE encode to keep memory down - leave it on unless you have a reason not to.

The outputs

Two of them:

• tora_trajectory (type TORAFEATURES) - the encoded path. This wires into the tora_trajectory optional input on the CogVideo Sampler. This is the one that does the work.
• video_flow_images (an IMAGE sequence) - a visual preview of the flow field the node generated. Pipe it to a preview or video-combine node and you can see the path it built before committing to a full render. Genuinely useful for catching a wrong-direction path early.

Common issues & troubleshooting

The subject flies toward the camera or warps instead of moving cleanly. A classic Tora gotcha reported early on: if your path's shape grows in size as it traces (the drawn dot getting bigger), the model reads that as forward/Z-axis motion and the scene warps. Keep the path marker a consistent size along the curve, or use the trailing/consistent-shape option in your spline editor.

Nothing moves along the path, or it barely moves. Two usual causes. Either coordinates isn't actually connected to a live editor output, or strength is too low. Also worth setting expectations: Tora is hit-or-miss by nature. Early testers said it straight - some image-and-path combos give great results, others come out strange or barely move, so don't expect a clean take every single time.

Motion is in the wrong spot. Almost always width/height/num_frames not matching the sampler. The path is rasterized at these dimensions; mismatch and it maps to the wrong coordinates. Check the video_flow_images preview to confirm the path looks right before a full run.

Out of memory. Leave enable_tiling on, and remember CogVideoX-5b plus Tora is already heavy - fp8 and offloading at the loader do more for VRAM than anything here.