Why the preview isn't always exactly the render

The editor's canvas is fast because it isn't Manim. It's a quick stand-in that redraws instantly while you drag things around, so you can compose and time a scene without waiting. The render is the real thing — the actual frames that ship.

Two different tools doing two different jobs. The gap between them is small in most everyday work, but it isn't zero. This page is an honest map of exactly where it is, so a difference between what you edited and what came out doesn't look like a bug when it's expected.

Formulas: very close, not identical

The editor and the render use two different maths typesetters. For ordinary notation they look nearly the same, which is why you can lay out an equation in the editor and trust it. But they are genuinely different engines, so an unusual construct can come out slightly differently — or, rarely, work in one and fail in the other.

Treat the preview as "very close to" the final render, not a pixel-for-pixel promise.

3D objects: shading differs

3D objects are drawn in the editor by a separate, fast 3D view with its own lights and materials. Manim shades them its own way. These aren't the same lighting model twice — they're two independent approximations.

Expect the shape, size, and position to match. Expect exact shading, highlights, and edge darkening to differ once you render.

3D matrix transforms: the canvas shows the flat part

A 3×3 matrix in a 3D scene can push geometry out of the flat plane. The editor's canvas can only show the flat, two-dimensional part of that movement — anything lifting out of the plane stays invisible until you render, where the full transformation is applied.

See Animate a linear transformation for the workflow.

Derivations: a switch in preview, a slide in the render

This is the biggest gap in the app, so it's worth knowing.

When a derivation moves to its next step, the render slides the matching terms to their new places and fades the rest — the whole reason to use a derivation. The editor can't reproduce that. While scrubbing, a step change looks like the whole equation snapping instantly from one line to the next.

So the preview here doesn't just look slightly different — it looks like a cruder animation than the one you'll get. Render to see the real thing.

Embedded video: a placeholder while editing

A video object shows as a labelled box in the editor, not the clip playing. Place, size, and trim it by that box; the clip plays in the render.

The 3D floor is editor-only

The floor, grid, origin axes, and drop lines in a 3D scene are there to help you judge depth and position while working. They are never rendered into your video.

What about exported images?

Saving a frame as an image does not share these limits in the way it once did. Formulas are captured as properly typeset maths, and 3D objects are included and redrawn at full quality. What you get is a faithful copy of the editor's view — so the shading and formula notes above still apply, but nothing is missing from the picture. See Export a single frame.

Why the split is deliberate

None of this is the preview being "wrong." The canvas's job is fast iteration — drag something, time it against something else, scrub the whole scene, all instantly. That would be impossible if every keystroke waited on a real render. The render's job is truth.

Keeping them separate is what makes editing feel fast. The cost is that a few specific things need a real render before you can fully trust them. Once you know which, "render to check" stops being a surprise and becomes the normal last step.