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. The defining moment of a breaking wave is the fold, the crest passing in front of its own base. Nothing we tried could produce it, because a simulation that resolves a surface into a single value per position has no way to represent one part of it passing over another. No amount of parameter tuning reaches a shape the model cannot hold.
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.