Mini-Flugzeugsimulator

[Crocotronic]

Hallo zusammen,

nur aus reinem Interesse oder vielleicht auch im Hinblick auf die Entwicklung eines kleinen Spiels möchte ich ein "Flugzeugsimulator" bauen.
Das hört sich jetzt nach einem ganzschönen Brocken an, er soll aber wirklich nur aufs Mindeste reduziert werden, dh.
- ein einfacher Button soll als Flugobjekt dienen
- mit Key-Up und Key-Down soll die Beschleunigung geändert werden
- die Masse des Fliegers soll berücksichtigt werden, also auch die Trägheit beim Beschleunigen
- wenn der Flieger sich in einem zu steilen Winkel befindet, soll eine Art Strömungsabriss stattfinden, der durch senken der Nase wieder behoben werden kann

Jetzt ist da eine Menge Physik drin, was mir hierbei etwas Schwierigkeiten bereitet. Mein Ansatz:

Delphi-Quellcode:

var Ticker, Winkel, Beschl: Double;

{$R *.fmx}

procedure TForm1.FormCreate(Sender: TObject);
begin
 Ticker:= 0;
 Winkel:= 0;
 Beschl:= 0;
end;

procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; var KeyChar: Char;
  Shift: TShiftState);
begin
  if Key = 37 then
    Winkel:= Winkel + 0.1;

  if Key = 39 then
    Winkel:= Winkel - 0.1;

  if Key = 38 then
    Beschl:= Beschl + 1;

  if Key = 40 then
    Beschl:= Beschl - 1;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
var
  v,h,a,t,s,g,w: Double;
begin
  Inc(Ticker);     // 1 ms Takt
  if Ticker > 50 then
    Ticker:= 50;   // Geschwindigkeit limitieren

  a:= Beschl;      // Beschleunigung
  t:= Ticker/100;  // Takt auf gewünschte Zeit bringen
  w:= Winkel;      // Winkel e
  g:= 9.81;        // Gewichtskraft

  s:= 0.5*a*Power(t,2); // 1/2 * a * t^2

  //v:= t/a;
  //h:= (v*t*w)-((g*power(t,2)/2));

  h:= (w * 0.5 * g * Power(t,2)) / 2; // sin(a) * 1/2 * g * t^2

  Button1.Position.X:= Button1.Position.X+s;
  Button1.Position.Y:= Button1.Position.Y-h;
end;

Wie ihr seht, ist das alles sehr primitiv und sicherlich nicht ganz korrekt. Es gibt hier wahrscheinlich eine Menge von Physikern unter euch, die auf den ersten Blick etliche Fehler sehen. Meint ihr, ihr könnt mir erklären (vllt. auch anhand von Code), wie die oben genannten Punkte hier noch eingefriemelt werden können?
Wenn die Theorie stimmt, werde ich aus dem ganzen Kram natürlich eine objektorientierte Lösung erstellen. Es geht mir lediglich darum, dass ich die physikalischen Gesetze hier richtig in Verbindung bringe.

Würde mich sehr freuen, wenn ihr mir ein paar Ratschläge geben könntet.

Viele Grüße
Croco

[Luckie]

Ein Ratschlag gleich vor weg: Pack das ganze in eine Klasse, sonst blickst du selbst nicht mehr durch deinen Code durch. Zurückgeben tut die Klasse dann wie sich das Objekt im nächsten Zeitabschnitt bewegen muss. Damit kannst du dann alles bewegen: Panel, Shape, beliebiges grafisches Objekt.

[jfheins]

Also erstmal sieh das mit dem Ticker sehr komisch aus. Hast du schonmal sowas gemacht, wo du numerisch integriert hast?

normalerweise misst man, wie viel Zeit seit dem letzten Frame vergangen ist. Und diese gemessene Zeit geht dann in die Berechnung ein. Die Darstellung ist dann nur wenig davon abhängig, wie schnell der PC rechnen kann.

Zur Physik: Wie ist die Ansicht? Ich nehme mal an, das Flugzeug fliegt nach rechts und man schaut von der Seite drauf?

Dann hat den Flugzeug drei Freiheitsgrade: X, Y, Theta. (Auch Nickwinkel)

Der aktuelle Zustand deines Flugzeugs enthält aber zudem die Ableitungen (alle drei) und den aktuellen Schub. Und zur Vereinfachung auch noch dessen Ableitung. (Für alles brauchst du Variablen)
Das Grundlegenden Schema sieht nun so aus:

