hallo leute.

ich lese grad ein opengl-buch und wollte mein verständnis der projection tansformation und der navigation allgemein bestätigen lassen.

hier mal ein grober überblick über die vertex-transf.-pipeline (ich gehe von der perspective proj. aus):

1. projektions-matrix resetten
2. viewing transformation. z.b. wegzoomen, um einen überblick auf die szene zu haben.
3. objekt(e) bauen (z.b. geometrisches zeugs, lichter, etc.) und transformationen durchführen (z.b. translate, rotate, scale). die objekte werden dabei nicht direkt (z.b. glTranslate) modifiziert, es werden die matrizen gespeichert. (objekte bleiben sozusagen alle im ursprung)
4. die projektions-transformation arbeitet all diese matrizen ab und positioniert alle akteure entsprechend den gespeicherten matrizen an die richtige(n) stelle(n) im frustum.
5. (zur vollständigkeit ) viewport-transformation. die projektion wird in den viewport umgerechnet.

und noch eine kurze frage zur navigation. ich habe oben ja die viewing-transformation erwähnt. obwohl ich jetzt problemlos navigieren kann, verwirrt mich doch etwas. hier ein beispiel:



ich bewege das welt-cos von mir weg und etwas nach unten, um einen überblick über die szene zu bekommen. die aktuelle modelview-matrix leg ich im matrixstack ab. sobald ich jetzt was zeichne ( in meinem fall sinds die x,y,z-achsen zur orientierung ), erscheint es im ursprung des welt-cos. es ist zwar so gewollt aber wieso dieses verhalten? sollte es nicht eigentlich genau bei den oben genannten koordinaten erscheinen, da die matrix-transformationen additiv sind? liege ich da richtig, wenn ich annehme, dass die erste transformation von opengl als die viewer-transformation und der rest als model-transformation interpretiert wird?

danke im voraus.

Kannst du mal genauer erklären was du mit dem letzten Block meinst?

Punkt 4 in deiner Liste fällt übrigens weg. Sobald du ein Objekt platzierst, wird es mit der Matrix multipliziert und in Weltkoordinaten um berechnet. Somit hast du auch nur eine Matrix und nicht mehrere Matrizen.
Mit glPushMatrix erzeugst du zwar eine Kopie der aktuellen Matrix, die wird aber nur abgelegt und wird erst wieder hervorgeholt wenn du glPopMatrix aufrufst.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

im text steht das allerdings auch.




ok, was macht/ist dann die projektionsmatrix? bitte erklären. wird nichts anderes gemacht, als das umrechnen des viewing volume? sprich clipping und das umrechnen der objekte, um perspektive zu faken?

siehe punkt navigation, das habe ich dort genauso beschrieben. also habe ich es richtig verstanden?


ok!



jo. der gebrauch von pushen und poppen ist mir geläufig.

Also irgendwie sind wir sprachlich inkompatibel.
Es möge also hier mal jemand einspringen der seine Postings versteht.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Das ist ein gründlicher Typ. Ich glaube, ich habe hier etwas, was ihm hilft (*herumkram*):
http://isgwww.cs.uni-magdeburg.de/~bernhard/cg/vorl6Projektionen.pdf
Das ist ein sehr ausführliches Dokument, ebenfalls von einem sehr gründlichen Typ geschrieben.


Eine Projektionsmatrix projiziert, und zwar je nachdem, um welche Projektion es sich handelt: glOrtho berechnet eine Parallelprojektion, glFrustum eine perspektivische Projektion (Zentralperspektive). Erst danach kommt die Viewporttransformation.

Ich bin ein einfacher Typ: für mich macht eine Projektion nichts anderes, als ein dreidimensionales Ding an die Wand zu patschen. Aber man kann es auf ganz verschiedene Weise "gegen die Wand patschen".



EDIT: ich habe Dir noch etwas unterschlagen. Es gibt dann auch noch DAS hier:
http://www.kowoma.de/gps/geo/Projektionen.htm
Hier sollte man ein wenig runterscrollen. Das ist eine erstklassig informative Website.

danke traude, wertvolle infos! und ja, ich arbeite generell "gründlich". es reicht mir nicht etwas nur anwenden zu können, ich will den prozess im hintergrund ebenfalls verstehen. ich habe mit noch jemandem über diesen thread gesprochen und mir wurde recht gegeben. diese person arbeitet beruflich mit opengl und hat folglich dem entsprechende kenntnisse zum thema.

die projektionsmatrix ( in diesem falle war es die perspective matrix ) projeziert den inhalt des frustums, wobei durch umrechnung (foreshortening) die perspektive realisiert wird. außerdem werden die clipping planes bestimmt, sodass alles außerhalb des frustums nicht gerendert wird.

glOrtho ist ja nichts anderes, als eine parallelprojektion mit tiefentest (sofern aktiviert). toll für 2d-zeugs.

was viewport und co angeht: das war nur vollständigkeitshalber angeschnitten. die kernfrage war die projektionsmatrix.

da das erste problem aus der welt geschafft ist, kommen wir zum thema navigation. und bitte genau lesen, es ist eigentlich alles recht klar und deutlich geschrieben.

ja, scheint so. konntest mir zumindest mit den matrizen helfen.

Aha. Also ich lese genau:


Hier drängt sich mir die Frage auf: Was ist das „welt-cos“ Achso: Das Welt-Koordinatensystem. Aber egal. Mit dieser Transformation verschiebst Du alles, was gezeichnet wird, in die Minus-Z-Richtung (also in den Bildschirm hinein) und in die Minus-Y-Richtung (also hinunter).


Was immer auch im Koordinatenursprung gezeichnet wird, ist bei der perspektivischen Projektion nicht zu sehen, denn Du hast die nahe ClippingEbene, die nicht Null sein darf, siehe http://wiki.delphigl.com/index.php/glFrustum. Zeichnest Du z.B. eine Kugel um den Koordinatenursprung, deren Radius größer ist als das ZNear UND deren Faces nach „innen“ schauen, dann siehst Du natürlich die Innenwand der Kugel, aber davon auch nur das Stück, das innerhalb des Frustums liegt.


Genau das tut es ja doch auch. Wenn Du ein Modell hast, das um den Nullpunkt platziert ist (alle gewöhnlichen Modelle sind so), kannst Du eine Transformation darauf anwenden, oder Du kannst alle Vertices händisch umrechnen, damit die Kugel dort zu sehen ist, wo Du sie mit glTranslate hingeschoben hättest. Rein mathematisch ist das genau derselbe Vorgang, Du machst mit Deiner händischen Manipulation das Gleiche wie OpenGL mit seiner Translation. Daher kommt auch genau das gleiche raus.


Ja. Aber das wird nicht von OpenGL so interpretiert, sondern von uns, denn das ist eine "menschliche" Sehweise.

Irgendwie habe ich aber das Gefühl, dass ich - obwohl ich mich bemüht habe, alle Deine Fragen zu beantworten - vielleicht doch nicht alles klar ist?

Zuerst einmal würde ich dir raten, das Tool aus dem Tutorial_Matrix2 einmal auszuprobieren.

2. Die Koordinaten deines Objekts, also z.B. eines Würfels, sind zueinander immer im lokalen KOS.
Bei jeder Manipulation der Modelviewmatrix, veränderst du diese. Diese Änderung gelten für alle zukünftig gezeichneten Vertices.
Wie hier bereits geschrieben steht, werden die lokalen Koordinaten deines Objekts sofort bei der eingabe, intern mit der aktuellen Modelviewmatrix multipliziert.

Nun zur Frage wieso die Koordinaten wo auftauchen. Phobeus hats diese Frage gestellt: Dreh ich mich um die Welt, oder die Welt sich um mich? Und das ist scheinbar hier dein Problem.
Wenn du direkt nach dem Laden der Identitätsmatrix etwas zeichnen würdest, dann ständest du direkt im Zentrum des geschehens. Mit der Folge nix zu sehen, da alles zu nah an der Near Clipping plane stattfindet.
Wenn du entsprechend "raus gehst" wie du schreibst, dann schiebst du eigentlich die Welt weg. Deshalb ist der neue KOU nicht mehr da wo deine "Kamera" steht.

