Naja siehe Topic.
Mich würde mal der Grund dafür interessieren. Ich weis, dass man die Kamera in der ModellView-Matrix setzen soll, aber welche genaueren Gründe hat das?
(Bitte nicht aufs Tut verweisen, da war ich schon).

In DirectX gibts dafür extra ne View-Matrix. Also hat man dort die logische Einteilung in eine Matrix, wo man die Projektionsart festlegt, eine Matrix für Kameraposition und eine Matrix um die Vertexe zu tranformieren. Soweit so logisch. Einzige Nachteil zur OpenGL-Variante der mir da jetzt erstmal einfällt, wäre eine Matrixmultiplikation mehr.

Wenn ich meinen gluLookAt-Befehl von der ModellView- zur Projektionsmatrix verschiebe, sieht die Position genauso aus,also kein Unterschied, zumindest jetzt bei meinem recht einfachen OpenGL-Programm. Allerdings stimmen dann die Lichtberechnungen nicht mehr.
Also das hat doch sicher noch weitere Gründe, dass man seine "Kamera" in der ModellView setzt. Weil komisch mutet es in soweit an, dass man ja seine Modelle verschiebt und nicht wirklich ne Kamera setzt.

Wie gesagt, interessiert mich nur mal interessehalber. In DirectX wirkt das halt logisch, eine Matrix für Modelltransformationen, wo man die Objekte wirklich ändert und eine wo man die Ansicht setzt, aber die Objekte sich nicht verändern. Und bei OpenGL halt die Matrix für die Modelle, wo man auch gleich die Kamera reinsetzt ... .

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Also ganz unter uns: Im Prinzip ist es völlig dir überlassen, wo du deine Krams unterbringst Aber ein gemeinsamer Standard hat nunmal den Vorteil, wenn Dir jemand in einem Tutorial erklärt, wie man Frustum Culling amcht und sich dabei darauf verlässt, daß die Perspektiv-Matrix so und so aussieht, du da aber sachen drin hast, die ich für 0 halte und deswegen immer ignoriere und nicht mit einberechne, dann wird das Tutorial nach hinten losgehen... Irgendjemand hat halt beschlossen: so machen wir das. Und alle haben sich fran gehalten und wenn du dann code anschaust, kannst du immer ein paar annahmen amchen, wo was zu finden ist. So ist es genauso mit der Drehrichtung von Dreiecken - daß die Vorderseite durch die Reihenfolge der Punkte gegen den Uhrzeigersinn definiert ist und nicht im Uhrzeigersinn hat den vorteil, daß wenn ich code ansehe ich den fehler evtl. schon daran erkenne - wo die Drehrichtung umgekehrt ist, ist das meistens sehr deutlich im Code vermerkt.
Im Prinzip also blos ein Standard. Und ein sehr guter sogar, weil man an der perspektiv - Matrix nur etwas ändern muss, wenn man tatsächlich die perspektive ändert. In vielen Fällen kann man also die Perspektiv - Matrix fast immer so belassen wie sie ist, pusht sie höchstens mal, um in den Orthodmodus zu wechseln... Kamerawechsel kommen dagegen meist häufiger vor - bei bewegten Szenen fast in jedem Frame - die perspektivmatrix kann dabei bleiben wie sie ist - z.B. bis zum ändern der Fenstergröße, oder bis 2D zeichnen angesagt ist...

Die Perspektivmatrix bestimmt wie Projeziert wird, nicht wo sich die Kamera befindet. Man kann sachen wie z.B. ein Fischauge in der Perspektivmatrix realisieren.

Außerdem ist es bei lokal Viewer Vorraussetzung, dass die Kamera in der Modelviewmatrix gesetzt wurde.

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

Ich packe immer Kamera und Perspektive in Projektionsmatrix und die lokale Matrix für das Objekt dann in die Modelview Matrix, denn die ändert sich ja sehr häufig. Aber bei Shadern ist das ja sowieso egal wo man die Werte speichert.

Das steht im Tut dazu



Letztendlich definiert das doch die Kamera: wie wird auf dem Bildschirm mein Weltkoordiantenbereich im OpenGL angezeigt. Also da finde ich das logischer, die Kamera der Projektion zuzuordnen.


