Ich hab mich heute wieder einmal mit der Mathematik hinter OpenGL beschäftigt und wollte mir die Projektions Matrizen ansehen, also Orthogonal und Perspektivisch.
Diese sehen für mich sehr nahe liegend aus, aber ich kann nicht sagen was jetzt die vom DGL Wiki anders machen...
Ich hab nur gesehen das da noch was mit Clipping-Pane drinnen ist...
Aber eine Frage hab ich noch... die quält mich schon den ganze Tag und muss ich jetzt los werden^^
Wieso kann man so einfach die 3 Rotationsmatrizen (x-, Y- und Z-Achse) multiplizieren?
Ich meine, was steckt da mathematisch dahinter?
Wieso kann man so einfach die 3 Rotationsmatrizen (x-, Y- und Z-Achse) multiplizieren?
Da du Student zu sein scheinst (das schließe ich aus deiner PM) verweise ich mal auf die lineare Algebra. Solltest du in quasi jedem technischen Studiengang in irgendeiner Form hören müssen.
Vom Prinzip sind diese ganzen Trnasformations-Matrizen nichts weiter als als das Wechseln zwischen verschiedenen Basen, also Basiswechselmatrizen. Die Spalten der Matrix sind die Basis-Vektoren, oder um es ohne Fachbegriffe auszudrücken, die Spalten sind die Koordinatenachsen auf die die XYZ-Achsen abgebildet werden. Da Matrix-Multiplikation assoziativ ist und die Multiplikation nichts weiter als die Verkettung dieser Basiswechsel ist, darfst du mehrere Matrizen zu einer einzigen zusammenfassen:
Du hast drei Matrizen A, B und C, sowie einen Vektor v:
A* (B * (C * v)) = (A * B * C) * v
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Zitat:
Wieso kann man so einfach die 3 Rotationsmatrizen (x-, Y- und Z-Achse) multiplizieren? Ich meine, was steckt da mathematisch dahinter?
Matrizen sind grundsätzlich bloß eine besondere Schreibweise für lineare Gleichungssysteme, man kann sie aber auch als mathematische Abbildungen benutzen.
Sie funktionieren daher nach den Vorschriften für Abbildungen. Wenn man Transformations-Matrizen miteinander multipliziert, dann bedeutet das geometrisch, dass mehrere Abbildungen hintereinander durchgeführt werden, und dafür gibt es mathematische Regeln, siehe auch hier http://mo.mathematik.uni-stuttgart.de/kurse/kurs7/seite17.html. Leider hab ich keine eine gute Seite gefunden, wo die Verknüpfungsregeln für Abbildungsmatrizen dargestellt sind.
Wenn man einen Punkt mit mehreren Transformations-Matrizen multiplizieren (=abbilden) will, so kann man das gleiche Ergebnis erzielen, wenn man die Transformations-Matrizen vorher miteinander in der richtigen Reihenfolge (!) multipliziert und das Ergebnis auf den Punkt anwendet. Es gibt dafür einen Beweis, aber da bin ich überfragt, denn ich bin kein Mathematiker. Daher kann ich mit dem Begriff "Basis-Wechsel" nur sehr bedingt etwas anfangen.
EDIT: ich habe heute früh noch herumgesucht: Rechenregeln für das Rechnung mit Matrizen sind in der Wikipedia zu finden, insbesondere die Regeln für die Multiplikation sind für uns interessant:
http://de.wikipedia.org/wiki/Matrix_(Mathematik)#Matrizenmultiplikation. (tut leid, DGL spinnt heute früh, ich konnte die url nicht als Link eingeben).
Am wichtigsten ist der Satz: "Zu beachten ist, dass Matrizenmultiplikation im Allgemeinen nicht kommutativ ist, d. h. im Allgemeinen gilt B x A <> A x B", dahinter steckt die einfache Tatsache, dass es einen großen Unterschied macht, ob man seine Punkte zuerst rotiert und dann verschiebt oder zuerst verschiebt und dann rotiert.
Zuletzt geändert von Traude am Mo Mär 16, 2009 08:52, insgesamt 1-mal geändert.
Daher kann ich mit dem Begriff "Basis-Wechsel" nur sehr bedingt etwas anfangen.
Ok, nochmal etwas ausführlicher. Eine Basis ist eine Menge von linear unabhängigen Vektoren mit denen du dein Koordinatensystem ausdrückst. Also angenommen du hast Spaltenvektoren X,Y,Z und T, sowie einen Punkt p = (x,y,z,w), dann kannst du mit Hilfe der Basis das Koordinatensystem wechseln. Also von der üblichen Einheitsbasis (1000), (0100), (0010) und (0001) wechselst du zur Basis X,Y,Z,T. Dieses neue Koordinatensystem könnte dann zum Beispiel um 30 Grad gedreht sein, etc. Das geht indem du einfach die Komponenten mit den Basisvektoren multiplizierst:
p' = x * X + y * Y + z * Z + w * T
Genau das gleich erhälst du wenn du die Basisvektoren hintereinander schreibst und als 4x4 Matrix interpretierst.
Eine einfache Rotationsmatrix die um die X-Achse mit Winkel a rotiert sieht also so aus:
Code:
| 1.00.00.00.0 |
| 0.0 cos(a) sin(a) 0.0 |
| 0.0 -sin(a) cos(a) 0.0 |
| 0.00.00.01.0 |
Es werden einfach nur die Basisvektoren Y und Z rotiert, damit rotierst du das Koordinatensystem.
Jetzt stellt sich noch die Frage warum wir eigentlich mit 4 Dimensionen rechnen um 3 Dimensionen darzustellen. Das Problem ist das man mit einer Matrix nur lineare Transformationen durchführen kann. Das bedeutet (unter anderem) das der Vektor (0,0,0) immer auf (0,0,0) abgebildet wird. Ein kleines Experiment:
p' = 0 * X + 0 * Y + 0 * Z
Es ist offensichtlich das es keine XYZ geben kann so das p' nicht der Nullvektor ist. Um nun also das Koordinatensystem nicht nur zu drehen, zu skalieren oder zu scheren sondern auch zu verschieben muss man die Verschiebung T einfach nur addieren.
p' = x * X + y * Y + z * Z + T = Mp + T
Das ist natürlich unhandlich, man kann nicht mehr einfach nur Matrizen kombinieren, sondern muss die Transformation schrittweise ausführen. Um also affine Transformationen im 3D-Raum darzustellen verwendet man eine Dimension mehr. Als Eingabe nimmt man den 3D Punkt und ergänzt die letzte Koordinate mit einer Eins:
p = (x,y,z,1)
Schreibt man nun T in die letzte Spalte der Matrix erhält man das gewünschte.
Nein. Angenommen du hast die Farbe RGB 25,25,25 an allen vier Ecken. Dein Rechteck müsste also überall die gleiche Farbe haben, nämlich ebenfalls RGB 25,25,25. Bei dir kommt da aber RGB 100, 100, 100 raus, weil du C1 bis C4 addierst.
Farbinterpolation macht man üblicherweise nicht per Rechteck, sondern per Dreieck. Insbesondere weil die Grafikkarte sowieso nur Dreiecke verarbeiten kann.
Das Dreieck ist definiert durch die Punkte ABC, sowie die Farben FGH. Fangen wir statt den Farben mal mit der Position an, da kann man nämlich leichter überprüfen ob das Ergebnis richtig ist. Zunächst brauchen wir ein Koordinatensystem....ein Dreieck ist flach, also zwei Vektoren. Wir nehmen
X = B-A
Y= C-A
Wir können nun jeden Punkt P innerhalb des Dreiecks erreichen indem wir folgendes berechnen:
P = A + b * X + c * Y
Der Punkt liegt genau dann im Dreieck, wenn die Koeffizienten b und c größer Null sind und b + c <= 1.
Nun, das ist etwas unhandlich, also nehmen wir noch einen dritten (abhängigen) Koeffizienten:
P = a * A + b * B + c * C
wobei a = 1 - b - c bzw. a+b+c = 1, sowie a,b,c >= 0
Genau das gleiche kannst du auch mit den Farben machen, also:
Farbe = a * F + b * G + c * H
wobei a+b+c = 1, sowie a,b,c >= 0
Wenn du nun ein Rechteck willst nimmst du zwei Dreiecke. Dabei macht es allerdings einen Unterschied wie du die Diagonale legst. Also ob du nun (bei dir oben im Bild) die Diagonale von C1 nach C4 oder von C2 nach C3 legst.
Ich hab jetzt einmal die Matrix aus dieser Ausarbeitung in einen kleinen Renderer eingebaut...
Welchen Wert sollte d dann ungefähr annehmen? Wenn ich d=1 setzte, dann wird alles was (find ich) ein bischen stark
verzert...
Bei größeren zahlen siehts dann ganz gut aus.
Wundert mich nur weil wenn ich das jetzt in Meter mir vorstelle, dann ist das soch ein bischen übertrieben, oder?
http://dl.getdropbox.com/u/642927/Browser3D_new/WebContent/index.html Ich habs daweil mit IE7, FF und Google Chrome ausprobiert. Aber nur Google Chrome hats bei mir mit der Framerate
halbwegs geschafft. Bin mir sicher den verwenden nicht viele bis gar keiner von euch... sorry, der hat eben die beste
JS-Engine bis jetzt... die von FF 3.2 wird aber angeblich noch schneller.
Bewegung is ganz normal... w, a, s, d und Maus zum umsehen
Hast du da jetzt nen kompletten Renderer in JavaScript geschrieben? JavaScript ist für sowas einfach viel zu lahm. Man kann höchstens irgendwas mit PointSprites machen:
http://www-users.rwth-aachen.de/martin.weusten/sprite/ Das Licht ist vor berechnet, die Bilder werden einfach nur in der richtigen Größe mit der richtigen Reihenfolge an der die richtige Stelle gesetzt. Das ganze ist in Java geschrieben und dann mit GoogleWebToolkit in JavaScript übersetzt.
Hast du da jetzt nen kompletten Renderer in JavaScript geschrieben? JavaScript ist für sowas einfach viel zu lahm.
Jop... absurd ich weiß^^
Ich wollte eben einerseits einmal das ganze Wissen was ich im letzten Jahr so erlangt hab einmal runter programmieren.
Aber andererseits wollt ich auch JavaScript einmal richtig verwenden, nicht so wie ichs in der Schule gelert hab (->"JavaScript ist nicht Objektorientiert")
Und weil ichs den entsprechenden Lehrer dann so richtig zeigen wollte, wählte ich Java Script. Auch wenn es in Java 100x
besser aussehen, schneller und leichter zum programmieren sein würde.
Das es langsam sein wird wusste ich... aber ich hab noch ein paar schwächen im Programm. Wenn ich die ausmerze würd
das ganze vil. schon wieder um 5 fps mehr haben.
Da wird in einigen Demos eine 3D Engine demonstriert, komplett in JavaScript geschrieben. Es geht dort natürlich nicht um performance per se, sondern eher um die Demonstration der Leistungsstärke von JavaScript sowie der Chrome (bäh) Engine.
Ich bin jetzt auf das Canvas von HTML 5 umgestiegen. Das is schon viel schneller.
Ich hab aber noch eine Frage zur Projektion:
Man kann ja die ganze Projektions-Matrix im weit übertragenen Sinn als Kamera sehen.
Wo müsste ich jetzt also die Rotation bzw. Translation dieser Kamera hinstellen?
Ich hab mir gedacht ich verschieb zuerst dann drehe ich und ganz zum Schluss kommt dann das Abbilden auf eine Ebene.
Also cTrans * cRot * cProje = camera
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.