Loops & feedback
Repeat a piece of your graph: once per element, a fixed number of times, or by feeding each frame's result back into the next.
Running the same recipe a number of times, building something up over a dozen passes, or letting a frame react to the frame before it are two tools: for-each loops and feedback loops.
Many copies of something laid out in space is a third thing, instancing, not a loop.
For-each loops
A for-each loop is a Start node, a body of nodes, and an End node. Whatever sits between Start and End runs once per pass, and the End gathers the results.
Two ways to set the count:
For runs a fixed number of passes.
For Each runs one pass per thing plugged in. The loop reads the wire: a list runs once per item, text runs once per character, a shape collection runs once per shape. Plugging in the input is the answer, so there is nothing to declare.
For Each is the mode a freshly-placed Start node is already in, and with nothing wired to iterate it sits idle rather than erroring, so a half-built loop is quiet until you feed it.
The Start node publishes where you are as outputs, not as attributes. $index is the current pass number, 0-based, in both modes. item carries the thing being iterated in For Each mode: the list element, the character, the number, the entity. Wire either into the body to vary each pass, nudging a copy further, rotating it more, tinting it differently.
A third output, result, hands the finished loop back at the top. Once every pass has run, the accumulation the End node built lands on the Start node's result pin, so a loop reads as a circle rather than a line and downstream work can pick it up where it began.
At the End node you pick how the results come together, with Mode:
Collect gathers every pass's value into a list.
Concat joins string values end to end, which is how an L-system builds its string.
Merge Collection merges each pass's collection into one, stamping every row with
@index,@normalizedand@totalso downstream per-element work can still tell which pass a row came from.Merge Entities writes attribute changes made inside the loop back onto the source collection. Only a For Each loop walking a collection's entities can use it; anything else fails the cook rather than falling back.
More than one value can be wired into the End node. Each wire accumulates separately under the same Mode and gets its own matching output.
Keep the loop body small. Anything that doesn't change from pass to pass (a texture you load, a shape you import) is computed once and reused, so the loop only re-runs the parts that actually vary.
Feedback loops
A feedback loop sends a pass's output back in as the next pass's input, which is how you grow trails, smear paint, run reaction-diffusion, or accumulate anything over time.
Like a for-each loop it is a Start node, a body, and an End node. Each value carried round is a state. Wire its starting value into a slot on Start and the matching output on the same row hands the body the current value; wire the body's result into Feedback End and it becomes the next pass's input. Slots grow as you wire them, so several states travel round together. Feedback End also copies each input to an output of its own, and those are what downstream nodes read once the last pass has run.
One-Shot runs a fixed number of passes and stops. Deterministic and repeatable, so the result is the same every time.
Continuous keeps its state alive across frames on the timeline, and each frame picks up where the last left off. This is the classic feedback look: echoes, trails, things that build up as time runs.
While keeps going as long as a condition you wire in stays true, with a safety cap so it can never run forever.
Continuous feedback respects the timeline. Scrub backwards or jump around and the result stays honest, because playing forward and re-checking a frame you have already seen are treated differently, so edits to your settings still show up without corrupting the build-up. Continuous mode also carries a Reset trigger that returns the state to its initial values, which is what you use when a trail has filled the screen.
The Start node's own outputs are $iteration, the 0-based pass number, and $delta_time, the time step this pass is being solved over. In Continuous mode with Substep Delta Time on, that step is the frame's delta divided by the iteration count, which is what a physics substep wants.
Feedback works on images and volumes as well as geometry. Each frame's rendered result is handed into the next pass without manual ping-ponging.
Choosing between them
Run a recipe a set number of times, or once per element, and gather the results: a for-each loop.
Each frame builds on the last (trails, sims, growth): a feedback loop. One-Shot for repeatable, Continuous for timeline-driven.
Many copies of a thing laid out in space: instancing.
Loops get expensive fast. Cap your pass counts, and prefer One-Shot feedback when you don't need cross-frame state. A heavy loop left on Auto Cook re-cooks every frame whether or not anything is looking at it, which is the usual culprit when playback gets sluggish. See The graph & cooking for the cook indicator that sets this.
See also
Copying & instancing for many copies, the non-loop tool