GLSL Partikel - Versionsgeschichte

Openglerf: /* Shader */

2012-03-18T15:35:54Z

‎Shader

Openglerf: /* Shader */

2012-03-18T12:49:20Z

‎Shader

Openglerf: /* Grundlagen für die Implementierung */

2012-03-18T12:47:39Z

‎Grundlagen für die Implementierung

Openglerf: /* Grundlagen für die Implementierung */

2012-03-18T12:44:26Z

‎Grundlagen für die Implementierung

Openglerf: /* Grundlagen für die Implementierung */

2012-03-18T12:43:29Z

‎Grundlagen für die Implementierung

Openglerf: /* Shader */ Rechtschreibung :(

2012-03-18T12:41:35Z

‎Shader: Rechtschreibung :(

Openglerf: /* Implementation per Texturlookup im Vertexshader */ Rechtschreibung :(

2012-03-18T12:39:44Z

‎Implementation per Texturlookup im Vertexshader: Rechtschreibung :(

Openglerf: /* Probleme bei der Implementation */ Rechtschreibung :(

2012-03-18T12:34:10Z

‎Probleme bei der Implementation: Rechtschreibung :(

Openglerf: Rechtschreibung :(

2012-03-18T12:30:56Z

Rechtschreibung :(

Openglerf: Rechtschreibung :(

2012-03-18T12:25:07Z

Rechtschreibung :(

@@ Zeile 138: / Zeile 138: @@
 Es werden zwei Vertex und Pixelshader gebraucht.
-Der Partikelphysikvertexshader muss nur die Variablen an den Pixelshader weiter geben. Prinzipell wäre es auch möglich die ModelViewProjectionMatrix zu umgehen, so dass die eventuell vorhandene Perspektive nicht stört. Auch die Texturkoordinaten ließen sich wegrationalisieren. Damit alles leicht verständlich bleibt hier die gewohnte Variante:
+Der Partikelphysikvertexshader muss nur die Variablen an den Pixelshader weiter geben. Prinzipiell wäre es auch möglich die ModelViewProjectionMatrix zu umgehen, so dass die eventuell vorhandene Perspektive nicht stört. Auch die Texturkoordinaten ließen sich wegrationalisieren. Damit alles leicht verständlich bleibt hier die gewohnte Variante:
 <source lang="glsl">
 void main(void){

@@ Zeile 161: / Zeile 161: @@
 </source>
-Im Rendershader muss die eigentliche Position (auch Normalvektoren und Farben) per Texturelookup ausgelesen werden. Um Bandbreite zu sparen sollten diese Variablen Werte möglichst weit zusammengepackt werden. Um Latenzen zu verstecken sollte man die Ergebnisse der Lookups nach Möglichkeit erst benutzen, wenn andere Dinge bereits berechnet wurden.
+Im Rendershader muss die eigentliche Position (auch Normalvektoren und Farben) per Texturelookup ausgelesen werden. Um Bandbreite zu sparen sollten diese Variablen Werte möglichst eng zusammengepackt werden. Um Latenzen zu verstecken sollte man die Ergebnisse der Lookups nach Möglichkeit erst benutzen, wenn andere Dinge bereits berechnet wurden.
 <source lang="glsl">

@@ Zeile 12: / Zeile 12: @@
 Ein Beispiel wäre ein einfaches Partikelsystem: Für drei Positionskomponenten, eine Zeitkomponente, drei Geschwindigkeitskomponenten und eine noch freie Komponente z.B. für Masse, werden 8 Werte benötigt. Bei einer Verwendung von float16 und 2^20 Partikeln, werden ganze 16MB GPU RAM verbraucht. Da es nicht möglich oder sinnvoll ist in eine aktive Textur zu schreiben, wird eine zweite Textur benötigt, die die selbe Größe hat. So verbraucht unser Partikelsystem 32 MB GPU RAM. Da immer zwischen diesen zwei Buffern hin und her gerendert wird, spricht mach auch von einem Ping-Pong-Buffer.
-Damit keine getrennten Buffer für Position und Geschwindigkeit verwendet werden müssen, sind Multiplerendertargets von Vorteil. Diese sind nicht schwerer zu verwenden als normale Framebufferobjekte. Eine Einschränkung ist, dass nur Rendertargets mit gleichen Bitanzahlen kombiniert werden können. So lässt sich ein 1x float32 mit einem 2x float16 und einem RGBA8 Rendertarget kombinieren. Ein RGBA_float16 Target z.B. lässt sich nur mit einem RG_float32 und sich selbst kombinieren.
+Damit keine getrennten Buffer für Position und Geschwindigkeit verwendet werden müssen, sind Multiple Render Targets von Vorteil. Diese sind nicht schwerer zu verwenden als normale Framebufferobjekte. Eine Einschränkung ist, dass nur Render Targets mit gleichen Bitanzahlen kombiniert werden können. So lässt sich ein 1x float32 mit einem 2x float16 und einem RGBA8 Render target kombinieren. Ein RGBA_float16 Target z.B. lässt sich nur mit einem RG_float32 und sich selbst kombinieren.
-Weiterhin ist es sehr sinnvoll einen float16 Frambuffer zu verwenden, da so nachträglich durch die Blende die Helligkeit des Bildes optimal angepasst werden kann (Siehe fehlendes HDR tutorial....)
+Weiterhin ist es sehr sinnvoll einen float16 Frambuffer zu verwenden, da so nachträglich durch die Blende die Helligkeit des Bildes optimal angepasst werden kann (Siehe fehlendes HDR Tutorial....)
-Nun erst einmal ein Program im Pseudocode um einen Überblick über die Initialisierung zu schaffen:
+Nun erst einmal ein Programm Pseudocode um einen Überblick über die Initialisierung zu schaffen:
    Optional (3 Zeilen):
    Eine RGB_Float16 Textur für HDR Rendering mit der OpenGL-Auflösung erzeugen.
-   Ein Rendebufferobjekt für den Z-Buffer erstellen.
+   Ein Renderbufferobjekt für den Z-Buffer erstellen.
-   Beides zu einem Frambufferobjekt hinzufügen.
+   Beides zu einem Framebufferobjekt hinzufügen.
 x2 RGBA_Float16 Texturen mit 1024x1024 erstellen.
-mit initialisierungsdaten füllen
+mit Initialisierungsdaten füllen
    Ein weiteres Framebufferobjekt erzeugen und die zwei übrigen daran binden.
    Laden weiterer Texturen
    Shader laden
-   Haupschleife
+   Hauptschleife
       Aktivieren des Partikelphysikshaders und des Rendertargets
       Rendern der Physikdaten in den zweiten Buffer
       Buffer tauschen.
       Die gerenderten Daten in ein VBO übertragen oder später per Vertextexturefetch nutzen.
-      Nortmales Rendertaget auswählen
+      Normales Rendertaget auswählen
       Rest der Scene Rendern
       Partikel mit Partikelshader als Pointsprites rendern.

@@ Zeile 10: / Zeile 10: @@
 Während es bei konventionellen Partikelsystemen am Sinnvollsten war, die berechneten Daten per VBO oder Vertexarray in die Grafikkarte zu laden. Müssen bei einem GLSL-Partikelsystem, alle Daten in Texturen gespeichert werden. Da die GPU in der Lage ist, mehr als die 10fache Menge an Partikeln zu verarbeiten und außerdem Positionen noch Physikdaten gespeichert werden müssen, sollte von Anfang an der Speicherkonsum auf der Grafikkarte mit eingeplant werden.
 Die Anzahl der Komponenten sollte sich möglicherweise durch vier teilen lassen. Zudem sollte beim Speichern statt float32 möglichst nur float16 genutzt werden.
-Ein Beispiel wäre ein einfaches Partikelsystem: Für drei Positionskomponenten, eine Zeitkomponente, drei Geschwindigkeitskomponenten und eine noch freie Komponente z.B. für Masse, werden 8 Werte benötigt. Bei einer Verwendung von float16 und 2^20 Partikeln, werden ganze 16MB GPU Ram verbraucht. Da es nicht möglich oder sinnvoll ist in eine aktive Textur zu schreiben, wird eine zweite Textur benötigt, die die selbe Größe hat. So verbraucht unser Partikelsystem 32 MB GPU Ram. Da immer zwischen diesen zwei Buffern hin und her gerendert wird, spricht mach auch von einem Ping-Pongbuffer.
+Ein Beispiel wäre ein einfaches Partikelsystem: Für drei Positionskomponenten, eine Zeitkomponente, drei Geschwindigkeitskomponenten und eine noch freie Komponente z.B. für Masse, werden 8 Werte benötigt. Bei einer Verwendung von float16 und 2^20 Partikeln, werden ganze 16MB GPU RAM verbraucht. Da es nicht möglich oder sinnvoll ist in eine aktive Textur zu schreiben, wird eine zweite Textur benötigt, die die selbe Größe hat. So verbraucht unser Partikelsystem 32 MB GPU RAM. Da immer zwischen diesen zwei Buffern hin und her gerendert wird, spricht mach auch von einem Ping-Pong-Buffer.
 Damit keine getrennten Buffer für Position und Geschwindigkeit verwendet werden müssen, sind Multiplerendertargets von Vorteil. Diese sind nicht schwerer zu verwenden als normale Framebufferobjekte. Eine Einschränkung ist, dass nur Rendertargets mit gleichen Bitanzahlen kombiniert werden können. So lässt sich ein 1x float32 mit einem 2x float16 und einem RGBA8 Rendertarget kombinieren. Ein RGBA_float16 Target z.B. lässt sich nur mit einem RG_float32 und sich selbst kombinieren.

@@ Zeile 8: / Zeile 8: @@
 ==Grundlagen für die Implementierung==
-Während es bei konventionellen Partikelsystemen am sinnvollsten war, die berechneten Daten per VBO oder Vertexarray in die Grafikkarte zu laden. Müssen bei einem GLSL-Partikelsystem, alle Daten in Texturen gespeichert werden. Da die GPU in der Lage ist, mehr als die 10fache Menge an Partikeln zu verabeiten und außerdem Positionen noch Physikdaten gespeichtert werden müssen, sollte von Anfang an der Speicherkonsum auf der Grafikkarte mit eingeplant werden.
+Während es bei konventionellen Partikelsystemen am Sinnvollsten war, die berechneten Daten per VBO oder Vertexarray in die Grafikkarte zu laden. Müssen bei einem GLSL-Partikelsystem, alle Daten in Texturen gespeichert werden. Da die GPU in der Lage ist, mehr als die 10fache Menge an Partikeln zu verarbeiten und außerdem Positionen noch Physikdaten gespeichert werden müssen, sollte von Anfang an der Speicherkonsum auf der Grafikkarte mit eingeplant werden.
 Die Anzahl der Komponenten sollte sich möglicherweise durch vier teilen lassen. Zudem sollte beim Speichern statt float32 möglichst nur float16 genutzt werden.
-Ein Beispiel wäre ein einfaches Partikelsystem: Für drei Positionskomponenten, eine Zeitkomponente, drei Geschwindigkeitskomponenten und eine noch freie Komponente z.B. für Masse, werden 8 Werte benötigt. Bei einer Verwendung von float16 und 2^20 Partikeln, werden ganze 16MB GPU Ram verbraucht. Da es nicht möglich oder sinvoll ist in eine aktive Textur zu schreiben, wird eine zweite Textur benötigt, die die selbe Größe hat. So verbraucht unser Partikelsystem 32 MB GPU Ram. Da immer zwischen diesen zwei Buffern hin und her gerendert wird, spricht mach auch von einem Ping-Pongbuffer.
+Ein Beispiel wäre ein einfaches Partikelsystem: Für drei Positionskomponenten, eine Zeitkomponente, drei Geschwindigkeitskomponenten und eine noch freie Komponente z.B. für Masse, werden 8 Werte benötigt. Bei einer Verwendung von float16 und 2^20 Partikeln, werden ganze 16MB GPU Ram verbraucht. Da es nicht möglich oder sinnvoll ist in eine aktive Textur zu schreiben, wird eine zweite Textur benötigt, die die selbe Größe hat. So verbraucht unser Partikelsystem 32 MB GPU Ram. Da immer zwischen diesen zwei Buffern hin und her gerendert wird, spricht mach auch von einem Ping-Pongbuffer.
 Damit keine getrennten Buffer für Position und Geschwindigkeit verwendet werden müssen, sind Multiplerendertargets von Vorteil. Diese sind nicht schwerer zu verwenden als normale Framebufferobjekte. Eine Einschränkung ist, dass nur Rendertargets mit gleichen Bitanzahlen kombiniert werden können. So lässt sich ein 1x float32 mit einem 2x float16 und einem RGBA8 Rendertarget kombinieren. Ein RGBA_float16 Target z.B. lässt sich nur mit einem RG_float32 und sich selbst kombinieren.

@@ Zeile 48: / Zeile 48: @@
 ==Implementation per Texturlookup im Vertexshader==
-Auch wenn Besitzer von ATI Karten jetzt dumm gucken, weil die Pixelshader3.0 kompatiblen Karten den Texturelookup im Vertexshader nicht unterstützen, werde ich als erstes diesen Weg zeigen, da er am einfachsten ist. Um eventuelle Probleme mit Float16 zu umgehen wird hier durchgängig float32 benutzt. Die Partikelanzahl beträgt 2^16. Mehr Partikel sollten aber kein großes Problem sein.
+Auch wenn Besitzer von ATI Karten jetzt dumm gucken, weil die Pixelshader 3.0 kompatiblen Karten den Texturelookup im Vertexshader nicht unterstützen, werde ich als erstes diesen Weg zeigen, da er am einfachsten ist. Um eventuelle Probleme mit Float16 zu umgehen wird hier durchgängig float32 benutzt. Die Partikelanzahl beträgt 2^16. Mehr Partikel sollten aber kein großes Problem sein.
 ===Initialisierung===
-Für ein Partikelsystem welches mit 8 Floats pro Partikel auskommt. Kann man so die nötigen Texturen und Framebufferobjekte erzeugt werden. Zusätzlich wird noch ein VBO mit Vertexdaten notwendig, welches Texturkoordinaten für jeden Texel der Textur enthällt:
+Für ein Partikelsystem welches mit 8 Floats pro Partikel auskommt. Kann man so die nötigen Texturen und Framebufferobjekte erzeugt werden. Zusätzlich wird noch ein VBO mit Vertexdaten notwendig, welches Texturkoordinaten für jeden Texel der Textur enthält:
 <source lang="cpp">
 for (i=0;i<4;i++){
@@ Zeile 80: / Zeile 80: @@
 glBufferDataARB( GL_ARRAY_BUFFER_ARB, 65536 *2 * sizeof(float), data, GL_STATIC_DRAW_ARB );
 </source>
-Anschließend sollten die Shader geladen werden. Benutzt für loadShader() eure eigene Funktion zum shader laden oder schaut im erstem GLSL Tutorial nach wie man einen shaderloader schreibt. Anschließen sollten die Uniformvariablen der Texturen gesetzt werden.
+Anschließend sollten die Shader geladen werden. Benutzt für loadShader() eure eigene Funktion zum shader laden oder schaut im erstem GLSL Tutorial nach wie man einen Shaderloader schreibt. Anschließen sollten die Uniformvariablen der Texturen gesetzt werden.
 <source lang="cpp">
@@ Zeile 94: / Zeile 94: @@
 ===Haupschleife===
-Damit das Pingpongrendering leicht gesteuert werden kann sollte eine Variable immer zwischen dem Wert 0 und 1 hin und her wechseln. Als erstes der Teil, der die Partikelphysik in den Pingpongbuffer rendert:
+Damit das Ping-Pong-Rendering leicht gesteuert werden kann sollte eine Variable immer zwischen dem Wert 0 und 1 hin und her wechseln. Als erstes der Teil, der die Partikelphysik in den Pingpongbuffer rendert:
 <source lang="cpp">
 pass = (pass+1)%2;
@@ Zeile 118: / Zeile 118: @@
-Nun noch der Teil, der die Partikel als Points rendert. Gegebenfalls sind Poinsprites sinvoller, zumal sie mit GLSL 1.2 noch ein wenig flexibler werden.
+Nun noch der Teil, der die Partikel als Points rendert. Gegebenfalls sind Poinsprites sinnvoller, zumal sie mit GLSL 1.2 noch ein wenig flexibler werden.
 <source lang="cpp">
@@ Zeile 138: / Zeile 138: @@
 Es werden zwei Vertex und Pixelshader gebraucht.
-Der Partikelphysikvertexshader muss nur die Variablen an den Pixelshader weiter geben. Prinzipell wäre es auch möglich die ModelViewProjectionMatrix zu umgehen, so dass die eventuell vorhandene Perspektive nicht stöhrt. Auch die Texturkoordinaten ließen sich wegrationalisieren. Damit alles leicht verständlich bleibt hier die gewohnte Variante:
+Der Partikelphysikvertexshader muss nur die Variablen an den Pixelshader weiter geben. Prinzipell wäre es auch möglich die ModelViewProjectionMatrix zu umgehen, so dass die eventuell vorhandene Perspektive nicht stört. Auch die Texturkoordinaten ließen sich wegrationalisieren. Damit alles leicht verständlich bleibt hier die gewohnte Variante:
 <source lang="glsl">
 void main(void){
@@ Zeile 161: / Zeile 161: @@
 </source>
-Im Rendershader muss die eigendliche Position (auch Normalvektoren und Farben) per Texturelookup ausgelesen werden. Um Bandbreite zu sparen sollten diese Variablen Werte möglichst weit zusammen gepackt werden. Um Latenzen zu verstecken sollte man die Ergebnisse der Lookups nach Möglichkeit erst benutzen, wenn man andere Dinge berechnet hat.
+Im Rendershader muss die eigentliche Position (auch Normalvektoren und Farben) per Texturelookup ausgelesen werden. Um Bandbreite zu sparen sollten diese Variablen Werte möglichst weit zusammen gepackt werden. Um Latenzen zu verstecken sollte man die Ergebnisse der Lookups nach Möglichkeit erst benutzen, wenn andere Dinge bereits berechnet wurden.
 <source lang="glsl">
@@ Zeile 174: / Zeile 174: @@
 </source>
-Der Pixelshader zum rendern der Partikel kan sehr einfach sein. Sollte jedoch später ein wenig mehr machen als nur weiße Punkte zu zeichnen:
+Der Pixelshader zum rendern der Partikel kann sehr einfach sein. Sollte jedoch später ein wenig mehr machen als nur weiße Punkte zu zeichnen:
 <source lang="cpp">

@@ Zeile 38: / Zeile 38: @@
 ==Probleme bei der Implementation==
-Während die Implementation der Frambufferobjekte sehr sauber ist und das Ping-Pong rendering an sich kein Problem darstellen sollte, macht das Nutzen der Pixeldaten als Vertexdaten richtig Stress. Die einzige halbwegs saubere Möglichkeit ist die Verwendung eines Pixelbufferobjektes. Jedoch hat dies den großen Nachteil, das es ein großer Speicherfresser ist, da alle Daten kopiert werden. Wenn unsere 2^20 Vertices auf Float32 aufgebläht werden, lösen sich weitere 32MB auf. Nun gibt es nur zwei sinnvolle Möglichkeiten:
+Während die Implementation der Framebufferobjekte sehr sauber ist und das Ping-Pong-Rendering an sich kein Problem darstellen sollte, macht das Nutzen der Pixeldaten als Vertexdaten richtig Stress. Die einzige halbwegs saubere Möglichkeit ist die Verwendung eines Pixelbufferobjektes. Jedoch hat dies den großen Nachteil, das es ein großer Speicherfresser ist, da alle Daten kopiert werden. Wenn unsere 2^20 Vertices auf Float32 aufgebläht werden, lösen sich weitere 32MB auf. Nun gibt es nur zwei sinnvolle Möglichkeiten:
-Es wird ein relativ kleines PBO  benutzt, welchen nur 2^16 Vertices abarbeitet, der Vorteil ist, dass einige Grafikkarten diese kleineren VBOs etwas schneller abarbeiten können. Ansonsten fallen zwar mehr Funktionsaufrufen an, dafür wird eine Menge RAM auf der Grafikkarte gespart. Dieser Weg bereitet einem besonders nette Überraschungen beim coden, da die Konzepte der FBOs irgendwie nicht zu den PBOs passen.
+Es wird ein relativ kleines PBO benutzt, welchen nur 2^16 Vertices abarbeitet, der Vorteil ist, dass einige Grafikkarten diese kleineren VBOs etwas schneller abarbeiten können. Ansonsten fallen zwar mehr Funktionsaufrufen an, dafür wird eine Menge RAM auf der Grafikkarte gespart. Dieser Weg bereitet einem besonders nette Überraschungen beim coden, da die Konzepte der FBOs irgendwie nicht zu den PBOs passen.
-Die zweite Möglichkeit erscheint auf dem erstem Blick noch sauberer, läuft jedoch nicht auf ATI Karten: Es wird ein kleines VBO mit Indexkoordinaten gebildet, welches einen kleinen Teil der Textur mit den Vertexdaten indiziert. Dieser Bereich lässt sich mit zwei Uniformvariablen verschieben, so das ohne kopieren der Daten alle Partikel gerendert werden können. Möglicherweise gibt es hier eine weitere Beschränkung auf Float32 Texturen.
+Die zweite Möglichkeit erscheint auf dem erstem Blick noch sauberer, läuft jedoch nicht auf ATI Karten: Es wird ein kleines VBO mit Indexkoordinaten gebildet, welches einen kleinen Teil der Textur mit den Vertexdaten indiziert. Dieser Bereich lässt sich mit zwei Uniformvariablen verschieben, so das ohne kopieren der Daten alle Partikel gerendert werden können. Möglicherweise gibt es hier eine weitere Beschränkung auf Float32-Texturen.
 In Zukunft sollte dieses Problem mit den "uerbuffers" oder "superbuffers" gelöst werden. Leider scheinen sich da Nvidia und ATI nicht einigen zu können.

@@ Zeile 2: / Zeile 2: @@
 So mal wieder was schreiben wo von ich keine Ahnung hab... (ironisch gemeint. Ich hab nur noch kein fertiges Testprogramm und es nirgends richtig dokumentiert)
-Sicher habt die meisten zumindest schon mal von Partikelsystemen gehöhrt. Da die Leistung der Grafikkarten in den letzten Jahren immer größer wurde und auch die Flexibilität immer größer wurde liegt es nahe ein Partikelssystem direkt in GLSL zu programieren. Dadurch, dass keine Daten mehr zu der Grafikkarte transportiert werden müssen und die CPU von den Berechnungen entlastet wird, sollten um eine Größenordnung mehr Partikel möglich sein.
+Sicher habt die meisten zumindest schon mal von Partikelsystemen gehört. Da die Leistung der Grafikkarten in den letzten Jahren immer größer wurde und auch die Flexibilität immer mehr zunahm, liegt es nahe ein Partikelsystem direkt in GLSL zu programmieren. Dadurch, dass keine Daten mehr zu der Grafikkarte transportiert werden müssen und die CPU von den Berechnungen entlastet wird, sollten um eine Größenordnung mehr Partikel möglich sein.
-Im gegensatz zu den klassischen Partikelsystemen wo alle Partikel unabhängig von einander sind, gibt es auch Partikelsysteme, bei denen Partikel mit einander verbunden sind. Dazu gehöhren unter anderem auch Seile und Kleidung. Der übergang zu echten Physiksimulation ist fließend. Der wahrscheilich größte unterschied ist, das ein Partikelsystem nur ein grafischer Effekt ist und keinen Einfluss auf die restliche Physik nimmt.
+Im Gegensatz zu den klassischen Partikelsystemen wo alle Partikel unabhängig von einander sind, gibt es auch Partikelsysteme, bei denen Partikel mit einander verbunden sind. Dazu gehören unter anderem auch Seile und Kleidung. Der Übergang zu echten Physiksimulation ist fließend. Der wahrscheilich größte Unterschied ist, das ein Partikelsystem nur ein grafischer Effekt ist und keinen Einfluss auf die restliche Physik nimmt.
 ==Grundlagen für die Implementierung==