1. Startwerte festlegen (wo ist das Flugzeug, und wie schnell?)
2. Ableitungen berechnen
3. Zustände entsprechend der Ableitungen ändern (Integration)
4. Weiter mit Punkt 2

Ich vermute mal, das Aufstellen der mathematischen Gleichungen ist noch etwas zu hoch für dich (???) daher hier eine Kurzversion (morgen vll. ausführlicher). Die Ableitungen stelle ich mit ' dar, x'' ist also die zweite Ableitung von x. (Zweimal integrieren, und dann kommt x heraus!)

x'' = Luftreibung + Antrieb = (-2*x' + Schub * cos(theta))/Masse
y'' = Luftreibung + Antrieb + Gravitation + Auftrieb = (-2*y' + Schub * sin(theta) - G + Auftrieb)/Masse
theta'' = 0;

Schub' = <Je nach Tastendruck -1, 1 oder 0>
x' = x' + dT * x''
y' = y' + dT * y''
theta' = 0.2*(arctan2(y', x') - theta) + <Je nach Tastendruck -1, 1 oder 0> // Das sollte bewirken, dass sich das Flugzeug ein bisschen "von selbst" ausrichtet

So in etwa. Vermutlich habe ich da aber noch was vergessen ... sollte schlafen gehen - morgen mehr. Gute Nacht :-)

[Luckie]

Uff. Wenn du den Luftwiderstand noch berücksichtigen willst, dann wird es kompliziert. Denn dann hast du mit Differenzialgleichungen zu tun. Wenn ich mich recht an mein Bauingenieurstudium und der Mechanikvorlesung aus dem dritten Semester erinnere.

[Sir Rufo]

Um das Ganze zu vereinfachen erstellt man sich ein festes Zeitraster für das man die eigentlichen Berechnungen durchführt. Dadurch können einige Werte vorberechnet oder fest vorgegeben werden und meistens sind es dann simple Additionen für die Berechnung der neuen Positionswerte.

Vor jedem Zeichnen bestimmt man die Zeit die seit dem letzten Zeichnen vergangen ist und bestimmt daraus die Anzahl der Zeitraster (x). Nun werden die Berechnungen einfach (x) mal durchgeführt und dann wird dieser Zustand gezeichnet. Die noch verbleibende Restzeit wird bei dem nächsten Durchgang berücksichtigt.

Nehmen wir an, das Zeitraster legen wir auf 20ms fest und ca. alle 40-60ms können wir neu zeichnen:

Code:

ZeitRaster = 20
// erster Durchgang
ZeitReserve = 0
ZeitVergangen = 45
Frames = ( ZeitReserve + ZeitVergangen ) div ZeitRaster = 2
ZeitReserve = ZeitReserve + ZeitVergangen - Frames * ZeitRaster = 5
// 2x Frames berechnen und anzeigen

// zweiter Durchgang
ZeitVergangen = 58
Frames =  ( ZeitReserve + ZeitVergangen ) div ZeitRaster = 3
ZeitReserve = ZeitReserve + ZeitVergangen - Frames * ZeitRaster = 2
// 3x Frames berechnen und anzeigen

...

[Crocotronic]

Zuerst mal vielen, vielen Dank jfHeins!
Also die Darstellung geschieht in 2D, d.h. die Kameraposition ist erstmal ganz normal von der Seite, wie in guten alten Zeiten. Das Flugzeug soll sich auf einer Karte frei bewegen können.

Was die Begrifflichkeiten angeht: Habe gestern mein Mahte-Abitur auf dem beruflichen Gymnasium mit dem Profilfach Informatik absolviert, von dem her sollten mir Ableitung und co. bekannt sein :thumb:

Grundlegend geht es mir erstmal drum, wie die Formel aussehen muss, wenn ein Flieger mit der Masse M im Winkel von z.B. 80° nach oben fliegt. Physik war noch nie meine Stärke, weshalb ich auch Chemie gewählt habe. Deshalb ist mir nicht ganz klar, wie ich die Gegenkraft mit einberechnen muss (Trägheit etc.) Außerdem soll der Flieger auch anders reagieren, wenn er nach unten Fliegt, da dann die Gewichtskraft die Beschleunigung "verstärkt".
Der Nickwinkel kann durch die Pfeiltasten variiert werden. Was du so geheimnisvoll mit Ableitung ausdrücken wolltest, ist wahrscheinlich

Code:

s'(t) = v(t)

und

Code:

s''(t) = a(t)

Nur wofür sollte ich die unbedingt bestimmen?
Das mit dem Luftwiderstand sieht zwar sehr interessant aus, ist jedoch etwas zu umfassend für mein Vorhaben. Dennoch glaube ich, dass du mir einiges erklären und mich weiter bringen könntest!

@Oliver: Vielen Dank für die Erläuterung. Da ich mich mit dem Thema "Video-Spiele" noch nie beschäftigt habe, ist soetwas sehr hilfreich für mich!

[himitsu]

Zitat:

Zitat von jfheins (Beitrag 1294695)

normalerweise misst man, wie viel Zeit seit dem letzten Frame vergangen ist. Und diese gemessene Zeit geht dann in die Berechnung ein. Die Darstellung ist dann nur wenig davon abhängig, wie schnell der PC rechnen kann.

Nicht nur wie schnell der PC ist ... auch TTimer wird niemals die gewollte Auflösung von 1ms hinbekommen
und da nebenbei auch noch andere Programme und das eigene Programm die Ausführng des Timerevents verzägern können, wird es je nach CPU-Auslastung noch "schlimmer".

Einfach mal ausprobieren und sich freuen, wie schon ohne viel Code der Timer (Count links) der echten Zeit (rechts) hinterherläuft. :stupid:

Delphi-Quellcode:

var
  Count, Start: Cardinal;

procedure TForm3.FormCreate(Sender: TObject);
begin
  Start := GetTickCount;
end;

procedure TForm3.Timer1Timer(Sender: TObject);
begin
  Inc(Count);
  Caption := Format('%d %d', [Count, GetTickCount - Start]);
end;

bzw. (z.B. für FMX)

Delphi-Quellcode:

var
  Count: Cardinal;
  Start: TDateTime;

procedure TForm3.FormCreate(Sender: TObject);
begin
  Start := Now;
end;

procedure TForm3.Timer1Timer(Sender: TObject);
begin
  Inc(Count);
  Caption := Format('%.0n %.0n', [Count/1, MilliSecondSpan(Now, Start)]);
end;

PS: Wert2 durch Wert1 = das, was dein PC gerade jetzt für ein Timer1.Interval "wirklich" hinbekommt.

[Mavarik]

Zitat:

Zitat von Crocotronic (Beitrag 1294699)

...wenn ein Flieger mit der Masse M im Winkel von z.B. 80° nach oben fliegt. Physik war noch nie meine Stärke...

Keine Tragfläche bietet bei 80° Auftrieb... Das geht nur über Antriebsleistung.

Eine Tragfläche erzeuge je nach Anstellwinkel mehr oder weniger Auftrieb. Ausgehend vom Horizontalflug wo der
Auftrieb=Masse ist, kannst Du also den Anstellwinkel vergrößern und so mehr Auftrieb erzeugen...
Dadurch erhöht sich aber der Widerstand.

Dem sind jedoch Grenzen gesetzt. Wenn die Umströmende Luft aufgrund des zu hohen Anstellwinkels nicht mehr anliegt, erzeuge die Tragfläche ganz plötzlich keinen Auftrieb mehr. Das ist je nach Tragflächenprofil unterschiedlich
und ob Klappen "gesetzt" sind oder "Vorflügel"...

Mavarik

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1294704)