Ist für mich ja ergo die Aufgabe der Kamera: den Blick auf die Szene ändern, und nicht die Welt verschieben, wie man es ja in der ModellView macht.


Naja aber egal. Wenn ich das gluLookAt in die perspektifische Matrix schiebe, verschwinden bei meiner Darstellung die Glanzstellen(Licht erzeugt aus Hardwarelicht, Parallelstrahler mit fester Position im WC-Bereich). Kann das jemand erklären?


siehe unten ich hab mal Screenshots gemacht. Das Verwaschene ist durch das Speichern im JPEG-Format mit Paint entstanden, also nicht wundern.

edit: das ganze ist ein Polygonmesh aus Dreiecken und nicht eine Fläche

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Nun ich denke das liegt daran, dass du den LocalViewer nicht aktiviert hast.

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

Ich habe am Local Viewer nichts gemacht, und von Start weg ist er ja auf "Außenbeobachter" eingestellt, wie es ja auch sinnvollerweise sein soll. Ich möchte die Lichtberechnung ja vom Betrachterpunkt aus und nicht von der negativen z-Achse.

Oder inwieweit ist das anders, wenn man die Kamera in der perspekt. Matrix setzt?

edit: ok war doch was falsch gesetzt, ich habe den Local Viewer jetz ausgeschalten: jetzt ist ein Spiegeleffekt da, allerdings an verschiedenen Stellen, also abhängig je nachdem wo ich die Kamera setze.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

@Lars: du arbeitest ja immer so, mit der Kamera in der P-Matrix.

Wie machst du das mit dem Licht? Habe jetzt noch ein bissel rumgespielt. Bei Local Viewer an war gar kein Glanzeffekt und das Licht auch nicht richtig. Mit Local-Viewer aus war das Licht zwar leicht besser, aber nicht wirklich gut. Würd mich mal interessieren wie du das halt machst Muss ja irgendwie auch so gehen

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Du könntest theoretisch auch Modelview und Projektions-Matrix in eine Matrix zusammen fassen. Das Problem was du dabei hast ist, dass diverse OpenGL-Funktionalität dann nicht mehr hin haut, bzw. nicht mehr so hin haut wie das gedacht war.

Für diverse Dinge ist es notwendig einen Standard-Raum zu definieren, also sowas wie "Ich (Kamera) befinde mich im 0-Punkt und schaue in eine vorgegebene Richtung" zu definieren. Diese Dinge sind namentlich:
- diverse TexGen-Funktionalität
- einige Lighting-Geschichten
- benutzerdefinierte Clipping Planes
Eventuell kommen durch diverse Extensions noch einige Dinge hinzu, oder ich hab auch noch was übersehen.

Also das es die Trennung zwischen Projektionsmatrix und Modelview-Matrix gibt ist eine Notwendigkeit. Eine Trennung zwischen Kamera und Modelview ist keine Notwendigkeit, da Kamerabewegungen (welcher Art auch immer) durch eine entsprechende umgekehrte Objekt-Bewegung durchgeführt werden können.

Es hält dich aber keiner davon ab eine eigene OGL-Abstraktion zu schreiben, wo du dann eine Kamera-Matrix auch drinnen hast. Bei größeren Projekten hast du üblicherweise ohnehin deine Kamera-Klasse wo das in der ein oder anderen Form auch so realisiert wird. Da OGL auf möglichst vielen Systemen laufen soll benötigt man einen möglichst einfachen, kleinsten gemeinsamen Nenner der Anforderungen, wozu eine eigene Kamera-Matrix sicher nicht gehört. D3D ist das mehr egal, wenn jemand aus irgend einem Grund keine Kamera-Matrix implementiert, dann wird halt einfach kein D3D unterstützt.

Nebel is noch so ne Sache, die nicht Funktioniert, wenn man die Kameraposition in die Projektionsmatrix packt.

Bei Shadern emfinde ich es allerdings als angenehmer, die Kameraposition nicht in der Modelviewmatrix zu haben, weil die Lichtquellen meist nicht in Eye-space sondern in World-space sind. Aber in dem Fall hat man ja sowieso noch zich andere Matrizen die man verwenden kann (GL_MATRIX0_ARB, ...).

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread