Kann es sein das "vEye" in die falsche Richtung zeigt und deshalb "posWorld" auch falsch ist?

Außerdem kannst du dir die Zeile vor "discard" sparen, da der Pixel sowieso verworfen wird. Wobei das wahrscheinlich automatisch wegoptimiert wird.

Dann noch ein Tipp: Falls du wirklich so viele Lichter hast, kann es etwas Geschwindigkeit bringen, wenn du die Multiplikation mit der colorMap in einen eigenen RenderPass auslagerst. Also erst die Lichtfarben aufsummieren und das Ergebnis dann mit der Farbe multiplizieren. Dadurch spart man sich für jedes Licht einen Textur-Lookup.

also ich rendere das Quad jetzt ohne die Projetions und ModelviewMat neu zu laden. Doch funktionieren tut es dennoch nicht.
Ich bin jetzt mal step-by-step durchgegangen..

hier der Tiefenwert:



so sieht vVertex (in rgb) bis hier her aus:





und so nach der mutliplication mit der Projectionsmatrix



und hier nach dem teilen durch w..





Jedoch ändern die Farben sich nciht entsprechend der Camerabewegung, sonden sie bleiben fix..

Irgendwo ist hier der Wurm drin...

...also ich habe jetzt den vVertex nach der Multipl. mit der inversen Projectionsmatrix nochmal mit der Inverse Modelviewmatrix multipliziert. Nun sehe ich für jeden Vertex eine Farbe. Doch so ganz kann das nicht hinhauen? Guckt selbst:

also ich komme langsam voran. Die projektion stimmt nun. ich habe den vVertex nochmal vor dem teilen durch w mit der InvModelMat multipliziert. Nun funktioniert aber die Lichtberechnung nicht wie sie soll. Undzwar geht es um den lambertTerm.

Wenn ich mir die normalen anzeige und die Kamera drehe, ändern diese sich auch bei jeder Rotation.. Das dürfte doch so eigentlich nicht sein oder?

Soweit ich weiß ist da doch die Normale nach Multiplikation mit der NormalMatrix interessant, also nach der Rotation. Von da her: die muss sich bei Rotation ändern.

Oder meinst du was anderes?

Mal noch eine Frage: Den Wert für die Tiefe schreibst du manuell per Shader oder? Damit der auch linear ist, so wie du ihn verwendest. Weil er das ja normalerweise nicht ist.

Dann zu dem Licht: Stimmen die Normalen? Anbieten würde es sich wenn die alle im "Eye-Space" sind. Dann transformiert man die Lichtposition bevor man sie an den Shader übergibt mit der ModelViewMatrix. Und der lambertTerm wird dann so berechnet:

Wie kann ich das prüfen? Wenn ich einfach vNormal als RGB ausgebe müsste doch für jedes Fragment die Farbe fix sein.. z.b. der kopf eines Modells ist dann z.b. pink, egal wie die Kamera drauf guckt.. Bei mir ändern sich die Normalen je nach Kamera.

Die Tiefe rendere ich ohne Shader, einfach via GL_DEPTH_COMPONENT & GL_FLOAT in eine Textur. Funktioniert aber ohne Probleme.

Also wenn sich die Normalen ändern, sind sie im Eye-Space. Das ist auch das normale verhalten was entsteht wenn man im Vertex-Shader "gl_NormalMatrix * gl_Normal" rechnet.
Also mal zur Erklärung wie ich die Bezeichnungen handhabe: Im Eye-Space sind die Positionen und Richtungen relativ zur Kamera angegeben. Eine Fläche die zur Kamera zeigt hat die Normale (0,0,1). Wenn man die Kamera dreht oder bewegt, zeigt die Fläche nicht mehr zur Kamera und die Normale ändert sich.
Im World-Space würden sich die Normalen nicht ändern, es sei denn man dreht die Objekte.

Normalerweise, ist es besser mit den Normalen im Eye-Space zu rechnen, weil die Matrix der Kamera mit den Matrizen der Objekte multipliziert wird. Um die Normalen im World-Space zu erhalten müsste man entweder die Transformation durch die Kamera-Matrix rückgängig machen (im Vertex-Shader) oder die Objekt-Matrix übergeben. Das kostet natürlich Zeit. Außerdem muss man (wie du das auch machst) dann in dem Beleuchtungsshader auch die Position des Pixels im World-Space berechnen, das eine zusätzliche Multiplikation mit einer Matrix bedeutet.

Zu der Depth-Texture: Teste mal ob die Entfernungen von den errechneten Positionen zur Kamera auch wirklich stimmen. Bin mir jetzt nicht so ganz sicher was ein GL_FLOAT für die Tiefenwerte für eine Änderung bewirkt. Normalerweise ist die Tiefe 0 nämlich auf der NearClippingPlane, die auch einen Abstand>0 von der Kamera hat.
So könnte man das zum Beispiel testen:

Dann müssten die farbigen Streifen die dadurch entstehen alle gleich breit sein.

da sehe ich nur blau...

Dann sind sie alle > -1.0 ==> versuchs mal mit anderen Werten (was weiß ich, zB -1.0, -0.6666, -0.3333), sollte es dann immer noch alles blau sein, kannst du ggf auch noch positive Werte versuchen.

Naja, das ist wahrscheinlich schon so wie ich es vermutet hatte. Die Tiefenwerte gehen von 0 bis 1. Die reale Entfernung geht aber von der NearClipping bis zur FarClipping-Plane.
Ich hab hier mal einen Ausschitt aus meinem Shader:

Fragment-Shader:

Vertex-Shader:

Die "matrix" aus dem Vertex-Shader wird im Programm wie folgt berechnet:

Da die Texturen, die die Normalen, die Tiefe und die Farben enthalten mit der normalen Projektion gefüllt wurden, das Fullscreen-Quad aber dann mit einer anderen Projektionsmatrix gezeichnet wird, muss man die Vertex-Positionen transformieren.

Man kann natürlich auch direkt die Matrizen setzen, wenn man weiß wie das geht (kann man nachlesen). Meine Variante macht es sich da ein bischen einfach. Funktionieren tut es aber.
Für die Matrix-Operationen musst du dann halt deine eigenen Funktionen benutzen.

vielleicht bin ich zu doof, aber ich verstehe einfach nich was du in deinem Fragmentshader machst? Wo teilst du da durch w? Hast du deine Tiefenwerte mit nem Shader gerendert? Wenn ja wie sah der aus?

Bei mir ist die w-Koordinate immer 1. Wenn man nur Vertices mit 3 Komponenten verwendet wird die automatisch so gesetzt (siehe glVertex).
Bei den Tiefenwerten benutze ich auch nur, die die GL_DEPTH_COMPONENT liefert. Wie gesagt sind die Werte aus dem Tiefenbuffer aber nicht linear zur realen Tiefe. Deshalb müssen die umgerechnet werden. siehe Link. Das müsste man auch selbst aus dem Artikel zu gluPerspective schlussfolgern können.

Meep, nach der Projektion wird die w-Koordinate aber anders sein. Das ist der Trick. Dann musst du nach w normalisieren (also alle Vektorkomponenten durch w teilen). So kommt überhaupt erst die perspektivische Verzerrung zustande. Allein mit Matrizen geht das mathematisch nicht.

greetings

_________________
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

Bei mir ist w trotzdem 1, weil in der Matrix die 4te Zeile (0,0,0,1) ist. Das liegt aber womöglich daran, dass ich für die richtige Szene und das Fullscreen-Quad die gleichen Werte fur Near und FarClipping-Plane verwende.