A morph has to decide what path each point takes between its two positions. The obvious answer is a straight line, and for most pairs it is also the right one. For a rotation it is visibly wrong, and the fix is to describe the motion in terms instead.
By the end of this page you will be able to predict, from the turn angle alone, how much shorter a rotating arm comes out at the midpoint, and say which of the two routes a compiler should take for a given pair. The failure here is the one readers most often mistake for a bug in their own rig.
Interpolating coordinates directly means every point travels the straight line between where it starts and where it ends. When the correct motion is a rotation, that straight line is the chord of the arc the point should have travelled, and a chord is shorter than its arc.
The shape therefore shrinks on the way across and grows back at the end.
| Pair | Linear | Polar | Cost |
|---|---|---|---|
| arrow-right to arrow-down | 204 B / 1217 B 2 kf / 9 kf |
At 180 degrees the two endpoints swap places, so the chord passes through the centre and the shape collapses to a single point mid-flight.
| Pair | Linear | Polar | Cost |
|---|---|---|---|
| arrow-right to arrow-left | 198 B / 2301 B 2 kf / 17 kf |
The alignment between the two shapes is solved once, at build time, into a rotation, a scale and a . Each part is then interpolated in the space where it is linear: the angle linearly, the scale logarithmically, and the leftover deformation as a plain lerp in the aligned frame.
"The space where it is linear" is doing the work in that sentence, and the scale is the one that needs explaining. Interpolating scale in log space means the midpoint between 1 and 4 is 2 rather than 2.5, because halfway between one doubling and two doublings is one and a half doublings. That matters here because growing and shrinking then cost the same: a shape that goes from 1 to 4 and back passes through 2 both times, where a plain average would put it at 2.5 on the way out and 2.5 on the way back and never at the size a viewer would call halfway.
The angle needs no such treatment because rotation is already uniform: turning 30 degrees costs the same wherever you start. The residual gets a plain lerp because by that point the rotation and scale have been divided out, so what is left is a small deformation with no structure worth respecting.
If the two shapes are the residual is zero, the bracket is constant, and the motion is a pure rotation.
None of that maths ships. The compiler samples the polar path at build time and emits the samples as ordinary keyframes, and the browser interpolates between adjacent ones, which is all it was ever going to do.
The sample count is chosen per pair against a deviation budget, so a pair with no rotation still costs two keyframes and only real curvature pays for more.
Progress does not have to come from the . seek renders the pair frozen at any value,
which is what a drag or a scroll position would drive.
If two shapes are not congruent there is no rigidity to preserve, and the rotation term is
decoration. The compiler checks the residual and falls back to two keyframes, which in
lib/morph is compileAuto, the one entry point that decides between the two routes for
you rather than making you pick.
An imported search to x, a circle becoming a line with a residual of
0.442, drops from 17 keyframes to 2 with no visible
loss.
So the rule is short. A straight tween cuts the corner off every rotation, by an amount you can read off the angle, and sampling along the arc is what buys the length back. Pay for it only when the two shapes are congruent enough for there to be a rotation worth preserving, and let the residual decide rather than deciding by eye.
That residual is about to do more than pick a route. Part 8 turns it into a gate.
Why the obvious interpolation collapses an arrow, and what to do instead.
You will need it in Part 8.