Zitat:

Zitat von jfheins (Beitrag 1294695)

normalerweise misst man, wie viel Zeit seit dem letzten Frame vergangen ist. Und diese gemessene Zeit geht dann in die Berechnung ein. Die Darstellung ist dann nur wenig davon abhängig, wie schnell der PC rechnen kann.

Nicht nur wie schnell der PC ist ... auch TTimer wird niemals die gewollte Auflösung von 1ms hinbekommen

1ms macht ja sowieso keinen Sinn.. weil 1000 Frames geht eh nicht...

So lange meine Berechnung und der Grafikaufbau schneller sind als 16,6 ms ist alle schick... Dann komme ich auf die 60 Frames die i.d.R. die heutiges Monitore machen... Schneller lohnt nicht...

[Caps]

Das mit dem Messen der Zeit, die seit dem letzten Frame vergangen ist, geht nur, wenn die Funktion der Flugbahn bekannt ist. Denn diese Funktion muss man dann integrieren. Das ist aber wohl selten der Fall. Ich würde es umgekehrt machen:

- in der Schleife die Werte korrekt berechnen (Ort, Geschwindigkeit, Beschleunigung)
- das Bild rendern; wenn die GraKa/ Prozessor nicht schnell genug ist -> Frame verwerfen

Auf diese Weise "hackt" das Bild genau wie im anderen Fall, aber die Flugbahn ist wenigstens korrekt.

