@TheWinner: ich finde Du hast recht. GERADE bei SzenenGraphen braucht man Push/Pop. Aber ich glaube ihr redet hier alle am Problem vorbei. Was der Threadstarter bekrittelt hat, hat nichts mit dem MatrixStack zu tun, denn er hat nur die Nomenklatur durcheinander gebracht, und das wollen wir ihm nicht ankreiden..

Ich glaube, er meint gar nicht den Matrix Stack, sondern eben die Reihenfolge, wie die Matrizen, die sich aus Translate/Rotate/Scale erechnen, in die aktuelle Matrix hineinmultipliziert werden. Wenn ich es mal auf den Punkt bringe:

Ich nehme ein einfaches Quad aus der XY-Ebene und berechne für glRotate einen Winkel, der sich laufend fortrechnet, damit das Quad sich dreht:

Die Reihenfolge:
1.glRotate(Winkel,1,0,0)
2.glTranslate(0,0,-5)

Das erzeugt in OpenGL ein Quad, das um mich herum rotiert: es verläßt in periodischen Abständen den Bereich, wo ich es sehen kann.

Flash nennt es im Wiki "Achsen neu ausrichten". Es gibt aber auch eine technische Erklärung, die mir mehr einleuchtet:

Wenn ich jetzt per Hand je eine ShiftMatrix und eine Rotationsmatrix erzeuge und sie per glMultMatrixf hineinfüttere, schaut es genauso aus wie vorher, gibt also keinen Unterschied zu OpenGL (klar, das "Hineinmultiplizieren" erledigt ja OpenGL).

AAAAAAABER wenn ich das gleiche Ergebnis wie in OpenGL mittels einer Matrizenmultiplikation erzielen will, dann muss ich das so machen:


Und, wie ihr seht, habe ich das ganze betitelt: "First shift, then rotate". Das bedeutet, dass meiner Meinung nach die Matrizenmultiplikation hier zuerst die Verschiebung ausführt (die rechte Matrix) und anschliessend erst die Rotation. Das sich drehende Quad sieht haargenauso aus wie das OpenGL-Resultat.

Wenn ich die Matrizenmultiplikation umdrehe:

TFMatrix:= MatrixMultiply(MatrixShift,MatrixRotate);

rotiert das Quad vor meinen Augen, denn es führt die Rotation zuerst aus und verschiebt dann. Ich glaube daher, dass Opengl die Matrizenmultiplikation verkehrt herum ausführt, und zwar ist das kein Bug, sondern ein Feature, gut verwendbar in ganz bestimmten Situationen. Aber leider dazu angetan, um die Leute zu verwirren.

HINWEIS: ich erzeuge meine eigenen Matrizen "per Hand" und ich multipliziere sie mit einer selbstgebastelten Funktion. Könnte natürlich sein, dass die falsch ist. Auf Verlangen stelle ich den Sourcecode gern zur Verfügung.
Nach dem Motto: "Glaub nichts, was Du nicht selbst gefälscht hast."

Allerdings müsste sich das gleiche auch mit der Geometry.pas überprüfen lassen.
Traude

@TheWinner:
Ich hab das selbst auch nur einmal gemacht und zwar auch in der Uni (und dort auch mit massiven nutzen von Push/PopMatrix). Ich hab einfach mal vermutet, dass es anders auch noch schneller geht. Diese Matrixoperationen sind ja, glaub ich mich erinnern zu können, nicht besonders performant.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nicht so schnell. Es könnte doch sein, dass ich gar nicht recht habe? Schließlich habe ich das Redbook nicht gelesen.
Und es kann durchaus sein, dass ich nicht recht habe: versuch mal, im Web was über die Reihenfolge der Matrizenmultiplikation herauszufinden. Bei meinem letzten Versuch bin ich gar nicht mehr fündig geworden. Das Web wird immer "mainstreamiger".

Matrizen verkehrt herum zu multiplizieren wäre ein einfacher, aber fataler Fehler, der mir passieren könnte.
Ich meine, irgendjemand sollte meine obige Aussage überprüfen. Das sollte einfach sein. Es ist nur ein winziges Programm.

Du hast recht mit der Reihenfolge. In der Uni sagte uns der Übungsleiter, dass OpenGL die Matrizen von rechts her multipliziert. (glaube sorum wars).

Wenn du also in OpenGL schreibst:

Idendity
Scale
Translate
rotate

dann macht openGL daraus

M = rotate x ( translate x ( scale x idendity) )

Aber vielleicht kann das ja mal einer unserer Mathematiker richtig stellen. Wozu haben wir die denn im Forum.

_________________
Blog: kevin-fleischer.de und fbaingermany.com