Und nochwas zur Art wie OpenGL Matrizen rechnet. OpenGL multipliziert immer von Rechts (glaub ich). D.h. die aktuelle MVMatrix steht rechts, während die neue Operation links daneben steht. (Oder wars genau umgekehrt?) Wenn du die Rechnung ausschreiben würdest, sähe es aus, als würde GL von innen nach außen rechnen.
Am besten mal ein simples Beispiel auf einem Blatt nachrechnen.

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

Genau umgekehrt.
M = Modelviewmatrix.
R1 = Rotationsmatrix 1 (Als Beispiel)
R2 = Rotationsmatrix 2
Mnew = M * R1
Mnew = M * R1
->
Mnew = M * R1 * R2
Aber (Und was du auch meinst): Hier wird ERST R2 auf den jeweiligen Vertex angewandt, DANN R1! Genau umgekehrt also, wie sie multipliziert wurden.

Mist. 50:50 Chance. Dachte ich hätte Glück.

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

erstmal vorweg: meine anspielung auf "klar und deutlich geschrieben" war nicht bös gemeint.

yup. mit welt-cos mein ich "wetl-coordinatesystem". und jo. dass es so verschoben wird, wie du beschreibst, ist mir bewusst. das habe ich ja nochmals kurz hingeschrieben. ( den raum nach vorne und herunter verschieben )



ja, das ist mir geläufig. es sei denn, man führt erstmal die viewing-transformation durch und verschiebt den raum entsprechend, um auf den ursprung einen blick zu haben.

zu der kugel ... dieses verhalten habe ich ja oben schon beschrieben. ( stichwort clipping planes )



das ist eine interessante aussage. du schreibst von "objekt platzieren und eine transformation darauf anwenden". so wie ich das verstanden habe, bewegt man nicht die objekte, sondern den raum.

gehen wir zunächst von meiner translation aus, wir haben also einen blick auf den ursprung und die matrix im stack. nehmen wir mal an, wir wollen das objekt im ortsvektor { 10, 10, -10 }. wir führen zuerst gltranslate aus ( bewegen den raum zum eben genannten vektor ) und erstellen erst dann das objekt. laden dann die viewing-matrix aus dem stack und fertig die "szene".

bis hier und nicht weiter ... und danke für deine hilfe, traude.

das matrix-tutorial ist wirklich gut, danke! habe ganz vergessen, was für ein gutes wiki ihr habt. schande über mein haupt. ;P ich werds mir gleich mal ordentlich geben und bei fragen hier wieder reinschreiben.

Auch das ist eine interessante Aussage. Wie glaubst Du, geht denn das - ich meine rein technisch - den Raum bewegen? Ich weiß schon, dass das in allen Büchern so drinsteht. Aber sie sagen gar nicht dazu, wie man das macht. Ich halte mich an die harten Fakten: Ich habe ein Objekt, das prinzipiell aus Vertices besteht. Die Transformation wird selbstverständlich auf die Vertices angewendet. Leeren Raum kann man gar nicht transformieren, wie sollte das gehen?

Damit Du weißt, dass ich nicht das Blaue vom Himmel phantasiere: ich kann genau dasselbe, was OpenGL macht, auf meine Objekte (die mit Bones versehen sind) anwenden und erst nach erfolgter Transformation im HAUPTSPEICHER schicke ich die transformierten Modelle an OpenGL, damit sie gezeichnet werden. Und sie werden genauso gezeichnet, wie ich das will. Ich kann das steuern, indem ich eine logische Überlegung anwende, die so nicht in der OpenGL-Literatur drin steht, aber ich weiß, das es intern so gemacht wird, denn man kann es gar nicht anders machen (!).

Und ich transformiere dabei keinen mystischen Raum, sondern das, was vorhanden ist: eben die Modelle.

das ist wohl wahr ... bevor ich anfing das buch zu lesen, habe ich mir das auch so gedacht. man hat nen haufen vertices, die ein objekt repräsentieren, und auf die wendet man dann die rechnungen an.

mit raum meine ich natürlich das KOS, welches man im frustum bewegt. streng genommen bewegt man ja diesen "raum" (welt). denn die objekte orientieren sich ja am ursprung des KOS und daher wohl dieser gedankengang. das propagieren zumindest die autoren der opengl-bücher.

ps: das mit "interessante aussage" war nicht sarkastisch, sondern ernst gemeint.