How keyframes and time work

Every property animation in a project is the same small thing: a property, a starting value, an ending value, a moment to begin, and a duration. There are three ways to create one — the Animate a value panel at the top of the inspector's Anim tab, the ◆ diamonds next to each field, and ● record mode — and they all produce exactly the same kind of animation. What makes all three make sense is one idea: a starting value can be left open, meaning "start from wherever this property already is." Understanding that, and how animations on the same property chain together, is the whole mental model. The Graph Editor (see Fine-tune motion in the Graph Editor) draws that shape as a curve — its two draggable ends are the start and end values described below, plotted rather than typed.

What an open starting value buys you

An explicit starting value says "this property definitely begins at this exact number, whatever happened before." An open one says something different and usually more useful: "begin at whatever this property's value already is, at the moment this animation starts."

That distinction is the reason the ◆ diamond flow is pleasant to use. When you animate a circle's radius at three seconds, you almost never want to type the exact radius it happens to have at that point in the timeline — especially if an earlier animation already left it somewhere non-obvious. You just want to say "grow from here to 2.5" and let the editor work out what "here" was.

Animations on the same property then chain exactly the way you'd hope. The second one's effective start is either its own explicit value or, if that's left open, whatever the first one left the property at when it finished. This lets you build a whole sequence purely in terms of destinations — "then go to 5," "then go to 0.2" — without ever knowing or typing the intermediate numbers. The canvas preview, timeline scrubbing, and the final render all follow this same chaining, which is what keeps them from drifting apart from each other.

The Animate a value panel is worth calling out here, because it differs in exactly one way. It reads the property's current value at the playhead and shows it to you as From, then stamps that number in as an explicit starting value. So an animation made this way is pinned to the number that was true when you created it, rather than left open to chain from whatever comes before. That's usually what you want from a panel whose whole job is "take this value, over this many seconds, to this other value" — but if you later move that animation earlier or later on the timeline, or add another animation before it, the start stays pinned rather than following along. Use a ◆ diamond or record mode when you want the chaining behaviour instead.

Record mode's retarget logic

Record mode (the ● toggle) turns any change you make to an animatable property, while the playhead sits past the very start of the scene, into an animation automatically — no need to drop a ◆ diamond first. What it does hinges on one question: is the playhead currently inside an existing animation for this property?

If it is, the existing animation's destination is updated to the new value, in place. No second animation is created. This is a deliberate choice rather than a shortcut: two animations driving the same property at overlapping times would be ambiguous — which one wins, and at what point in its own ramp? Record mode heads that ambiguity off by reading "you're in the middle of an animation and you changed the value" as "you meant to retarget where this animation ends up," which is almost always what actually happened. You scrubbed into the middle of a move, nudged something, and want the nudge to be the new endpoint.

If the playhead is not inside an existing animation for that property, record mode creates a brand-new one instead. It runs from the end of that property's most recent animation — or from the start of the scene if there isn't one yet — up to the current playhead, starting from the property's real value at that anchor point. Two guards keep it from producing animations you didn't mean. If the anchor and the playhead are less than a twentieth of a second apart, nothing is created: you're not trying to animate an instantaneous jump, you're just adjusting the value. And if the playhead is within the first fraction of a second of the scene, record mode does nothing at all — there's no meaningful "before" to animate from, so the edit stays a plain, unanimated change, exactly as if record mode were off.

Priority when several things compete

One property can, in principle, be driven by more than one thing at once. Plain keyframes, a "follow" link to another object, and baked physics could all want to control the same position. The order is the same in the canvas preview and in the render:

1. Baked physics wins over everything. Once you've run the physics simulator on an object, its position, depth, and 3D orientation come straight from the simulated result at every moment. Keyframes and links on that object still exist, but the simulated motion is applied on top and overwrites them. To get a keyframe back in control, clear the baked motion.
2. A live link beats a plain keyframe. If a property is linked to follow another object's value (see Link one object's property to another), that link's value wins over anything a keyframe on the same property would have produced. This is the usual reason a keyframe appears to do nothing — the property is being held by a link. Remove the link and the keyframe takes over again.
3. Plain keyframes are the baseline, when neither of the above applies: the chained start-to-end ramps described above.

This ordering isn't arbitrary. It's the same priority Manim itself uses — something that recalculates a value every single frame always beats an animation that was set running earlier, because the per-frame update happens last. Baked physics and links are both per-frame things; plain keyframes are animations. So this isn't just "how this editor happens to break ties" — it's how Manim resolves the same conflict in hand-written code, which means the intuition you build here carries over unchanged if you ever go and read or write real Manim scenes.