lg Caps

[Mavarik]

Zitat:

Zitat von Caps (Beitrag 1294739)

- in der Schleife die Werte korrekt berechnen (Ort, Geschwindigkeit, Beschleunigung)
- das Bild rendern; wenn die GraKa/ Prozessor nicht schnell genug ist -> Frame verwerfen

Bei komplexen Spielen kannst Du dir das nicht leisten Frames zu verwerfen...

Wenn Du nicht auf einem anderen Core die Sachen berechnest, hast Du dafür sowieso keine Möglichkeit...

Wenn das letzte Frame angezeigt wurde, kommst Du in Deine Berechnung ggf. hängst Du sowieso schon wieder hinterher...
Also kannst Du nur die Zwischenrechnungen vergessen und Dein Object gemäß vergangener Zeit an der richtigen Stelle anzeigen.

Mavarik

[Caps]

Zitat:

Zitat von Mavarik (Beitrag 1294746)

Wenn Du nicht auf einem anderen Core die Sachen berechnest, hast Du dafür sowieso keine Möglichkeit...

In einem Thread?

Zitat:

Zitat von Mavarik (Beitrag 1294746)

Wenn das letzte Frame angezeigt wurde, kommst Du in Deine Berechnung ggf. hängst Du sowieso schon wieder hinterher...
Also kannst Du nur die Zwischenrechnungen vergessen und Dein Object gemäß vergangener Zeit an der richtigen Stelle anzeigen.

Aber die Berechnungen können leicht so komplex werden, dass es nicht möglich ist, zu integrieren. Man denke nur an Kollisionen...

lg Caps

[Mavarik]

Zitat:

Zitat von Caps (Beitrag 1294769)

Aber die Berechnungen können leicht so komplex werden, dass es nicht möglich ist, zu integrieren. Man denke nur an Kollisionen...

Naja egal wie komplex... Du kannst nur so viele Frames anzeigen wie Du auch pro Sekunde berechnen kannst... :stupid:

[Caps]

Ja, freilich; ich wollte ja welche wegwerfen, wenn sie nicht schnell genug gerendert werden können, weiter nüschde ;-)

[jfheins]

Zitat:

Zitat von Luckie (Beitrag 1294697)

Uff. Wenn du den Luftwiderstand noch berücksichtigen willst, dann wird es kompliziert. Denn dann hast du mit Differenzialgleichungen zu tun. Wenn ich mich recht an mein Bauingenieurstudium und der Mechanikvorlesung aus dem dritten Semester erinnere.

Natürlich will ich das :stupid: Und Differenzialgleichungen sind es ohnehin schon, sobald man Bewegungen und Beschleunigungen numerisch simuliert. Ob man es beim Namen nennt, oder nicht.

Zitat:

Zitat von Crocotronic (Beitrag 1294699)

Grundlegend geht es mir erstmal drum, wie die Formel aussehen muss, wenn ein Flieger mit der Masse M im Winkel von z.B. 80° nach oben fliegt. Physik war noch nie meine Stärke, weshalb ich auch Chemie gewählt habe. Deshalb ist mir nicht ganz klar, wie ich die Gegenkraft mit einberechnen muss (Trägheit etc.) Außerdem soll der Flieger auch anders reagieren, wenn er nach unten Fliegt, da dann die Gewichtskraft die Beschleunigung "verstärkt".

Hoffentlich sollte die Formel dann nicht anders aussehen als sonst - zumindest wenn wir alle Einflüsse in der Formel berücksichtigen.

Zunächst stellen wir ein Kräftegleichgewicht auf. D.h. wir überlegen usn, was für Kräfte auf das Flugzeug in welcher Richtung wirken. (Kräfte sind Vektoren) Dann kommt der Impulserhaltungssatz: p' = Summe aller Kräfte. Da sich die Masse deines Flugzeugs nicht ändert (Vereinfachung!) können wir schreiben:

Beschleunigung = a(t) = x''(t) = Kräftesumme/Masse (Alles Vektoren)

