OpenGL: Kamera bewegen

[cooky451]

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

[dd++ 0]

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.

[cooky451]

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

[dd++ 0]

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)

[Kellerautomat]

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.

[cooky451]

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

[pVoid]

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 ?

[Kellerautomat]

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...

[pVoid]

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

[Kellerautomat]

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);

[pVoid]

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

[Kellerautomat]

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

[dot]

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...

[Kellerautomat]

Was heisst denn 'richtige' Rotationsreihenfolge?

[dot]

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...

[Kellerautomat]

Das ist mir schon klar, aber warum "In deinem Fall dürfte das ZXY sein.". Und warum nicht zusammenmultiplizieren? Damit vermeide ich das Problem doch?!

[dot]

Drück mal ein Weilchen auf A, dann ein Weilchen auf W und dann ein Weilchen auf Q und sag mir, ob die beobachtete Bewegung deiner Kamera dem entspricht, was du haben willst.

[Kellerautomat]

Im Moment: Ja. Warum?

[dot]

Ah, du berechnest nun die Achsen ständig neu, das ist mir irgendwie entgangen. Numerisch ist das ganze vermutlich suboptimal, aber wenns für dich funktioniert, dann

[Kellerautomat]

Alternativen?
Und sind Quaternionen eigentlich einen Blick wert?