wollte eigentlich nur ne kleine korrektur anbringen bezüblich:

http://wiki.delphigl.com/index.php/Tuto ... hse_drehen

und zwar ist folgendes falsch:

ZITAT:##########################################################

glLoadIdentity;
glRotate(12, 1, 0, 0);
glRotate(15, 0, 1, 0);
glRotate(2, 0, 0, 1);
DrawObjekt;

Hier wird also zuerst die OpenGL interne Matrix zurückgesetzt (glLoadIdentity)
und dann um die X, die Y und zum Schluss um die Z-Achse gedreht. Somit läuft in
OpenGL folgendes ab:

* Matrix zurücksetzen.
* 12 Grad um die X-Achse drehen (wird sofort ausgeführt)
* 15 Grad um die Y-Achse, ausgehend von der bereits gedrehten X-Achse (wird
auch sofort ausgeführt).
* 2 Grad um die Z-Achse drehen, ausgehend von den bereits gedrehten X und
Y-Achsen.

ZITAT ENDE ####################################################

also die reihenfolge ist EXAKT umgekehrt!
Richtige rotations-reihenfolge erhält man indem man immer von der geometie
(DrawObjekt) nach oben geht.

also:
* 2 Grad um die Z-Achse drehen, (zuerst)
* 15 Grad um die Y-Achse, (anschliessend)
* 12 Grad um die X-Achse, (ZUM SCHLUSS)

warum? OpenGL verwendet einen MATIX STACK (FIST IN LAST OUT).

durch den stack ergibt sich folgende rechenreihenfolge:

p' = Rx(12)*Ry(15)*Rz(2) * p

wobei zuerst Rz mit p multipliziet wird dann dieses Ergebniss mit Ry usw.

das könnte auch die im tutorial erwähnten komischen effekte erklären bei
rotationen um 3 achsen erklären.

sorry wenn das klugscheisserich rüberkommt, aba das ist elementar und wenn das
einer für richtig hält wird er oft beim proggen verzweifeln


zum schluss noch an dankeschön ans DGL-Team, auch wenn ich mit Delphi nichts zu tun hab muss ich sagen eure site ist super, es gibt viel zu wenig deutsche OGL seiten, macht weiter so.

recht hast Du. Scheint so, als müsse man die Sätze darunter dann auch ein wenig umstellen - werde mal sehen, daß ich am Wochenende dazukomme - heisst soviel wie, ich komme vorher nicht dazu, wenn sich also jemand drum reisst

Danke übringes für das Feedback und das genaue lesen.

Erledigt.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Nico sollte trotzdem nochmal drüber gucken. Vielleicht hat sich der Fehler in einigen Aussagen fortgesetzt, bzw. vielleicht würde er mit seinem heutigen Wissen Sachen anders erklären.

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

Hallo,
Bin dabei, mir einige ältere Beiträge anzuschauen. Dabei bin ich auf diesen Thread gestoßen, der ein rundes Jahr alt ist, bei mir aber einige Irritationen hervorruft. Entweder habe ich einiges nicht richtig verstanden - oder die Verfasser nicht. Dabei ist das Thema unheimlich wichtig, wenn man die Zusammenhänge verstehen will, und zwar genau. Entschuldigung also, wenn ich ein Relikt wieder ausgrabe. Das Tutorial, um das es letzten Endes geht, sollte ja noch aktuell sein.



Ich versteh nicht, warum die Reihenfolge einmal falsch sein soll, anders herum richtig. Genauer: Unter welcher Prämisse kann man eine Rotationsreihenfolge als richtig oder falsch bezeichnen?



Versteh ich ebenfalls nicht. Was hat der Stack mit der Reihenfolge der Rotationen zu tun? Ich dachte immer, alle Rotationen, überhaupt alle Transformationen steckten in der einen Top-Matrix. Bis jetzt bin ich immer davon ausgegangen, dass der Matrix-Stack nur gebraucht wird, um ältere Matrixzustände mit glPopMatrix wieder zu restaurieren, quasi als Komfortangebot von OpenGL.

Hi,

ich bin zwai jetzt kein Experte in Sachen Matrix Berechnung aber ich weis das in OpenGL für die Berechnung eines Objektes der Matrix-Stack nacheinander abgearbeitet wird.

