Determinism
One frame loop feeds every format, and frame time is exactly index / fps —
never wall-clock.
That one decision produces a set of guarantees you can rely on.
What it guarantees
Two exports are identical
Render the same project twice on the same machine and you get the same frames. There is no “re-render and hope it looks the same”. (Across different GPUs and drivers, tiny rounding differences are possible; the guarantee is about the frame being a pure function of the project, not about every graphics driver rounding identically.)
A re-render resumes identical work
If a render is interrupted — a crash, a power cut — restarting it produces exactly the frames the first attempt would have. Nothing drifts.
The preview is the export
The viewport, the pop-out viewports, the secondary view panes, the export preview dialog, the Render Queue and the command line all draw from the same engine, evaluating the document the same way.
They are not two renderers kept in sync. They are one renderer called from several places — which is why “the export doesn’t match the preview” is not a class of bug that can exist here.
Particles are reproducible
A deterministic emitter means the same frame always produces the same field. Scrub backwards and you see the truth, not a different roll of the dice.
The renderer can be tested against reference images
A golden-frame gate renders a catalogue of scenes through the native engine and compares them to committed reference frames. That is only possible because the same input always produces the same output.
What it means for you
| Situation | Consequence |
|---|---|
| A client asks for a change to one shot | Re-render just that range; it will cut against the old material exactly |
| You render a review copy and then a master | The master is the review copy at higher resolution, not a different take |
| An export failed halfway | Restart it; nothing about the first half was arbitrary |
| Someone else renders your project | The same frames, up to rounding differences between GPUs and drivers |
The refusal rules
Determinism is one half of the design. The other half is refusing to produce a plausible-looking wrong result:
- Every path asserts on a real frame count. A zero-frame encode is an error, not a silently successful black video.
- The engine stops with a named reason if it has no usable GPU, rather than handing the encoder an untouched canvas.
- The export preview reports empty frames before anything is written.
- Proxies never reach output. Substitution is something the interactive viewport asks for; export, the Render Queue and the command line reach full resolution by doing nothing, so there is no opt-out to forget.
The underlying rule, stated in the codebase’s own conventions: producing a plausible-looking wrong result is considered worse than failing.