Hi,

uns wurde zur Prüfungsvorbereitung die folgende Aufgabe gegeben und ich tue mich mit Shadern leider noch sehr schwer. Es wäre sehr nett, wenn mir jemand unter die Arme greifen könnte.

"Die beiden Shader beschreiben die Oberfläche einer Kugel. Erklären Sie die Variablen, die verwendet werden sowie jeweils die Ausgabe der Shader. Wie wird die Kugel wahrscheinlich aussehen?"

Vertex-Shader:


Fragment-Shader:


Ich schreibe mal, was ich verstehe und wo ich Probleme habe:
varying ist eine Variable, die der Kommunikationsrichtung Vertex-Shader -> Fragment-Shader dient, wobei für letzteren read-only gilt.
vec3 bzw. vec4 ist ein Vektor mit 3 bzw. 4 float-Werten.

Jetzt beginnen auch schon die Probleme:
gl_Position wurde nirgendwo deklariert, warum kann man dieser Variablen einfach einen Wert zuweisen und was bedeutet die Zeile hinter "gl_Position = "?
pos und vNormal wurden bereits deklariert und sie erhalten jetzt einen Wert. Was wird hier aber gemacht?

Also ich habe mir auch schon das Tutorial http://zach.in.tu-clausthal.de/teaching ... _tutorial/ durchgelesen, aber die Probleme bleiben.

Thanks für die Hilfe!!!

Grüße,
gargado

Erstmal vorweg: Der Shader, so wie er da steht, würde nicht funktionieren. Da fehlen sämtliche Uniform Deklarationen. Ich vermute ihr benutzt da irgendein Framework was dies automatisch erledigt.


gl_Position ist eine Variable die fest eingebaut ist. Ich quote mal das Wiki:

Kurz: Nach der Division durch W enthält gl_Position.xyz die Bildschirmposition des Vertex in NDC (Normalized device coordinates = Würfel von -1 bis 1).


Die Vertexposition wird zunächst ins Kamerakoordinatensystem transformiert und dann wird die Kameraprojektion angewendet. Die dafür nötige Division durch W passiert später.


Hier werden ja augenscheinlich Dreiecke gerendert (vermutlich ein billschirmfüllendes Quad), daher solltest du im Kopf behalten das der Vertexshader jeweils dreimal ausgeführt wird (für jeden Vertex des Dreiecks einmal). D.h. du bekommst je drei Werte für gl_Position, vNormal und pos. Der Rasterizer interpoliert diese Werte (mit Hilfe von gl_Position) und ruft für jedes Fragment (=Pixel auf dem Bildschirm) den Fragmentshader mit den entsprechenden Werten auf.

pos im Vertexshader ist die Vertexposition im Koordinatensystem der Kamera. D.h. der Punkt 0,0,0 ist die Position der Kamera, die negative Z-Achse (per Konvention) entspricht der Blickrichtung. Im Fragmentshader wird durch die interpolation daraus die Position des jeweiligen Fragments im selben Koordinatensystem.

vNormal ist die Normale des Vertex bzw. im Fragmentshader die Normale des Fragments.

to_camera ist ein Vektor vom Fragment zur Kamera. (Zur Erinnerung: Kamera steht an 0,0,0)

_________________
Yeah!

Danke erstmal für die schnelle Antwort.

Für die Übungen wurde uns eine Datei namens Three.js gegeben sowie eine HTML-Datei in der wir den Code für die Vertex-/Fragment-Shader einfügen können. Die hier gepostete Aufgabe entspricht aber einer Klausuraufgabe, für die uns nur Papier und Stift zur Verfügung stehen würde.

Den Vertex-Shader habe ich jetzt verstanden, Probleme habe ich aber noch mit dem Fragment-Shader:

1.) Mir ist klar, dass die Kamera im Ursprung ist und über die negative z-Achse in die Welt blickt. Aber warum -pos?
2.) Mir ist auch klar, dass die Formel für die Berechnung der Lichtintensität Skalarprodukt(Richtung, Normale) / (Betrag(Richtung)*Betrag(Normale)) ist, wobei der Nenner aufgrund der vorherigen Normalisierung wegfällt. Wozu aber die Funktion max(..., 0.0)?
3.) Das fertige Bild sieht dann so aus:



Für die gegebene Aufgabe muss man denke ich die Variablen derart beschreiben, wie du es gemacht hast. Was ist aber mit "Ausgabe der Shader" gemeint und woran kann man am Quellcode erkennen, dass die Kugel so aussehen wird wie auf dem geposteten Bild?

Vielen Dank für die Hilfe!

Zu 1):
pos ist die Position des Fragments. 0,0,0 die Kamera. Daher ist (0,0,0) - pos der Vektor vom Fragment zur Kamera.

Zu 2):
Nun es gibt ja Fälle bei denen du ein negatives Ergebnis beim Skalarprodukt bekommst. Etwa wenn die Normale von der Kamera weg zeigt. Eine negative Intensity macht eher weniger Sinn, darum setzt man die dann einfach Null.


Naja, man kann sich anhand der Oberfläche der Kugel und der jeweiligen Position der Fragmente zur Kamera darauf schließen wo die Kugel hell und wo sie dunkel sein wird. Eben da hell wo die Normale zur Kamera zeigt.

_________________
Yeah!

Es ist vermutlich trivial, aber irgendwie "steige" ich da noch nicht ganz dahinter...

Bei einer anderen Aufgabe hatten wir den Code:





Mit dem Ergebnis:



Wie würde man sich hier eine Antwort auf die Frage "Wie wird die Kugel vermutlich aussehen?" erschließen?

Vielen Dank!

Das ist eigentlich ganz einfach (und übrigens falsch ):

Die Theorie ist folgende, ein Punkt (hier v) erhält weniger Photonen von einer Lichtquelle desto weiter er von ihr entfernt liegt. Stell dir nun dein
Polygon als eine Ansammlung von Punkten auf der gleichen Ebene (E) und deine Lichtquelle als Punkt vor. Aus den gängigen Quellen wissen wir das der
kürzeste Weg zwischen Beiden eine Gerade (g) beschreibt die Senkrecht zur Ebene steht. Der Richtungsvektor dieser Geraden ist die Normale.
Nun bilden wir ein Dreieck aus dem Punkt (v) unserer Lichtquelle und dem Schnittpunkt von (E und v) um den Weg (d) unseres Photons zu sehen. Dabei
stellt man fest das der Weg länger wird wenn auch der Winkel zwischen den beiden geraden größer wird. Glücklicherweise kennen wir vom Dreieck
ein ähnliches Verhalten. Und zwar den Cosinus und wir wissen das der Cosinus Richtung A * Richtung B entspricht. Und eine Richtung ergibt sich wiederum
aus Ende - Start.

Allerdings verändert sich unser Punkt durch die ModelView Matrix. Daher muss auch die Normale geändert werden um noch Senkrecht zu unserer Ebene (e) zu
stehen. Da die Normal ein Vektor der länge 3 ist der nicht skaliert wird, brauchen wir nur den ersten 3*3 Block unserer ModelView Matrix zu berücksichtigen.
Da stellen wir allerdings fest das unsere Normale nicht immer senkrecht steht. Allerdings sieht man auch das dieser Effekt nicht bei den Tangenten unserer Ebene
auftritt . Da wir wissen das die Normale Senkrecht zur Tangente steht und der Cosinus in diesen Fall 0 ist, können wir die folgendes Gleichungsystem aufstellen:

(n * matX) * (t * matMV[0..3][0..3]) = 0
t*n = 0
=> (n * matX) * (t * matMV[0..3][0..3]) = t*n

Wenn man sich eine Matrix als Menge von Vektoren vorstellt dann müssen alle Vektoren a) die gleiche Länge haben und b) orthogonal zueinander sein, wie zum
Beispiel {(1,0,0),(0,1,0),(0,0,1)}. Da wir aber mit Variablen arbeiten solls lieber so aussehen {(a1,b1,c1),(a2,b2,c2),(a3,b3,c3)}, unsere Bedingungen eingesetzt
ergeben dann dein Ergebniss:


M ^ -1 => 1 / (a x b) * c * {(b2 * c3 - c2 * b3, c1*b3 - b1*c3, b1*c2 - c1*b2), (c2 * a3 - a2 * c3, a1*c3 - c1 * a3, c1*a2 - a1 * c2), (a2*b3 - b2*a3, b1 * a3 - a1 * b3, a1*b2 - b1*a2)}
M ^ T => {(a1,a2,a3),(b1,b2,b3),(c1,c2,c3)}
// also: matX ^ T * matMV[0..3][0..3] = X ^ -1

normal => (matMV[0..3][0..3]^ -1) ^ T * n ;
intensity => normalize(normal) * normalize((10.0,10.0,-80.0,1.0 - (p * matMV)[0..3]))

_________________
Meine Homepage

Wenn ich das richtig verstehe (und ich bin mir dessen ziemlich sicher) ist das blank inkorrekt (eventuell wolltest du darauf aber auch hinweisen, dann habe ich aber nicht verstanden warum…).

Der Grund für die Abschwächung bei unpassender Normale ist nicht der verlängerte Weg, sondern die Tatsache, dass dadurch, dass die Fläche vom Licht wegzeigt, also weniger Photonen erhalten kann:



In der Skizze siehst du zwei Flächen die von parallelem Licht beschienen werden. Aus sicht des parallelen Lichtes nimmt die obere, schräge Fläche ungefähr die gleiche Fläche ein wie die untere, gerade Fläche. Das heißt, dass ca. die gleiche Anzahl an Photonen auf die Fläche trifft. Der Unterschied ist bloß, dass sich die bei der oberen Fläche auf eine viel größere Fläche verteilen (eben eine cos(α) Abhängigkeit), damit ist die Fläche insgesamt weniger stark ausgeleuchtet.

grüße

_________________
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