Nehmen wir mal folgendes Beispiel an:

glTranslatef (0.0, 0.0, -5.0);
glRotatef (25, 0, 1, 0);

{Dreieck zeichnen}


Hier wird erst das jeweilige Vertex des Dreiecks genommen und danach wird die Rotation von Stack genommen und mit dem Vertex verrechnet.
Dann wird die Translation von Stack genommen und mit dem Rotierten Vertex verrechnet.

Ich hoffe das man die Erklärung auch verstehen kann .

_________________
ghost-site.de

Moment.

Ich glaube erin hat nicht ganz unrecht.
Es stimmt, dass alle Manipulationen nur in der aktuellen Matrix verrechnet werden. Auf dem Stack landet eine Matrix nur wenn man sie drauflegt. (Push)

Wenn du rotierst multiplizierst du die aktuelle Matrix mit der rotationsmatrix. Das ergebnis ist dann die neue aktuelle Matrix. Die vorherige aktuelle Matrix ist dann weg. Du kannst sie aber manuell per PushMatrix sichern.

Noch ein Punkt wieso die einzeloperationen nicht Matrizen auf den Matrix-Stack legen ist der:
Der Matrix-Stack ist begrenzt. Wenn die Einzeloperationen was drauflegen, dann wäre die Anzahl an Drehungen/Verschiebungen/Scalierungen begrenzt. Ist sie aber nicht.

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

Verstehen schon, aber leider nicht nachvollziehen. Das Tolle an den Matrizen ist ja, dass in einer einzigen Matrix eine ganze Kette von Transformationen gespeichert werden kann, natürlich mit allen Tücken, die die Reihenfolge mit sich bringt. Nehmen wir an, wir haben glTranslate aufgerufen. Dann steckt die Verschiebung in der aktuellen Matrix. Wenn wir anschließend irgendein glRotate bemühen, wird eine lokale Rotationsmatrix erstellt und mit der aktuellen Matrix multipliziert. Diese enthält dann beide Transformationen. Gleichzeitig wird die vorherige aktuelle Matrix im Stack nach unten geschoben und kann, wenn der User in der Hierarchie einen Schritt zurückgehen möchte, mit glPopMatrix wieder nach oben geholt werden. Ich denke schon, dass der Stack nichts mit den Problemen der Reihenfolge zu tun hat.

Was die Reihenfolge von Rotationen betrifft, so scheint sich der Irrglaube festgesetzt zu haben, dass OpenGL die Befehle rückwärts abarbeitet. Definitiv: Die aktuelle Modelview-Matrix wird genau in der Reihenfolge aufgebaut wie die Befehle eingegeben werden. Wer's nicht glaubt, sollte mal schrittweise vorgehen, die Matrizen auslesen und untersuchen.

Richtig ist trotzdem, dass wir die Rotationsbefehle anders herum eingeben sollten als wie wir uns die Rotation vorstellen. Das hängt mit dem assoziativen Charakter der Matrixmultiplikationen zusammen. nomedsoft hat es schon richtig wiedergegeben:

I * (R1 * (R2 * (R3 * V)))

Die Klammern deuten an, dass das Koordinatensystem schrittweise lokalisiert wird. Jede Transformation erzeugt ein neues Koordinatensystem (Vektorraum), basierend auf dem globaleren. Es ist aber angebracht, vom lokalsten Koordinatensystem auszugehen und sich zum globaleren vorzuarbeiten. Also von hinten nach vorne. Wenn du ein Ding näher heranrücken und anschließend drehen willst, tust du gut daran, zuerst zu drehen. Aber das dürfte klar sein.

Schwieriger, wenn es nur um Rotationen geht. Mal ein Beispiel, auch zum Nachvollziehen. Du willst eine Kiste um 45° um die y-Achse drehen, anschließend nach vorne kippen, so dass du besser draufgucken kannst. Machst du das in dieser Reihenfolge, dann steht die Kiste schief, nach links oder rechts gekippt, als wäre sie auch um die z-Achse gedreht worden. Das ist natürlich nicht der Fall, weil die Drehung um Y gleichzeitig die X- und Z-Achse verdreht hat. Es ist nicht falsch, sondern nur logisch, dass die Kiste schief steht. Wenn du aber die Kiste zuerst um x herum nach vorne kippst, dann das Ganze um y drehst, erreichst du was du willst.

