Pilot View vs gluLookAt



  • Hallo,
    ich schreibe gerade an meiner kleinen Anwendung in OpenGL. Weil ich mich momentan noch nicht an die Physik traue plane ich einen Flugsimulator im Weltraum (keine Schwerkraft...*g*).

    Jetzt sitze ich programmiertechnisch bereits in einem Raumschiff und bewege mich vorwärts und rückwärts. Allerdings muss sich mein Flügel jetzt auch noch rauf und runter drehen und nach links und rechts sollte ich ja auch noch steuern.

    Ich habe mir als folgendes überlegt:
    - x,y,z Koordinaten für die Position
    - a,b,c Winkel für dir Rotation (a um dei X-Achse, etc...)

    Da ich ja aus der Ich-Perspektive fliege liegt die (nicht existierende) "Kamera" genau in meinem Ursprung.

    Bei gluLookAt müsste ich die Winkel ja in 6 Koordinaten umrechnen. Ich habs noch nicht gemacht, aber ich vermute mal das geht nicht ganz ohne ein par sin(), cos() und Diffisionen, was ja bekanntlich viel rechenleistung bei float (double) Werten benötigt.

    Mein erster Gedanke war aber eher die folgende Funktion:

    void 3D::CamPos(float x, float y, float z, float a, float b, float c)
    {
      glRotated(a, 1.0, 0.0, 0.0);
      glRotated(b, 0.0, 1.0, 0.0);
      glRotated(c, 0.0, 0.0, 1.0);
      glTranslated(-x, -y, -z);
    }
    

    Das wären dann "nur" 4 Befehle mit überschaubaren Rechenaufwand.

    Macht es denn Sinn das ganze auf gluLookAt umzuschreiben? Gewinnt man dadurch etwas? In meinen Augen nicht, aber ich dachte, ich frage mal jemanden der sich besser auskennt als ich (und nutze nicht die gelben Seite).

    Mal rein rethorisch: Bei Google hab ich nicht eine einzige Meinung zu dem Thema gefunden. Nur ein paar Leute die gluLookAt verwenden, aber nicht wirklich die Vor- oder Nachteile auflisten.

    Danke,
    Stefan



  • gluLookAt ist für mich immer einfacher, da ich die beiden Vektoren (die man auch leicht in position und viewray umrechnen kann) intuitiver finde, als die Angabe von drei Winkeln x,y,z. Diese Darstellung der Rotation ist auch nicht immer eindeutig (z.B. Eulerwinkel, Kardanwinkel, ...) und es kann zu Effekten wie beispielsweise Gimballock kommen.

    Die Berechnungen von sin(), cos() sollten im Verhältnis nicht viel kosten, da Du diese nur einmal pro Frame berechnen musst. (siehe neuere OpenGL-Versionen, bei denen die die Modelviewmatrix selbst berechnen musst)



  • sin und cos lassen sich auch prima vorberechnen und in Arrays ablegen. Es geht natürlich etwas Genauigkeit dabei flöten, je nachdem wie "fein" du die Schrittweite speicherst. Sowas hat man früher bei Raycastern gemacht um Rechenzeit zu sparen. Aber echt mal, heute braucht man sowas eigentlich nicht mehr, wo jeder lumpige Office Rechner einen Doppelkern unter der Haube hat 🙂



  • stefanjann schrieb:

    Ich habs noch nicht gemacht, aber ich vermute mal das geht nicht ganz ohne ein par sin(), cos() und Diffisionen, was ja bekanntlich viel rechenleistung bei float (double) Werten benötigt.

    Viel Rechenleistung? Im Vergleich zu was? Mach dir darum erstmal keine Gedanken, den Unterschied ob du dreimal sin() und cos() mehr pro Frame machst oder nicht wirst du nichtmal messen können...


Anmelden zum Antworten