Ich fürchte, dass Du das unterschätzen tust.
Der Flocking-Algorithmus ersetzt ja nicht die Skin-Animation (oder Animation des Flügelschlags eines 3D-Models). Die Animation des Vogels selbst (die Bewegung seiner Flügel) erstparst Du Dir ja damit nicht.
Noch dazu ist die Bewegung der Flügel ja auch abhängig von der Flugrichtung. Es reicht also nicht aus, die Flügel immer gleichmäßig zu bewegen. Du müsstest in Deinen Flocking-Algorithmus dann also auch einbauen, dass bei einem Kurswechsel die Flügel entsprechend anders bewegt werden. Eine Landung auf z.B. einem Baum (wie auf einem der Youtube-Videos oben zu sehen) ist mit einem Flocking-Algorithmus auch nicht möglich.

Also ich denke, dass eine vorberechnete Vertex-Animation da wesentlich schneller ist, als jede Art von Echtzeit-Berechnung. Und dass man dabei auch viel flexibler ist, und man auch so Dinge wie Landung und Abflug darstellen kann.

Für komplexe Bewegungsbahnen, wie z.B. vorberechnete Kameraflüge, oder eben jetzt auch Vogelflüge, verwende ich auch gerne UNSICHTBARE Hilfs-Models, die nur aus einem einzigen Polygon bestehen. Die Flugbewegung dieses Polygons berechne ich dann in Max (dort kann man schöne runde Flugbahnen definieren, und auch die Fluggeschwindigkeit beliebig anpassen).
Weil es nur ein einziges Polygon gibt (also 3 Vertices), verbraucht die Vertexanimation dann auch nur sehr wenig Speicher. Und zur Laufzeit hänge ich dann an eines der drei Vertices das eigentliche Objekt an, das sich bewegen soll (z.B. die Kamera, oder eben auch ein animiertes Sprite für den Vogel, das dann immer in Richtung Kamera ausgerichtet wird, während es der Flugbahn folgt).

Für die Ansteuerung des momentan abzuspielenden Frames der Skin/Sprite-Animation könnte man von dem unsichtbaren Bewegungs-Model den zweiten Vertex der drei Vertices zweckentfremden. Dessen Z-Koordinate könnte dann für jedes einzelne Animationsframe die Frame-Nummer der Skin-Animation hinterlegt haben.