4. OpenGL: Kamera bewegen

OpenGL: Kamera bewegen

  • C

    Ja, da steht genau das was ich geschrieben habe noch mal, OpenGL ES 2.0 kennt die fixed-function Pipeline nicht einmal mehr. So.. what's your point?
    Edit: Jetzt haste alles gelöscht..

    0
  • P

    cooky451 schrieb:

    Ja, da steht genau das was ich geschrieben habe noch mal, OpenGL ES 2.0 kennt die fixed-function Pipeline nicht einmal mehr. So.. what's your point?
    Edit: Jetzt haste alles gelöscht..

    Du unterstellst hier (wie schon in Deinen vorherigen Postings)
    Dinge die so nicht gesagt wurden.

    Das im 1. Post verlinkte Beispiel war wie die Einleitung erkentlich machte
    auf die Kamera bezogen und wie man das (mit eben jenem Code den KellerAutomat verwendet hat) realisiert, Kernaussage war - In OpenGL gibts keine Kamera, wenn muss man die selber implementieren.

    Auf Deine "vor-vor-version" Aussage hab ich Dir mitgeteilt das Dinge sich wiederholt haben, was nun einmal so war, wodurch "alte" Versionen dann plötzlich doch nicht mehr so alt waren..

    Und der Wink mit Zaunpfeiler das es eben ein komplettes Versionschaos gibt
    hast Du mit dem obigen Quote "gekontert".

    Fakt ist,
    weder bekommst Du die neuesten Shader auf Deinem Smartphone zum Laufen,
    noch ist die Welt GL 2.0 frei (und wird s so schnell auch nicht werden).

    Und damit war s das für mich weil diese "veraltet" Debatte einfach zu nichts führt 🙂

    0
  • K

    Also, ich will, dass meine Kamera immer nach Links/Rechts rotiert, wenn ich A/D druecke, nach Oben/Unten bei W/S und rollen ueber Q/E, also ein lokale Koordinatensystem. Genau das ist aber nicht der Fall.

    0
  • C

    pVoid schrieb:

    Kernaussage war - In OpenGL gibts keine Kamera, wenn muss man die selber implementieren.

    Was extrem sinnlos war, weil Kellerautomat das offensichtlich bereits verstanden hat. (Er hat ja schon eine Kamera selbst implementiert, sie funktioniert nur nicht.)

    pVoid schrieb:

    Und der Wink mit Zaunpfeiler das es eben ein komplettes Versionschaos gibt

    Es gibt kein komplettes Versionschaos und dass man auf Smartphones keine Tessellation-Shader bekommt hat nichts damit zu tun, dass dein verlinktes Tutorial auf der fixed-function Pipeline aufbaut, die er nicht benutzt, die wie bereits erwähnt auf so ziemlich jedem Gerät der Welt völlig veraltet ist, und die ihm deswegen auch kein Stück weiter hilft.

    0
  • D

    in OpenGL gibt es keine Kamera, aber in vielen Applikationen gibt es eine Kamera, die mit Hilfe von OpenGL implementiert wird. die Frage ist nun, wie implementiere ich mit OpenGL eine Kamera

    wenn man sich wie in der fixed Pipeline mit einer Projektionsmatrix in festen Weltkoordinaten bewegt, verwendet man für die Kamera die Winkel Heading (Yaw), Pitch und Roll. diese müssen in der richtigen Reihenfolge multipliziert werden, weil man sonst einen Drehwurm bekommt

    http://www.google.de/#hl=de&sclient=psy-ab&q=opengl+heading+pitch+roll

    0
  • C

    Scheinbar kann Kellerautomat nicht darauf hoffen, hier noch mal Hilfe zu bekommen. 😃

    0
  • D

    ich habe mir den Programmcode nicht so im Detail angesehen. aber die Fehlerbeschreibung klingt so, als würde er Heading, Pitch und Roll in der falschen Reihenfolge multiplizieren.

    0
  • C

    Sollte man vielleicht, bevor man mit einem random Google-Link antwortet.

    0
  • D

    in seinem Programm kann ich Heading, Pitch und Roll nicht erkennen. deshalb von mir der Vorschlag, Heading, Pitch und Roll zu verwenden

    das läuft meistens in den 2 Schritten:

    1. Interaktoren (Maus, Tastatur) verändern Heading, Pitch und Roll
    2. aus Heading, Pitch und Roll Projektionsmatrix berechnen

    (nicht mit den Interaktoren die Projektionsmatrix direkt verändern)

    0
  • K

    Mir ist schon bewusst, dass es nicht gerade die beste Art ist, euch einfach den Code hinzuklatschen. Allerdings habe ich, wie schon geschrieben, bereits alles versucht und keine Loesung gefunden.

    Zur Speicherung der Rotation benutze ich eine 3x3 Matrix, die ich bei jeder Rotation veraendere. Jeden Frame erweitere ich diese 3x3 Matrix mit der Position der Kamera auf eine 4x4 Matrix (glm::mat4 from_rot_pos(glm::mat3 rot, glm::vec3 pos)), multipliziere diese dann mit der Projektionsmatrix und uebergebe sie anschliessend an den Vertex-Shader.

    Mein Problem ist nun, die richtige Veraenderung dieser Rotationsmatrix zu berechnen. Dazu habe ich mir aus Wikipedia die allgemeine Rotationsmatrix um eine Achse kopiert und in die Funktion glm::mat3 rotate_axis(glfloat angle, glm::vec3 axis) gepackt. Ich bin mir ziemlich sicher, dass ich diese Achsen, um die gedreht werden soll, einfach nicht richtig berechne.

    0
  • C

    dd++: Was hat die Projektionsmatrix mit der View-/Camera-Matrix zu tun?

    0
  • P

    Hallo 🙂

    Kellerautomat man muss sich einfach entscheiden ob man ein Objekt dreht
    ( zb die Wetterfahne auf einem FESTSTEHENDEM Turm )
    oder ob man eine Kamera simuliert.
    ( Wetterfahne und Turm bewegen sich gemeinsam )
    Wenn man das einmal geistig verinnerlicht hat kann man auch Beides gemeinsam realisieren.

    Fürs "Objekt drehen" haben Dir dot und Nathan Hintergrund und Beispiel geliefert.

    Für die Kamera hat Dir dd++ den Hintergrund geliefert
    und sollte Dir mein Beispiel zu alt sein gibts reichlich im Netz
    denn eine Kamera birgt noch mehr Tücken als nur die Projektion.

    Gibts jetzt Kekse ? 😃

    0
  • K

    Ehm... mir ist der Unterschied zwischen eine Kameradrehung und einer Objektdrehung schon klar...
    Das Problem liegt in der Implementierung der Kamera, da ich keine Rotation um deren lokale Achsen hinbekomme...

    0
  • P

    Wenn Du eine kamera rotierst kann Dein Wuerfel sich aus dem Sichtfeld bewegen
    ist das wirklich was Du haben willst ?

    0
  • K

    Ja, das wollte ich von Anfang an. Jedenfalls hab ich das Problem jetzt dank cookys IRC-Hilfe geloest. Das Problem war, wie schon gedacht, das berechnen der Rotationsachsen. Das mache ich nun so:

    auto rotx = glm::vec3{ camrot[0][0], camrot[1][0], camrot[2][0] };
		auto roty = glm::vec3{ camrot[0][1], camrot[1][1], camrot[2][1] };
		auto rotz = glm::vec3{ camrot[0][2], camrot[1][2], camrot[2][2] };

    Und auf die Tastendruecke reagiere ich dann hiermit:

    if(glfwGetKey('W'))
			camrot *= rotate_axis(camera_rotation, rotx);

		if(glfwGetKey('S'))
			camrot *= rotate_axis(-camera_rotation, rotx);

		if(glfwGetKey('A'))
			camrot *= rotate_axis(camera_rotation, roty);

		if(glfwGetKey('D'))
			camrot *= rotate_axis(-camera_rotation, roty);

		if(glfwGetKey('Q'))
			camrot *= rotate_axis(camera_rotation, rotz);

		if(glfwGetKey('E'))
			camrot *= rotate_axis(-camera_rotation, rotz);
    0
  • P

    Asche über mein Haupt ><

    Bis zum letzten Post hätt ich schwören können
    da ist ein bewegter Würfel im Spiel.

    Dann muss ich wohl die Kekse rüberreichen 🙂

    0
  • K

    Der Wuerfel ist auch bewegt, nur dass die entsprechende Zeile auskommentiert ist 😉

    0

  • Du musst einfach die richtige Rotationsreihenfolge verwenden. In deinem Fall dürfte das ZXY sein. Multiplizier nicht bei Tatstendrücken Rotationen zusammen, sondern merk dir die Rotationswinkel und bau die Matrix dann damit...

    0
  • K

    Was heisst denn 'richtige' Rotationsreihenfolge?

    0

  • Was genau ist daran unklar? Die Reihenfolge, in der Rotationen angewendet werden, macht einen Unterschied!? Ergo ist es absolut nicht egal, in welcher Reihenfolge du deine X, Y, Z Rotationen zusammenmultiplizierst...

    0
Anmelden zum Antworten