Die Geschwindigkeit deines Flugzeugs ergibt sich nun aus der anfänglichen Geschwindigkeit und der auf-integrierten Beschleunigung. Ja, dabei entsteht ein kleiner Fehler, da du keine infinitesimal kleinen Zeitschritte machst. Aber da du auch keine Referenzkurve hast, kannst du kleine Fehler ignorieren.

Zitat:

Der Nickwinkel kann durch die Pfeiltasten variiert werden. Was du so geheimnisvoll mit Ableitung ausdrücken wolltest, ist wahrscheinlich

Code:

s'(t) = v(t)

und

Code:

s''(t) = a(t)

Nur wofür sollte ich die unbedingt bestimmen?
Das mit dem Luftwiderstand sieht zwar sehr interessant aus, ist jedoch etwas zu umfassend für mein Vorhaben. Dennoch glaube ich, dass du mir einiges erklären und mich weiter bringen könntest!

Maßgeblich für den Stömungsabriss ist aber nicht der Nickwinkel, sondern vielmehr der Anstellwinkel. (Anstellwinkel = Pitchwinkel - arctan2(Geschwindigkeit)) Wenn das Flugzeug 10° nach oben zeigt, kann das in einem Steigflug wunderbar funktionieren. Aber falls das Flugzeug nach unten fliegt (und dabei nach oben zeigt) dann ist der Anstellwinkel zu groß und es kommt zum Strömungsabriss.

Genauer gesagt: Auftriebskraft ergibt sich aus dem Auftriebsbeiwert und der Geschwindigkeit, der Auftriebsbeiwert hängt aber vom Anstellwinkel ab.

Eine Trägheitskraft brauchst du nicht zu modellieren, die Trägheit ergibt sich daraus, dass du die Kräfte durch die Masse teilst.

Zitat:

Nur wofür sollte ich die unbedingt bestimmen?

In der Schule hast du sicher öfters Ableitungen zu gegebenen Funktionen bestimmt. Das Problem hier ist umgekehrt: Du kennst die Ableitungen (Beschleunigung), und möchtest du Funktion plotten (Position). Das nennt sich Anfangswertproblem.

Sobald die Luftreibung dazu kommt, kannst du die Gleichungen auch (fast) nicht mehr analytisch lösen. Daher geht man oft den Weg über das Kräftegleichgewicht (lässt sich meistens ganz gut Aufstellen) und Integriert das dann.

[Mavarik]

Zitat:

Zitat von jfheins (Beitrag 1294779)

Da sich die Masse deines Flugzeugs nicht ändert

Stimmt auch nicht so ganz...

Klar die Masse ändert sich nicht... Abgesehen von Treibstoffverbrauch oder Eisansatz..

Aber:Wenn Du eine Kurve mit 60° Bank fliegst "wiegt" Dein Flugzeug schon doppelt so viel...
Bedeutet Deine Tragfläche muss doppelt so viel Auftrieb liefern...
Dieser Auftrieb wird nur durch einen erhöhten Anstellwinkel erreicht.

Zitat:

Zitat von jfheins (Beitrag 1294779)

Maßgeblich für den Stömungsabriss ist aber nicht der Nickwinkel, sondern vielmehr der Anstellwinkel. (Anstellwinkel = Pitchwinkel - arctan2(Geschwindigkeit)) Wenn das Flugzeug 10° nach oben zeigt, kann das in einem Steigflug wunderbar funktionieren. Aber falls das Flugzeug nach unten fliegt (und dabei nach oben zeigt) dann ist der Anstellwinkel zu groß und es kommt zum Strömungsabriss.

Da geht aber einiges durcheinander!

Es geht hierbei nicht um die "Richtung" in der das Flugzeug zeigt oder fliegt...
Der Anstellwinkel ist der Winkel zwischen Profilsehne und der anströmenden Luft.

Mavarik

[Caps]

Zitat:

Zitat von Mavarik (Beitrag 1294821)

Zitat:

Zitat von jfheins (Beitrag 1294779)

Da sich die Masse deines Flugzeugs nicht ändert

Stimmt auch nicht so ganz...

Klar die Masse ändert sich nicht... [...]

Zitat:

Zitat von jfheins (Beitrag 1294779)

[...] Wenn das Flugzeug 10° nach oben zeigt, kann das in einem Steigflug wunderbar funktionieren. Aber falls das Flugzeug nach unten fliegt (und dabei nach oben zeigt) dann ist der Anstellwinkel zu groß und es kommt zum Strömungsabriss.

