GLSL Licht und Schatten - Versionsgeschichte

Openglerf: /* Paraboloide Maps */ WäHrend

2012-03-18T15:52:40Z

‎Paraboloide Maps: WäHrend

Openglerf: /* Grundlegendes zu den Koordinatensystemen in den Shadern */ WäHrend

2012-03-18T15:52:24Z

‎Grundlegendes zu den Koordinatensystemen in den Shadern: WäHrend

Openglerf: /* Statische Anteile in den Schattenmaps */

2012-03-18T14:27:54Z

‎Statische Anteile in den Schattenmaps

Openglerf: /* Dual Paraboloide Maps */ Rechtschreibung :(

2012-03-18T14:27:38Z

‎Dual Paraboloide Maps: Rechtschreibung :(

Openglerf: /* Paraboloide Maps */ Rechtschreibung :(

2012-03-18T14:27:07Z

‎Paraboloide Maps: Rechtschreibung :(

Openglerf: /* Beschleunigtes Rendern */ Rechtschreibung :(

2012-03-18T14:26:40Z

‎Beschleunigtes Rendern: Rechtschreibung :(

Openglerf: /* Farbiges Glas */ Rechtschreibung :(

2012-03-18T14:25:46Z

‎Farbiges Glas: Rechtschreibung :(

Openglerf: /* Beschleunigtes Rendern */ Rechtschreibung :(

2012-03-18T14:23:31Z

‎Beschleunigtes Rendern: Rechtschreibung :(

Openglerf: /* Optimierungen und Verbesserungen */ Rechtschreibung :(

2012-03-18T14:21:07Z

‎Optimierungen und Verbesserungen: Rechtschreibung :(

Openglerf: /* Dual Paraboloide Maps */ Rechtschreibung :(

2012-03-18T14:07:51Z

‎Dual Paraboloide Maps: Rechtschreibung :(

@@ Zeile 202: / Zeile 202: @@
 * Tangente
-Wärend die Funktion der ersten beiden Vektoren klar ist, wird die Tangente dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
+Während die Funktion der ersten beiden Vektoren klar ist, wird die Tangente dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
 Beschreiben lässt sich diese Funktion am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

@@ Zeile 76: / Zeile 76: @@
 ===Grundlegendes zu den Koordinatensystemen in den Shadern===
-Im Vertexshader müssen alle Komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkoordinaten den Bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich von -1.0 bis 1.0 arbeiten.
+Im Vertexshader müssen alle Komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkoordinaten den Bereich von 0.0 bis 1.0 nutzen, während die Rendertargets im Bereich von -1.0 bis 1.0 arbeiten.
 In den Shadern werden daher öfters Multiplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

@@ Zeile 510: / Zeile 510: @@
 ===Statische Anteile in den Schattenmaps===
-Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
+Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichtquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
 Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinnvoll die Maps hier erst zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

@@ Zeile 216: / Zeile 216: @@
 Die Projektion der dualparaboloiden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflexionsbild der umgebenden Welt in einem Rotationsparaboloiden.
-Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compilieren auf über 170 Instruktionen. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktionen passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen werder sollen: Die Karte hat keine Chance mehr diese umzusortieren.
+Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichtquellen kommt nach dem Compilieren auf über 170 Instruktionen. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktionen passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen werder sollen: Die Karte hat keine Chance mehr diese umzusortieren.
 Wer dualparboloide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.
@@ Zeile 417: / Zeile 417: @@
-Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
+Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichtquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
 Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
 Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

@@ Zeile 192: / Zeile 192: @@
 ==Paraboloide Maps==
-Einfache paraboloide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt werden soll. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im Gegensatz zumr Parallelen Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.
+Einfache paraboloide Maps können für alle Punktlichtquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt werden soll. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im Gegensatz zumr Parallelen Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.
 Bei kleinen Öffnungswinkeln hat die paraboloide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vorteil ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

@@ Zeile 68: / Zeile 68: @@
 Alternativ sollte alles was zwischen [[glBegin]] und [[glEnd]] in [[Displaylisten]] gespeichter werden. Das Speichern von Texturwechseln usw. ist nicht sinnvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.
-Bei mehrfachen Lichquellen kann es wiederrum Sinn machen den ersten Rendervorgang inklusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.
+Bei mehrfachen Lichtquellen kann es wiederrum Sinn machen den ersten Rendervorgang inklusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.
 ===Algemeines zu GLSL===

@@ Zeile 444: / Zeile 444: @@
 Der Algorithmus ist nicht schwer:
-* Alle undurchichtigen Sceneteile in die Tiefenmaps gerendert.
+* Alle undurchsichtigen Sceneteile in die Tiefenmaps gerendern.
 * Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
 * Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
@@ Zeile 452: / Zeile 452: @@
 * Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.
-Bei diesem Algorithmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:
+Bei diesem Algorithmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algorithmus:
 * Alle transparenten Polygone in den Zbuffer rendern. Dabei für alle Polygone, deren  doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.

@@ Zeile 66: / Zeile 66: @@
 Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits [[Tutorial Vertexbufferobject|ein Tutorial]] gibt werde ich hier nichts mehr darüber schrieben.
-Alternativ sollte alles was zwischen [[glBegin]] und [[glEnd]] in [[Displaylisten]] gespeichter werden. Das Speichern von Texturwechseln usw. ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.
+Alternativ sollte alles was zwischen [[glBegin]] und [[glEnd]] in [[Displaylisten]] gespeichter werden. Das Speichern von Texturwechseln usw. ist nicht sinnvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.
-Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.
+Bei mehrfachen Lichquellen kann es wiederrum Sinn machen den ersten Rendervorgang inklusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.
 ===Algemeines zu GLSL===

@@ Zeile 422: / Zeile 422: @@
 ==Optimierungen und Verbesserungen==
-Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.
+Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine universelle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.
 ===Schatten durch Alphatest===
-Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader  weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:
+Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader  weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Schatten in Abhängigkeit einer Alphatextur zu rendern:
 shadow.frag
@@ Zeile 436: / Zeile 436: @@
          if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
 }</source>
-Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
+Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Parallax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
-Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.
+Es ist auch möglich den Shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.
 ===Farbiges Glas===
-Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
+Schatten hat jetzt ja schon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
-Der Algoritmus ist nicht schwer:
+Der Algorithmus ist nicht schwer:
-* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
+* Alle undurchichtigen Sceneteile in die Tiefenmaps gerendert.
 * Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
 * Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
 * Rendern aller transparenten Objekten
 * Auf finales Rendern umschalten
-* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
+* Alle undurchsichtigen Objekte mit Hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
 * Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.
-Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:
+Bei diesem Algorithmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:
-* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren  doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
+* Alle transparenten Polygone in den Zbuffer rendern. Dabei für alle Polygone, deren  doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
 * Zbuffer und Colorbuffer Löschen.
 * Helligkeitsmap in den Colorbuffer kopieren.
-* Alle nicht transparanten Objekte in den Zbuffer Rendern.
+* Alle nicht transparenten Objekte in den Zbuffer Rendern.
-* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
+* Alle transparenten Polygone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
 * Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.
-Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.
+Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Polygone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurchgang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichtquellen (fast) überein, so wird das Polygon mit dem Licht aus der Colormap beleuchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die Entfernung zu Lichtquellen, enthält die Colormap die gefilterte Farbe des Lichtes hinter dem Polygon. Für die Beleuchtung des Polygon muss also das Licht der Lichtquelle benutzt werden. Sinnvoll ist es die Helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.
 Ansonsten noch ein paar Vorschläge:
-* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
+* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefärbten Glaskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
-* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
+* Eventuell macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
-* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
+* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich aussehen. Gute Filter wären Komplementabfärben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
-* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...
+* Um von den Farbfehlern abzulenken, farbige Objekte in einer rot verschobenen Farbe fluoreszieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...
 ===Schattenmap durch eine Heightmap modifizieren===
-Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.
+Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit Hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.
 ===Zweite parabolische Map vermeiden===
-Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.
+Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodennähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.
@@ Zeile 481: / Zeile 481: @@
 ===Texturelookups vermeiden===
-Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.
+Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können deutlich Beschleunigt werden.
 Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
@@ Zeile 500: / Zeile 500: @@
 light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</source>
 Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
-Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.
+Wichtig ist auch, dass man beachtet, dass die dualparaboloiden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.
 ===Ein zusätzlicher Renderpass===
-Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.
+Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboloiden Maps einen Übergang haben.
 ===Dynamische Lichter in statische Lightmaps Rendern===
@@ Zeile 511: / Zeile 511: @@
 ===Statische Anteile in den Schattenmaps===
 Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
-Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.
+Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinnvoll die Maps hier erst zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

@@ Zeile 207: / Zeile 207: @@
 Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboloiden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für Shadowmap verwendet werden kann die nicht jeden Frame neu berechnet werden muss.
-==Dual Parabolide Maps==
+==Dual Paraboloide Maps==
-Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.
+Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidende Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.
-Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.
+Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboloiden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.
-Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer  Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.
+Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflexion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer  Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.
-Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.
+Die Projektion der dualparaboloiden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflexionsbild der umgebenden Welt in einem Rotationsparaboloiden.
-Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es  wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.
+Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compilieren auf über 170 Instruktionen. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktionen passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen werder sollen: Die Karte hat keine Chance mehr diese umzusortieren.
-Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.
+Wer dualparboloide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.
 ===Hauptprogramm===
-So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
+So kann in der Hauptschleife das Rendern der 16 paraboloiden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
-<source lang="cpp">//Shader für Dualparabolische Mpas aktivieren
+<source lang="cpp">//Shader für Dualparabolische Maps aktivieren
 glUseProgramObjectARB(parabol);
@@ Zeile 230: / Zeile 230: @@
 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
-//Die 8 Lichtquellen Rendern
+//Die 8 Lichtquellen rendern
 for (int light;light<8;light++){
          glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
@@ Zeile 255: / Zeile 255: @@
 ungetesteter Pascalcode:
 <source lang="pascal">
-//Shader für Dualparabolische Mpas aktivieren
+//Shader für Dualparabolische Maps aktivieren
 glUseProgramObjectARB(parabol);
@@ Zeile 262: / Zeile 262: @@
 glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
-//Die 8 Lichtquellen Rendern
+//Die 8 Lichtquellen rendern
 for light := 0 to 7 do
 begin
@@ Zeile 323: / Zeile 323: @@
 	}</source>
-Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.
+Es gibt zwei Uniformvariablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vor- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.
-Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
+Statt einer Multplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
-Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.
+Die Division durch -L entspricht weitgehend einer Normalisierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kamera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kamera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.
-Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
+Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Farbbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
-Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.
+Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinnvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.
 ====Shader für den finalen Renderdurchgang====
@@ Zeile 353: / Zeile 353: @@
 uniform int MaxLights;
-//Achtung folgende Zeile ist nicht GLSL konform.
+//Achtung folgende Zeile ist nicht GLSL-Konform.
-//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
+//Workaround: Array als Uniform übergeben oder durch sehr aufwendige Berechnung erstzten
-//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
+//Sollte es auch auf ATI-Karten funktionieren, frage ich mich warum es nicht erlaubt ist...
 const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
 			  vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
@@ Zeile 377: / Zeile 377: @@
 	}</source>
-Möglicher weise für ATI taugliche Variante:
+Möglicherweise für ATI taugliche Variante:
 <source lang="glsl">
 varying vec3 Normal;