Part 1 had a slider that walked the top bar of a hamburger into one diagonal of a cross. Four numbers on the left became four numbers on the right, and every frame in between was a weighted average of the two. That is the whole of the arithmetic, and it is the easy half.
The hard half is the decision that came first. Something had to say that that bar becomes that diagonal, and nothing in either icon says so. A hamburger is drawn with three lines and a cross with two, so the lines have to be paired up before a single number can be averaged, and there is more than one way to pair them.
By the end of this page you will be able to say why that pairing never goes away. You would
settle it in a second, because you can look at both icons and you know what a hamburger and a
cross are for. A program cannot look at either one. All it has is two d strings, which is
to say two lists of positions on a 24 by 24 grid. Every technique in the rest of these pages
is a way of recovering your answer out of those numbers alone.
A hamburger has three strokes, meaning three separate lines, one pen-down each, rather
than the stroke attribute that paints them. A cross has two. Before anything can be
interpolated, something has to settle the , which means answering
three questions:
None of those has an obviously correct answer, and every one of them is visible when you get it wrong.
Answer them yourself. Every arrangement below is legal, nothing errors, and several look absurd, which is the point: the browser will faithfully animate whichever correspondence it is handed.
Take the third question first, because it is the one that looks like it cannot matter. The pair is already settled and both strokes are straight, so all that is left is which end meets which end. There are two answers, the source gives you no way to tell them apart, and one of them wrecks the animation.
Say the top bar becomes the \ diagonal. Lucide writes that diagonal as m6 6 12 12, which
by Part 1's alphabet is "start at 6,6 and draw a line 12 right and 12 down", so it runs from
(6, 6) to (18, 18). The top bar is M4 5h16, which runs from (4, 5) to (20, 5). Both
go left to right, so joining start to start joins the two left ends. The bar sweeps into
place, and it never gets shorter than 15.2 units on the way against
the 16 it started at.
Now the other diagonal, the /. Lucide writes it as M18 6 6 18, and the pairs of numbers
are in the other order: it runs from (18, 6) to (6, 18), which is right to left. Join
start to start now and you have joined the bar's left end to the diagonal's right end. That
end has to cross the whole icon while the other end crosses back the other way. Halfway
through, the two ends have swapped sides, so the bar passes through vertical, an orientation
neither icon contains anywhere, and it bottoms out at 6.3 units
against the 16 it started at. Then it arrives backwards.
Try it. The dots are the bar's two ends, so you can follow where each one goes, and the read-out is the bar's own length. Pick a diagonal, then join the other end of it, and the verdict swaps.
The bar is 6.3 units long, and the least it gets is 6.3, against 16 at rest.
Nothing is broken. The maths did exactly what it was told. The two diagonals draw the same two pictures whichever way round they are written, so the disagreement about which end was the beginning is invisible in the icon and sitting in plain sight in the data.
Three bars, two diagonals. One bar has nowhere to go.
The obvious answer is to fade it out, and the obvious answer is wrong in an interesting way. Fading leaves the stroke sitting in the middle of the icon getting fainter while the other two rotate around it, which reads as a bug rather than as a decision.
The better answer is that the spare stroke should be somewhere specific: sitting exactly on top of one of the other two, so the animation reads as one stroke splitting into two rather than as a stroke evaporating. That is called , and it turns out to have a subtle rendering problem of its own, which is Part 5.
Count the first question on its own. Three bars, two diagonals, one bar spare: there are six ways to hand the bars out. Most look wrong, one or two look right, and which ones depend on what you think the icon means.
Then remember there were three questions, not one. Each of the two surviving pairs can still be joined either way round, which multiplies those six by four. The exercise above is that arithmetic.
Now scale it. Two icons with six strokes each have 720 ways to assign the strokes, because the count is a factorial, and orientation doubles each of the six pairings on top of that, for 46,080 in total. This is not something you brute force past a handful of strokes, and not something you eyeball across a library of two thousand icons.
You looked at the hamburger and the cross and knew what should happen. Top bar becomes one diagonal, bottom bar becomes the other, middle bar tucks away. It took no effort.
That is because you understand what the icons mean. You know a hamburger is a stack and a cross is an X. You know the visual grammar the designer used.
A computer has two lists of numbers. It has no idea that one drawing means "menu". Every approach to this problem is some way of recovering, from geometry alone, a decision that you made from meaning.
Correspondence is the whole problem. Interpolation is arithmetic. Everything interesting a morphing library does is an attempt to answer which becomes which, without being able to see.
There are only two places to answer it.
You can answer it at runtime, on the user's device, every time the page loads. Look at the two shapes, measure them, score the possible pairings, pick the best one. This is what most libraries do and it is genuinely clever work.
Or you can answer it once, ahead of time, and write the answer down as data that ships with the icons.
Those two choices lead to completely different products, and the difference is not really about performance. What neither of them can do is see what you saw. The answer that ships is still a decision about meaning, recovered from coordinates, whichever end of the pipeline recovers it, and nothing later on these pages changes that.
Part 3 is the fork itself.
Every approach to morphing recovers, from geometry alone, a decision you made from meaning.