Preflight — find out what will go wrong before the render starts

You set four hundred frames going overnight. In the morning: blank frames. Or frames missing half the scene. Or frames with no transparency because the format has no alpha channel. Or frames written on top of yesterday's. The cause is almost always one of a dozen known things, and every one of them was visible beforehand — if anyone had looked.

Preflight looks. It goes through the reasons a render comes out wrong, tells you which of them apply to this render, and then measures how long the job will take by rendering an actual frame.

Nothing will be visible

No camera, or the camera disabled for rendering. Clipping that cuts objects which are in frame — measured, with the distance and the clip value printed, not guessed. Everything in the scene disabled for rendering.

It will not look like what you see

Objects hidden in the viewport that will appear in the render, and objects you can see that will not be there. Collections excluded from the view layer. Texture files that are not on disk. Materials that reach no output and will render black. Subdivision set lower for the render than for the viewport, so the result is coarser than what you are looking at. An exposure or a look left over from a test. Simulations that were never baked, which are only correct when frames are rendered in order and never on a farm.

The result will not survive

An output folder that does not exist or cannot be written to. A relative output path in a file that was never saved. Transparency going into a format that has no alpha channel. Frames of this very range already sitting in the output folder, about to be overwritten — counted, so you know how many. A long animation going straight into a single video file, where a stop halfway leaves nothing usable. A frame range that ends before the animation does.

And how long it will take

This is the part that is measured rather than modelled. Preflight renders a real frame at your settings and reports what it took, then multiplies by the number of frames. No extrapolation, no assumptions about how time scales: on ordinary scenes render time barely depends on resolution until the scene gets heavy, so a small frame scaled up would be wrong. If even a quarter-size frame takes more than about twenty-five seconds, the full frame is not rendered and the number is labelled honestly as a lower bound.

Your settings come back exactly as they were

The probe changes the resolution, the output path, the format and a few flags while it runs, and restores every one of them, including the frame you were on. The add-on takes a fingerprint of all of that before and after and tells you if anything differs. That verification ships with the product; it is not a promise in a description.

Checked both ways

On a scene with eight deliberately planted problems it finds all eight and nothing else. On a healthy scene it reports nothing. Remove one problem and exactly that finding disappears while the others stay. All of it runs on Blender 5.1 and 5.2, on Cycles and EEVEE, with eighty-four checks green.

Compatibility

Blender 4.2 and later on Windows, macOS and Linux.

License

GPL-3.0.