Es ist also schon wichtig, vom lokalen Koordinatensystem zum globalen zu gehen, also von hinten nach vorne. Dass das bei der Drehung in der Reihenfolge z, y, x passieren muss ist - Entschuldigung - in meinen Augen Unsinn. Die Frage ist, ob es bei mehreren Drehungen eine wichtigste gibt. Theoretisch nein, doch von den Sehgewohnheiten her wohl. Nimm eine Kamera, stelle sie auf ein Stativ und richte sie auf ein Motiv aus. Was machst du als erstes? Du drehst sie um die Stativachse (y). Dann stellst du sie nach oben oder unten (x). Als letztes drehst du sie vielleicht noch um die optische Achse, um den Horizont gerade zu kriegen (z). Das heißt, es ist einfach günstig, bei solchen Drehungen die Reihenfolge z, x, y einzuhalten, damit kommen wir am besten zurecht und erreichen am ehesten das, was wir uns vorstellen. Das Beispiel zeigt übrigens, wie die lokaleren Koordinatensysteme entstehen. Wenn du die Kamera um y drehst, drehst du dich mit und steckst damit mitten im neuen Koordinatensystem, so dass du es gar nicht merkst. Bei OpenGL sehen wir die Sache aber immer von außen.

Puh, das war mal gründlich von der Leber geredet. Wenn ich was falsch sehe, korrigiert mich. Wenn ich das richtig sehe, dann sollte jemand noch einmal kritisch über das geänderte Tutorial gehen. Das alles sind keine Kleinigkeiten, sondern es geht darum, die vielleicht wichtigste Sache in OpenGL zu verstehen.

Nur am Rande. Dass sich beharrlich die Meinung hält, OpenGL arbeite die Befehle in umgekehrter Reihenfolge ab, dafür scheint das OpenGL Redbook ein wenig verantwortlich zu sein. Die Autoren sind redlich bemüht, es Anfängern leicht zu machen, und tatsächlich bringen sie das Bild von der umgekehrten Sichtweise. An entscheidender Stelle steht aber das Wörtchen "seem".

Also das kommt jetzt so rüber als würde OpenGL automatsich mit jedem glTranslate, glRotate oder glScale aufruf den Matrix-Stack zumüllen. Dem ist aber nicht so. Keinesfalls. Das wird allein von glPushMatrix erledigt. Sonst müsste man ja nach jedem Frame glPopMatrix so oft aufrufen, wie man eine von den Transformationsoperationen durchgeführt hat.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich verstehe noch nicht was eine Matrizenmanipulation mit dem Stack zu tun haben soll?

Vielleicht hilft das: http://de.wikipedia.org/wiki/Stapelspeicher

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Das ist es ja was ich gerade sagte: Es hat nichts damit zu tun.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Gut, dass die diesen Punkt richtig stellst. Ich hatte ein bißchen einen Taschenrechner mit UPN vor Augen, wo bei jeder Eingabe der Stack verschoben wird. Es stimmt, für Stackverschiebungen sind glPopMatrix und glPushMatrix zuständig.

Aber das bestätigt noch mehr meine These, dass der Stack absolut nicht für die Reihenfolge von Operationen zuständig ist. Alles steckt in der Top-Matrix.

Und das ist der Grund, warum mir dieses aufgestoßen ist. Die Begründung ist schlicht falsch und damit so einiges, was daraus abgeleitet wurde.

Ich glaube du hast recht. Da hat wohl jemand den Scene-Graph mit dem Matrixstack verwechselt. Wenn man die Rotationsmatrix eines Objektes bestimmen will, muss man den Scenegraph von der Wurzel bis nach unten zum entsprechenden Blatt durchlaufen und alle Operationen (Matrizen) auf dem Weg durchmultiplizieren.

Mit dem Stack hat das gar nix zu tun, außer .... hmmm... Anfänger benutzen beim Umgang mit dem Scenegraph recht viel Push und Popmatrix (bei jedem Schritt !). Dort stimmt die Aussage, leider hat das nix mit der Realität der Programmierung zu tun.

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

Wie läufst du dann einen Scene-Graph entlang wenn nicht mit push und pop matrix? Berechnest du die matrizen alle von Hand und nimmst loadmatrix?

_________________