[...] Der Anstellwinkel ist der Winkel zwischen Profilsehne und der anströmenden Luft.

Mavarik

Ich finde die Widersprüche nicht 8-).

lg Caps

[CHackbart]

Mir gefällt die Entwicklung der Diskussion :) Das erinnert mich an eine Spielerei von vor 15 Jahren (Herrje, wo ist nur die Zeit hin).
Damals hatte ich nach eingehendem Studieren der Webseite von David Braben angefangen einen Elite-Klon zu schreiben.

Der Code für die Flugbewegung war nicht sonderlich komplex, aber tat seinen Dienst:

Delphi-Quellcode:

function moveToTarget(cur, tar, speed: single): single;
begin
  if (cur <> tar) then
  begin
    if (cur < tar) then
    begin
      cur := cur + speed;
      if (cur > tar) then
        cur := tar;
    end
    else
    begin
      cur := cur - speed;
      if (cur < tar) then
        cur := tar;
    end;
  end;
  result := cur;
end;

...

    Rcur.x := moveToTarget(Rcur.x, Rtar.x, Rdampen.x);
    Rcur.y := moveToTarget(Rcur.y, Rtar.y, Rdampen.y);
    Rcur.z := moveToTarget(Rcur.z, Rtar.z, Rdampen.z);

    // z-Achsenrotation für Autopilot
    if (Rcur.z <> 0) then
    begin
      thrust.Assign(0, 0, 1);
      thrust.Mul(Matrix);
      M.RotateAbout(thrust, -Rcur.z);
      Matrix.Mul(M);
    end;

    if (Rcur.x <> 0) then
    begin
      thrust.Assign(1, 0, 0);
      thrust.Mul(Matrix);
      M.RotateAbout(thrust, -Rcur.x);
      Matrix.Mul(M);
    end;

    if (Rcur.y <> 0) then
    begin
      thrust.Assign(0, 1, 0);
      thrust.Mul(Matrix);
      M.RotateAbout(thrust, -Rcur.y);
      Matrix.Mul(M);
    end;

    // Minimalgeschwindigkeit
    if (fSpeedTar < 4) then
      fSpeedTar := 4;
    fSpeedCur := moveToTarget(fSpeedCur, fSpeedTar, 2);
    if (fSpeedCur <> 0) then
    begin
      thrust.Assign(0, 0, fSpeedCur);
      thrust.Mul(Matrix);
      Position.Add(thrust);
      Movement.Copy(thrust);
    end
    else
      Movement.Assign(0, 0, 0);

Bei der Gelegenheit habe ich den Code mal wieder rausgekramt und gleich um FMX und GDI+ erweitert. Schon erstaunlich, wie einfach die alte Delphi2 Version auf Delphi7 bzw. XE5/8 portiert werden konnte.

[jfheins]

Zitat:

Zitat von Mavarik (Beitrag 1294821)

Zitat:

Zitat von jfheins (Beitrag 1294779)

Da sich die Masse deines Flugzeugs nicht ändert

Stimmt auch nicht so ganz...

Deshalb steht ja auch direkt dahinter ein "(Vereinfachung!)" :stupid:

Zitat:

Zitat von Caps (Beitrag 1294839)

Zitat:

Zitat von Mavarik (Beitrag 1294821)

[...] Der Anstellwinkel ist der Winkel zwischen Profilsehne und der anströmenden Luft.

Mavarik

Ich finde die Widersprüche nicht 8-).

lg Caps

Das eine ist halt eine Vereinfachung, und das andere die strikte Definition. Auf der einen Seite wurde Profilsehne = Flugzeuglängsachse gesetzt. Das ist beim realen Flugzeug meist nicht so, der Flügel ist etwas geneigt (soll ja auch ordentlich Auftrieb erzeugen, wenn das Flugzeug geradeaus fliegt). Andererseits werden damit auch Auftriebshilfen wie Slats und Klappen, sowie neigbare Flügel vernachlässigt.
Auf der anderen Seite habe ich Winkel der anströmenden Luft = Geschwindigkeit im Erdbasierten Intertialsystem gesetzt. Das gilt eben nur für Windstille.

Um noch weitere Vereinfachungen aufzuzeigen: Der Luftwiderstand müsste sich natürlich mit der Höhe ändern, genauso auch der Auftrieb. Und Kurven (das Quer- und Seitenruder) sind in dieser 2D-Betrachtung natürlich ohnehin außen vor. Man kann das im Grunde beliebig kompliziert machen.