Motion is a timing problem before it is a styling problem
Days lost to shading and colour on something that was never a shading problem.
What happened
A hand-drawn look was chased through shading and colour for days without success. It was never a shading problem: a physics simulation cannot hold a frame, and smooth 60fps interpolation reads as computer-generated no matter how it is painted.
What changed
Motion is now specified as frame rate and hold — how many drawings, held how long — before anything is drawn. Easing curves and colour come afterwards, and only if the timing already reads correctly.
We wanted an animation with a hand-drawn quality. The first attempts were a physics simulation with careful shading, and every version looked computer-generated. More shading did not help. Neither did better colour.
The problem was never the rendering. Hand-drawn animation is produced at eight or twelve drawings a second, with each drawing held. That stutter is what the eye reads as "drawn". Anything interpolating smoothly at sixty frames a second reads as generated, however it is painted.
There was a second, structural problem. A physics simulation of a surface stores one height per position, so the surface can never fold over itself. But the defining moment of a breaking wave is exactly that fold — the crest passing in front of its own base. It was unreachable by construction, not by parameter.
The fix was to stop simulating and start animating: a small number of hand-authored key poses, swapped discretely, with the motion quantised into held steps. Once the timing was right, the styling took an afternoon.
The transferable version is a sequencing rule. Specify motion as frame rate and hold before you specify easing or colour. If the timing is wrong, no amount of styling will rescue it, and you will spend days finding that out the expensive way.