Ich lese mir gerade das Bluebook durch (also die OpenGL SuperBible - leider noch 4th ed.).
Natürlich programmiere ich mir immer mal wieder kleine Beispiele, um den gelesenen Stoff auch zu verinnerlichen bzw. zu verstehen.

Nun möchte ich mich innerhalb einer Szene bewegen können, was ich durch einen Camera-Actor realisiere.
Dies ist eine Klasse, die eben die Position, einen Vorwärtsvektor und einen Upvektor enthält und natürlich eine entsprechende Schnittstelle um die Kamera zu bewegen und um jede beliebige Achse zu drehen (pitch,yaw,roll).
Die entsprechenden Daten werden alle in einem array gespeichert, der eine Modelmatrix darstellt. Bei jeder Drehung multipliziere ich die Matrix mit der entsprechenden Rotationsmatrix.
Klappt auch alles soweit einwandfrei.

Die Kamera wird dann zu Beginn jedes Renderdurchlaufs über gluLookAt positioniert. Auch alles wie erwartet.

Mich würde nun interessieren, was genau gluLookAt eigentlich tut.
Ich habe versucht anstatt von gluLookAt ein glLoadMatrixf bzw glMultMatrixf aufzurufen - allerdings ist dann das Verhalten anders.
Als Achsen werden dann weiterhin die standardmässigen Achsen (also 1,0,0 - 0,1,0 und 0,0,1) verwendet.

Ich habe nun versucht den Artigel über gluLookAt hier im Wiki zu verstehen.
Allerdings erschliesst sich mir nicht ganz:
glMulMatrixf(@M[0,0]);
glTranslated(-EyeX, -EyeY, -EyeZ);

Also es findet wie erwartet eine Matrix-Multiplikation statt (ich vermute, die Angabe der indices wird in delphi nur gemacht, um das erste Elemnt des arrays anzugeben - wäre also in C++ ein einfacher Aufruf von glMultMatrixf(M);)
Danach erfolg tnoch ein Translate.
Da meine Matrix allerdings die Position in der vierten Matrixspalte schon enthält (also indices 12,13,14) benötige ich meinem Verständnis nach kein Translate mehr, da dadurch ja genau diese Werte gesetzt werden.

Also sollten im Endeffekt doch gluLookAt und glMultMatrix bzw glLoadMatrix (ist ja egal da ohnehin mit der Einheitsmatrix multipliziert wird bei vorherigem glLoadIdentity) das gleich Ergebnis liefern. Eigenartigerweise ist dies nicht der Fall und ich komm nicht drauf, warum nicht.

gluLookAt funktioniert so wie das im Wiki steht.


Ich denke hier liegt dein Denkfehler. glTranslate setzt nicht einfach nur die Werte, sondern baut eine Matrix und multiplziert diese mit der bisherigen Matrix! Du musst daher das dot-Produkt der zugehörigen Spalte mit der Eye-Position bilden um die korrekte Position zu erhalten.

Hier mein Code für gluLookAt aus CoolMath:

_________________
Yeah!

Ah, genau so war es.
In meiner Matrix waren die Weltkoordinaten der Kamera gespeichert. Nachdem ich diese mit den entsprechenden Vektoren der Matrix multipliziert habe, funkioniert auch ein einfaches glMultMatrixf.

Grummel - als Anfänger auch nicht so leicht zu verstehen mit Eye-Koordinaten und World-Koordinaten und dem ganzen Matrizengerechne. Da kommt man mal schnell durcheinander.

Ich danke dir mal wieder für deine Hilfe

Wobei das doch doppelt gemoppelt ist.
f = forward-Vektor
s = x-achsen-vektor
u = up-vektor

wenn
s = f x up und u = s x f, dann ist u = up und zwar mit richtigem Vorzeichen.

Unter der Annahme das f orthogonal zu up ist...ja...aber das nimmt gluLookAt nicht an. Das hat den Vorteil, dass man den Up-Vektor z.B. einfach auf (0,1,0) setzen kann und der sich dann selbst nen vernünftigen Vektor ausrechnet. Funktioniert natürlich nur solange man keinen Looping fliegen will.

_________________
Yeah!

Ah gut, das stimmt natürlich, wenn man nicht davon ausgehen kann, dass up orthogonal auf f steht erhält man so natürlich immer den richtig berechneten up-Vektor.

Möchte aber jetzt nicht den Versuch starten mir vorzustellen, wie ein up-Vektor nicht orthogonal zum forward-Vektor stehen kann

So kompliziert ist das nicht (*). Ok, oben ist bei uns die Y-Achse, also (0,1,0) was wir dann auch als Up-Vektor nehmen. Jetzt sitzen wir in einem Auto das gerade einen Berg hochfährt. Unser forward-Vektor ist daher (10,3,0).normalized(). Und schon sind beide Vektoren nicht mehr orthogonal.



(*) behauptet der Informatik-Student im 12. Semester

_________________
Yeah!

Ja gut, wenn man es so sieht.
Allerdings berechne ich bei verändertem forward-Vektor auch immer gleich den up-Vektor. Somit hab ich den Fall nie. Wäre nämlich z.b. relativ doof, wenn das Auto ne Klippe runterfällt und der forward-Vektor auf einmal (0,-10,0).normalized() wird

Das war oben mit dem Looping gemeint.

_________________
Yeah!