MixavisdocsHomeCommunityOpen editor
Concepts

Time and the playhead

One clock drives everything, and that is why the export matches the preview.

There is exactly one source of time: the playhead position on the timeline. Every driver, every shader, every simulation reads that value and nothing else. Nothing anywhere reads the wall clock.

That sounds like an implementation detail. It is the reason three things work.

Scrubbing shows the truth#

Dragging the playhead to 4.2 seconds evaluates every layer at 4.2 seconds. You are not seeing an approximation or a cached frame — you are seeing the frame. A wiggle sampled at that moment is the wiggle that will render there.

The export matches#

Rendering walks the same clock in fixed steps. A four-second composition that takes four minutes to render produces exactly what you watched, because neither pass consulted anything that was moving on its own. A single node reading the wall clock would break this, and the breakage would only show up in the finished file.

Frame rate is a sampling decision#

The composition is continuous. Frame rate decides how often it gets sampled. That is why changing from 30 to 60 does not change any of your timing — the same curves are simply measured twice as often.

It does change how motion reads, though. Fast movement at 24 fps strobes in a way that at 60 fps it does not, so the frame rate you will deliver at is worth choosing before you tune fast motion rather than after.

The two exceptions

Fluid, and Melt in Liquid mode, accumulate state across frames instead of being pure functions of time. They are still deterministic — the same input gives the same output — but jumping backwards means re-running from the start, so scrubbing them is not instant.

Seconds, not frames#

Keyframes are stored in seconds. Changing the composition frame rate therefore does not move them and does not silently retime work. It can leave a keyframe sitting between two rendered frames — snap to frame if you need a change to land on an exact one.