TF Generate

This is the node the whole pack is built around, and the first thing you'll notice is what it doesn't do: it returns no image. TF Generate samples one trajectory - a stack of four latent levels, coarse to fine - and hands the whole thing to whatever comes next on a TF_LEVELS socket. To actually see it you run TF Decode Levels afterwards, and to poke at it you run the edit nodes. Think of it less as a txt2img node and more as the seed of a small data structure.

The mechanism is what makes Trajectory Forcing interesting in the first place. Instead of denoising pixels, the model walks a hierarchical DINOv2 latent space in four passes: level 0 is object and background, then parts, then subparts, then the finest tokens. Each level is one network evaluation conditioned on the level below it. Because the RAE decoder is frozen and can decode any point in that space, every one of those intermediates is a real picture - not noise on the way to a picture. That's the whole trick that lets you edit a level, resume from it, and keep everything below untouched.

So the inputs are minimal on purpose. pipeline comes from TF Load Pipeline. class_id is an ImageNet-1k class in 0–999 - this model is class-conditioned, there's no text prompt anywhere - and seed (default 592) drives sampling. Wire TF ImageNet Class in to pick the class by a name you can actually remember, because "213" is not memorable and the default, an Irish setter, gets boring fast. The tooltips spell out the contract that matters for experiments: re-sampling with the same seed and class reproduces a trajectory exactly. That reproducibility is the foundation of every comparison and sweep in this pack - if you can't regenerate the baseline, you can't tell an edit's effect from a seed's.

The single levels output carries more than the four latent arrays. Each trajectory remembers its class, its seed, and a running history of what was done to it (an edit marks it "dirty" until TF Resume From Level runs). It also carries the pipeline that made it, which is why most downstream nodes need no pipeline wire - the socket only exists as an override, and for trajectories restored by TF Load Levels that have no pipeline attached.

Worth knowing before you queue it: the first TF Generate after load can feel like a hang for a minute or two while XLA compiles the sampler. TF Load Pipeline's warmup option (on by default) pays that compile at load time under a progress bar instead, so leave it on. And on a small card, remember the VRAM profile: roughly 2.5 GiB for the model, 4.6 once the sampler has compiled, 6.6 once you decode. 8 GB is the stated floor and 12 GB is comfortable; on an 8 GB card keep this the only model in the graph.

Install

This pack is not a normal one-click custom node. It runs a JAX model inside the ComfyUI process, which only coexists with ComfyUI's torch on CUDA 12 at torch 2.8+, so it usually needs its own Python 3.11 environment. requirements.txt is empty on purpose so a Manager install can't rewrite the torch your other nodes depend on. Manager → search Trajectory Forcing → Install works when install.py judges your existing torch compatible; otherwise it changes nothing and tells you why, and the README's env/setup.sh route builds a separate venv. Either way the model code and weights are fetched on first use - the flow checkpoint (~2 GB) and RAE decoder (~1.6 GB) - and the first run of the whole stack sits behind the warmup progress bar.

The fastest self-diagnosis if anything is off is the pack's own doctor:

cd ComfyUI/custom_nodes/ComfyUI-TrajectoryForcing
python -m tf_nodes.doctor

If a trajectory comes back wrong, don't reach for it alone - wire TF Compare Levels between it and an earlier one; it tells you per-level and per-token what actually moved.