Partikelsysteme & Schwärme

Transkript

1 Partikelsysteme & Schwärme Version August 2006 Vortrag von: Irma Sejdic, Dominik Erdmann, Daniel Wilhelm & Christoph Kurz Im Rahmen des Seminars: Programmierung von Grafikkarten Universität Kassel Seminarleiter: Prof. Claudia Leopold Björn Knafla - 1 -

2 Inhaltverzeichnis 1.1 Einführung Basisidee Stochastische Partikelsysteme Strukturierte Partikelsysteme 1.3 Aufbau eines Partikelsystems Partikel-Eigenschaften Partikel-Emitter Generierung eines Bildes Partikel-Erzeugung Attribut-Zuweisung Partikel-Löschung Aktualisierung der Attribute Rendering Partikel-Löschung Aktualisierung der Attribute Rendering 1.4 Partikelhierarchien Anwendung Partikel und deren Kollision Partikelsysteme und Schwärme im Vergleich Theorie der Schwarmsimulation Schwarmverhalten Kollision 3.3 Schwärme auf der Hardware (Grafikkarte / CPU) Schwarmverhalten Kollision Ablauf Neighboursearching - 2 -

3 Partikelsysteme 1.1 Einführung Bis zum Beginn der 1980er Jahre blieb den Computergrafikern die realitätsnahe Visualisierung von Objekten ohne feste Oberfläche verschlossen. Die Explosionen eines Raumschiffes in Videospielen wurden als erstes durch einzelne rot, gelb und weiß dargestellte Punkte verwirklicht. Die Explosionspartikel mussten explizit und individuell gesetzt werden. Das war sehr aufwendig. Der Grafikspezialist W. T. Reeves ermöglichte im Jahre 1982 erstmals die automatische Generierung der Partikel. Reeves arbeitete an den Effekten für die Filmproduktion Star Trek II: The Wrath of Khan. Es sollte im Film eine Computersimulation des sogenannten Genesiseffekts dargestellt werden. Er schuf mit dieser Entwicklung die Grundlage für zahlreiche neue Möglichkeiten in der computergrafischen Objektmodellierung. Eine wichtige Weiterentwicklung war der Einsatz von Partikelsystemen zur Darstellung von Pflanzen, Gräsern und Bäumen wurde der erste Vogelschwarm simuliert. 1.2 Basisidee Partikelsysteme bestehen aus Ansammlungen von einfachen Grafikobjekten, Partikel genannt, die zusammen ein großes Objekt bilden. Sie werden in der Computergrafik zur Darstellung von natürlichen Phänomenen verwendet, deren Form nicht eindeutig definierbar ist und die keine glatte und klar abgrenzbare Oberfläche besitzen, wie z.b. Feuer, Wasser, Wolken, Bäume, Gräser, Dampf/Rauch und Textilien. Partikelsysteme können in zwei Gruppen unterteilt werden: a. Stochastische Partikelsysteme (Darstellung von Feuer, Nebel und Rauch) b. Strukturierte Partikelsysteme (Modellierung von Graslandschaften und Wäldern) Stochastische Partikelsysteme Bei stochastischen Partikelsystemen ist das Verhalten der Partikel unabhängig voneinander definiert. Ein Körper (Objekt), dessen Volumen Partikel ausfüllen, wird durch Häufungen von Partikeln beschrieben. Ein Objekt, das durch ein Partikelsystem beschrieben wird, hat keine eindeutige geometrische Form. Die Attribute und Positionen der einzelnen Partikel und damit des ganzen Systems, ändern sich in Abhängigkeit von der Zeit Strukturierte Partikelsysteme Partikelsysteme werden nicht nur zur Simulation von Feuer und Explosionen eingesetzt, sondern es gibt auch andere Anwendungsgebiete. Dies sind strukturierte Partikelsysteme, bei denen die Partikel voneinander abhängig sind. Diese werden zur Simulation von Bäumen, Gräsern und Wäldern eingesetzt. Die einzelnen Partikel eines solchen Partikelsystems müssen dabei ein zusammenhängendes 3D-Objekt bilden. 1.3 Aufbau eines Partikelsystems Partikel-Eigenschaften Partikelsysteme bestehen aus zwei Komponenten: Partikeln, den Elementen des Systems und dem Emitter, der die Kontrolle über die Partikel besitzt. Partikelsysteme sind dynamische Systeme d.h. man kann sie während der Simulationslaufzeit beliebig anpassen. So ist jeder Partikel ein dynamisch veränderbarer Teil eines Partikelsystems und hat eine endliche Lebensdauer. Es entstehen ständig neue Partikel während alte gelöscht bzw. durch neue ersetzt werden. Am Beginn der Modellierung eines Partikelsystems wird ein einzelner Partikel definiert. Ein Partikel kann dabei ganz unterschiedliche Formen haben. Neben der Grundform können dem Partikel noch andere Eigenschaften zugeordnet werden. Die gängigsten und nahezu in jedem Partikelsystem verwendeten Eigenschaften für jeden erzeugten Partikel sind im Folgenden aufgeführt: - 3 -

4 Position: Die Position beschreibt den Punkt im Raum, an dem sich der Partikel während der Laufzeit der Animationsszene befindet. Geschwindigkeit und Richtung: Mit einem Beschleunigungs- und Richtungsvektor wird die Bewegung des Partikels in der Animationsszene festgelegt. Größe: Die Größe kann einem Partikel zugeordnet werden, wenn es als ein- oder mehrdimensionale Struktur verwendet wird. Die Größe kann sich während der Lebenszeit ändern. Farbe: Die anfangs festgelegte Farbe kann sich auch im Laufe der Lebenszeit ändern. Transparenz: Die Partikel können einen Transparenzwert haben, der sich auch während der Lebenszeit ändert. Form/Aussehen: Geometrie, welche an der Partikelposition dargestellt wird. Lebensdauer: Bezieht sich auf die Zeit zwischen der Generierung (Geburt) und dem Ablauf der Lebenszeit (Tod) eines Partikels Partikel-Emitter Jedes Partikelsystem besitzt mindestens einen Partikel-Emitter. Sie können verschiedene Formen annehmen und bestehen aus einer zentralen Abschussstelle und einer Ansammlung fliegender Partikel, die ausgestoßen (emittiert) werden. Alle Partikel kommen von einem Emitter. Dieser gibt gewisse Grenzen für die Attribute der einzelnen Partikel vor (z.b. die Geschwindigkeit und die Richtung) Generierung eines Bildes Der Ablauf aller Berechnungen, welche für die Darstellung der Partikel eines Frames vorzunehmen sind, lässt sich in fünf unterschiedliche Phasen unterteilen (siehe Abbildung 1.1). Abb. 1.1: Fünf Lebensphasen eines Partikels [1.1] Partikel-Erzeugung Während der ersten Phase werden neue Partikel erzeugt. Dabei ist die Anzahl der neu erzeugten Partikel sehr wichtig, da sie die Dichte des dargestellten Objekts bestimmt. Die Berechnung der Anzahl neuer Partikel pro Frame unterliegt stochastischen Prozessen

5 Attribut-Zuweisung In der zweiten Phase werden jedem neuen Partikeln seine Attributwerte zugewiesen (siehe Abschnitt 1.3.1) Partikel-Löschung In der dritten Phase werden die Partikel entfernt, deren Lebensdauer überschritten wurde. Bei der Erzeugung erhält jeder Partikel ein Lebensdauer-Attribut, welches auf einen Zahlenwert gesetzt wird. Mit jedem neu generierten Bild wird der Zahlenwert um eins dekrementiert. Wenn der Wert Null erreicht, wird der Partikel gelöscht. Auch die Partikel, die nichts mehr zum Bild beitragen, werden gelöscht Aktualisierung der Attribute In der vierten Phase werden die noch vorhandenen Partikel im System entsprechend der gesetzten Attribute bewegt und verändert. Einfache Partikelsysteme halten sich an einmal zugewiesene Attribute, bei anderen werden neue Attribute berechnet. Andere wiederum werden durch physikalische Gesetze wie Gravitation und magnetische Anziehung beeinflusst Rendering In der fünften Phase, nachdem die Änderungen an den Partikeln vorgenommen und Attribute festgelegt wurden, werden die Daten dem Renderingsystem zur letztendlichen Darstellung des Bildes übergeben. Da die klassischen 3D-Renderingverfahren beim Rendern eines Objekts mit Tausenden von Partikeln extreme Rechenzeit benötigen, wurden spezielle Renderingroutinen für diverse Partikelsysteme entworfen. Wegen der großen Menge an Partikeln können auch gewisse Probleme entstehen (z.b. bei der Berechnung von Transparenz, Überdeckung von Partikeln oder Schattenwurf). 1.4 Partikelhierarchien Um besondere Effekte zu simulieren, wie z.b. die Erzeugung einer Feuerwand, müssen verschiedene Feuerherde gebildet werden, die wiederum kleinere Feuer entfachen. Dafür wurden hierarchisch organisierte Partikelsysteme entwickelt, die baumartig strukturiert sind. Mit der Hierarchie können Partikelsysteme neue Partikel erzeugen und löschen, die ihrerseits wieder Partikel oder Partikelsysteme generieren oder kontrollieren können. So kann es mehrere Quellen (Emitter) für neue Partikel geben. Hierarchisierte Partikelsysteme eignen sich für die Darstellung kompliziert aufgebauter Objekte. 1.5 Anwendungen Der Genesis-Effekt Der Genesis-Effekt aus Star Trek II beschreibt die Ausbreitung einer Explosion von einem Einschlagpunkt einer Bombe auf einem leblosen Planeten im Weltraum. Von dem Einschlagpunkt soll sich eine Feuerwand über die Oberfläche des Planeten ausbreiten. Das Feuerwandelement der Genesis-Demo wird über eine 2-Stufen-Hierarchie von Partikelsystemen realisiert. Der Einschlagpunkt wurde zum übergeordneten Systems (top-level-system), das die Partikel emittierte, die selbst wiederum Partikelsysteme waren und als untergeordnete Partikel-Systeme (second-level-system) charakterisiert wurden. Die neuen untergeordneten Partikelsysteme breiten sich in wachsenden Kreisen, ausgehend vom Zentrum (top-level-system), aus (siehe Abbildung 1.2). Die Anzahl der second-level- Partikelsysteme pro Kreis ergab sich aus einer zuvor festgelegten Dichtekonstanten und in Abhängigkeit vom Umfang des Kreises. Die eigentliche Explosionen und Feuerpartikelemissionen gingen von second-level-systemen aus. Die Generierung erfolgte auf Basis des Abstands zum Einschlagpunkt und die Parameter wurden auf Basis der Elternsysteme zugeteilt. Die Partikel werden von der Oberfläche immer nach oben emittiert und durch Gravitation in einer parabolischen Flugbahn auf die Planetenoberfläche zurückgezogen (siehe Abb. 1.3). Die Emissionen und Teilexplosionen fanden in unterschiedlichen Höhen über der Oberfläche statt, was den Eindruck der Feuerwand entstehen ließ

6 Abb. 1.2: Schematische Sicht eines hierarchischen Partikelsystems [1.1] Abb. 1.3: Orientierung der Geschwindigkeits- und Richtungsvektoren [1.1] 2 Partikel und deren Kollision Es gibt hauptsächlich zwei Verfahren um Partikel zu realisieren: Das statuslose Verfahren geht davon aus, dass man immer vom Anfangspunkt bis zum aktuellen Zeitpunkt rechnet. Man hat den Partikel, weiß wie er wo losflog und berechnet dessen aktuelle Position dann immer mit Hilfe der Anfangsposition mal der vergangen Zeit. Dieses Verfahren ist an sich recht simpel und leicht zu berechnen. Allerdings wird es exponentiell aufwendiger, wenn man dynamische Objekte mit in die Simulation nimmt, an denen die Partikel abprallen sollen. Dann muss jedes Mal berechnet werden von wo ein Partikel kam, wo es wie abprallte und wie es weiterflog. Um das Problem zu umgehen, entwickelte man das dynamische Partikelsystem, welches für jeden Partikel die momentane Position speichert und dadurch nur noch einen weitern Schritt berechnen muss. Ob nun eine Kollision in einem vorhergehenden Schritt stattfand, spielt hier keine Rolle mehr. Abb. 2.1: Modellierung eines Wasserfalls mit einem Partikelsystem [2.1] Berechnet werden die Partikel auf den Fragmentprozessoren, wodurch eine simultane Berechnung mehrere Partikel möglich ist. Gespeichert werden diese danach als 2D-Textur, da eine Grafikkarte mit diesen Daten am besten umgehen und rechnen kann. Um 3D-Vektoren zu speichern, welche für die Kollisionserkennung benötigt werden, werden sogenannte depth maps verwendet. Wie sie von Stephan Gsöllpointner in seinem Projekt [2.1] beschrieben werden. Durch die darin vorgespeicherten Normalverktoren können die Fragmentshader schneller einen Abprallwinkel der Partikel berechnen. Denn dadurch, dass man den Normalvektor schon hat, kann man den Partikel einfach an dem Normalvektor spiegeln, was für eine Grafikkarte recht schnell zu erledigen ist. Für die Kollision selbst gibt es zwei Ansätze: Man kann die Grafikkarte eine Annäherung registrieren lassen. Die normale Kollisionsberechnung (ob eine stattfindet, und wenn ja wie) wird der CPU überlassen. Da man aber die Probleme bzw. den Flaschenhals (Daten von der Grafikkarte zur CPU zu transportieren) kennt, hat man Algorithmen entwickelt, die selbst die Kollisionserkennung der Grafikkarte überlassen. Sie können sogar den Abprallwinkel berechnen und brauchen die CPU nur noch, wenn es andere Sachen zu kalkulieren gibt (z.b. Auslösen irgendeines Signales etc.). Außerdem werden, um einen Geschwindigkeitszuwachs zu erlangen, von einem komplexen Objekt kleine Unebenheiten, die nicht ins Gewicht fallen, unbeachtet gelassen. Hinzu kommt, dass Werte, die sich nicht - 6 -

7 ändern, wie z.b. Farbe oder Größe, aus dem Stream des Shaders rausgelassen werden, da diese ja nicht neu berechnet werden müssen. Allerdings gibt es ein Problem bei der Partikelkollisionsberechnung: Wenn man ein Objekt hat, an dem ein Partikel abprallen soll, muss sein neuer Flugvektor berechnet werden. Da natürlich auch andere Partikel berechnet werden müssen, kann es passieren, dass ein Partikel nicht genau nur einen Schritt berechnet wird, sondern das man (auch bei schnell fliegenden Partikeln) diesen gleich zwei oder drei Schritte rechnen lassen muss. So kann es passieren, dass ein Partikel in ein zweites Objekt, welches dem ersten recht nahe ist, hineingerechnet wird. Um dies zu vermeiden, wird nach einem Abprall kontrolliert, ob es in einem anderen Objekt steckt. Trifft dies zu, wird ein Zwischenschritt berechnet um den wiederum neuen Abprallvektor zu erhalten. Dies wiederholt man, bis der Partikel wieder frei ist. Schwärme 3.1 Partikelsysteme und Schwärme im Vergleich An sich sind Schwarmmodelle den bereits vorgestellten Partikelsystemen sehr ähnlich: Es werden in beiden Modellen viele Objekte gesteuert. Jedoch gibt es auch einige Unterschiede: Partikel haben eine begrenze Lebenszeit. Schwarmelemente (sogenannte Akteure ) hingegen bestehen so lange, wie der Schwarm an sich besteht. Der Gesamteindruck ist bei einem Partikelsystem maßgebend. Bei einem Schwarm kommt noch der dynamische Eindruck hinzu (siehe z.b. am Himmel ziehende Vogelschwärme). Akteure sind komplexer als Partikel. So können Vögel z.b. mit den Flügeln schlagen und Geräusche von sich geben. Akteure greifen aktiv ins Geschehen ein (steuern sich selbst autonom), wohingegen Partikel nur passiv ihrem Bewegungsablauf folgen. Im Folgenden werden nun die Probleme und Umsetzung der Simulierung eines Vogelschwarmes anhand eines konkreten Beispieles [3.2] beschrieben. 3.2 Theorie der Schwarmsimulation Schwarmverhalten Die ersten Arbeiten an Schwarmsimulationen wurden 1987 von Craig Reynolds durchgeführt. Im Film Stanley and Stella: Breaking the Ice hat Reynolds erstmals eine gesamte Sequenz einer Animationszene am Computer dargestellt. Reynolds stellte einen komplexen Schwarm von Vögeln mit Hilfe einfacher einzelner Elemente dar, welche sich selbst steuerten. Jeder Akteur besaß einen Geschwindigkeitsvektor, welcher sich mit jedem Schritt der Simulation verschob. Neben diesem Geschwindigkeitsvektor besaß jeder Akteur des Schwarms drei einfache Regeln: Kollisionsvermeidung (Akteure vermieden selbstständig Kollisionen) Geschwindigkeitsanpassung (Akteure passten ihre Geschwindigkeit den Nachbarn an) Schwarmzentrierung (Akteure versuchten, in der Nähe ihrer Nachbarn zu bleiben) Mit diesen drei verhältnismäßig einfachen Regeln gelang es Reynolds, komplexe Schwarmmuster zu erstellen Kollision Die Kollisionsvermeidung war hierbei das schwierigste Problem. Dafür gab es mehrere Ansätze. Im ersten Ansatz ist jeder Akteur von einem kreisförmigen Feld umgeben. Sobald ein anderer Akteur mit diesem Feld kollidiert, also in dieses Feld eindringt, wirkt eine vom ersten Objekt abstoßende Kraft auf das zweite Objekt, sodass dies unweigerlich seine Bewegungsbahn ändert. Diese Abstoßkraft ist antiproportional zum Abstand und steigt exponentiell an, sodass hier eine Kollision vermieden wird

8 Dieser Ansatz ist zwar leicht zu modellieren und umzusetzen, hat allerdings einen schwerwiegenden Nachteil: Sollte ein sich Akteur von hinten einem anderen nähern, sodass deren Bewebungsvektoren auf einer Linie liegen, wird der hintere Akteur durch die Abstoßkraft abgebremst und der vordere automatisch beschleunigt. Sobald der gewünschte Abstand wieder gegeben ist, kehren beide auf ihre ursprüngliche Geschwindigkeit zurück. Nun würde der vordere Akteur wieder beschleunigt und der hintere wieder abgebremst werden, sobald sich ihre Kraftfelder wieder berühren usw. Aufgrund der unterschiedlichen Geschwindigkeiten führt dies, solange die Geschwindigkeit nicht angepasst wird, zu einer Endlosschleife, was zu einem unnatürlichen Verhalten führt. Genauso verhält es sich umgekehrt: Die beiden Akteure bewegen sich direkt aufeinander zu, sodass deren Abstoßkraft beide Objekte abbremst, bis sie zum Stillstand kommen. Die beiden Akteure würden nun auf ihrer aktuellen Position verbleiben. Dies sieht gerade bei Vögeln, die dann in der Luft stehen würden, sehr unnatürlich aus. Beim zweiten Ansatz zur Kollionsvermeidung sieht ein Akteur nur die Hindernisse, welche sich direkt vor ihm befinden. Er beachtet also nur die anderen Objekte in seinem Sichtfeld ( Steer-to-avoid ). Nun kann man durch Hüllkörper (je nach Wunsch, z.b. eine Kugel), die um jedes Hindernis gelegt werden und der aktuellen Position des Akteur eine Tangente berechnen, welche von der Position ausgeht und den Hüllkörper des Hindernisses berührt. Dies ist in diesem Falle der neue Ausweichkurs des Akteurs. Bei diesem Ansatz kommt es nicht zu unnatürlichen Bewegungsmustern des Schwarmes, wie bei der ersten Methode mit der Abstoßkraft. Bei der Schwarmzentrierung kann es auch zu Problemen kommen, nämlich genau dann, wenn die simple KI des Akteurs einen Ausweichkurs vorschlägt, der genau entgegengesetzt der Richtung liegt, welche durch die Schwarmzentrierung berechnet wurde. In diesem Falle hat der Akteur eine Entscheidungsmöglichkeit. Ein Lösungsansatz für dieses Problem ist, alle möglichen berechneten Richtungsvektoren zu summieren, sodass dadurch ein Mittelwert zwischen beiden Kursen errechnet wird. 3.3 Schwärme auf der Hardware (Grafikkarte / CPU) Schwarmverhalten Jeder Akteur in einem Schwarm ist durch bestimmte Parameter wie beispielsweise Gewicht, Höchstgeschwindigkeit, Höchstbeschleunigung, globale Position, aktuelle Geschwindigkeit und das Sichtfeld definiert. Einige Informationen wie z.b. Masse, maximale Geschwindigkeit und entsprechend die maximale Beschleunigung verändern sich während der Simulation nicht und werden deshalb bei der Initialisierung des Schwarmes für jeden Akteur gespeichert, die anderen Parameter werden jeden Frame aktualisiert. Um die Menge der Akteure in einem Schwarm zu verwalten, benutzen wir eine Datenstruktur aus der man schnell die Nachbarn jedes Akteurs auslesen und diese immer aktualisieren kann, wenn sich der Schwarm bewegt. Diese Daten werden in einem CellGrid (dreidimensionale Matrix) gespeichert. Dies ist der Teil der Simulation, welcher auf der CPU läuft. Die Aktualisierung geschieht bei jeder Bewegung des Schwarmes. Aufgrund der Tatsache, dass die Umsortierung auf der CPU erfolgt und die großen Dateninformationen des Schwarmes dafür zwischen CPU und GPU ausgetauscht werden müssen, ist dies auch trotz PCIe ein recht langwieriger Prozess. Dies ist der Flaschenhals der Simulation. Für jeden Akteur werden vier Nachbarn gespeichert. Es sind genau vier, da man diese direkt in einem Pixel einer Textur speichern kann. Aufgrund dieser Nachbarn wird das aktuelle Steuerverhalten des Akteures berechnet: Kollisionsvermeidung ( Separation, Abb. 3.1) Schwarmverhalten ( Alignment, Abb. 3.2) Zentrierung zwischen den Nachbarn ( Cohesion, Abb. 3.3) Zusätzlich zu diesem Steuerverhalten könnte man noch einen Schwarmführer einbringen, dem alle Akteure folgen sollen, um eine Bewegung des Schwarmes zu generieren. Andernfalls folgt der Schwarm einer vorgegebenen Route oder sucht sich den Weg per Zufall. Dieser Führer folgt einem fest vorgegebenen Weg. So z.b. kann man die Bewegung eines Fisch- oder etwa eines Vogelschwarms realitätsgetreu darstellen

9 Abb. 3.1: Separation : Kollisionsvermeidung [3.1] Abb. 3.2: Alignment : Schwarmverhalten [3.1] Abb. 3.3: Cohesion : Zentrierung [3.1] Kollision Als Grundvoraussetzung wird das oben bereits angesprochene Modell (siehe Abschnitt 3.2.2) der Kollision als Grundmodell benutzt. Jedoch existieren bei dieser Kraftfeldmethode mit Reduktion auf das Sichtfeld gewisse Nachteile. Einige davon wurden bereits angesprochen, ein weiteres wollen wir an dieser Stelle vorstellen. Man stelle sich folgende Situation vor: Wir haben einen Vogelschwarm, welcher auf eine Gartenmauer mit einer flachen geraden Oberseite zufliegt. Alle Vögel fliegen parallel zu dieser Oberseite und haben eine Höhe, welche oberhalb der Mauerkante liegt, sodass sie nie mit dieser Mauer kollidieren würden. Umgibt man nun diese Mauer mit einem Kraftfeld, so würden die Vögel, sobald sie über die Mauer fliegen, einen Krafteinfluss erfahren, welcher die Vögel abbremsen würde, obwohl diese nie mit der Mauer kollidieren würden. Dies ist eine unnatürliche Bewegung, die wir zu verhindern versuchen. Eine Lösung für dieses Problem ist, dass wir für jedes Hindernis dieser Art folgende Berechnung ausführen: Wir nehmen das Skalarprodukt zwischen dem Richtungsvektor des Vogels und dem Kraftfeldvektor (Normalvektor) der Mauer. Je nach Ergebnis muss nun entsprechend reagiert werden. Das nächste Problem, was bei dieser Lösung auftritt, ist das sogenannte Lack of Time. Was passiert, wenn die Simulation berechnet wird, ein Akteur sich auf ein Hindernis zubewegt und im nächsten Berechnungsschritt (Zeitschlitz) sich in diesem befinden müsste (z.b. Zeitschlitz i: Vogel auf Kollisionskurs, Zeitschlitz i+1: Vogel bereits in der Mauer )? Um dieses Problem zu lösen, wird für jeden Akteur die Route im voraus berechnet, um zu prüfen, ob in naheliegenden Zeitschlitzen eine Kollision erfolgen könnte. Dementsprechend kann man dann früher reagieren Ablauf Dieses Modell der Berechnung (siehe Abb. 3.4) eignet sich besonders gut für Grafikkarten, da jeder Akteur unabhängig berechnet werden kann und benutzt die Möglichkeit der simultanen Berechnung mit Streams und Kernel. Die Berechnungen finden auf den Fragmentprozessoren statt, da man dort aus Texturen lesen und schreiben kann. So ist es möglich, die entsprechenden Daten zur Berechnung weiterzureichen. Die Informationen eines Akteurs werden in mehreren Texturen (sogenannten Quads ) gespeichert, sodass alle Informationen aller Akteure gleichzeitig im Speicher der Grafikkarte zur Verfügung stehen. Aufgrund der bereits bekannten Tatsache, dass die Anzahl der Instruktionen pro Fragmentprogramm limitiert ist, wird das sogenannte Multipass-Schema verwendet: Die Ausgabe des Fragmentprogrammes wird als Eingabe für das nächste Fragmentprogramm benutzt. So können auch Programme mit mehr als der limitierten Instruktionsanzahl ausgeführt und abgearbeitet werden. Abb. 3.4: Steuerverhalten auf der Grafikkarte [3.2] - 9 -

10 Die daraus berechneten Ergebnisse werden an die CPU zurückgegeben, damit diese den Schwarm in der Datenstruktur neu ordnen kann (siehe Abschnitt 3.3.4). Des Weiteren werden hierdurch die neuen Nachbarn für die einzelnen Akteure berechnet. Wie bereits erwähnt, ist dies der Flaschenhals der Simulation, da hier große Datenmengen zwischen CPU und Grafikkarte ausgetauscht werden müssen Neighboursearching auf der CPU Das Problem bei der Berechnung der Nachbarn auf der CPU ist, dass jeden Frame jeder der vier Nachbarn für jeden Akteur neu berechnet werden müsste. Dies ist mit das Aufwendigste an der gesamten Berechnung der Simulation. Diese Berechnungen würden auch dann durchgeführt werden, wenn sowohl der Akteur als auch alle vier Nachbarn dieselbe Geschwindigkeit und Richtung hätten und sich somit keiner der Nachbarn geändert hätte. In diesem Falle wäre die Berechnung unnötige Ressourcenverschwendung. Um dieses Problem zu umgehen, wird eine 3x3x3-Matrix ( Scattering-Matrix, siehe Abb. 3.5) benutzt mit den Werten aus dem Bereich {-1, 0, 1} auf jeder Achse, um die Bewegungsänderung des Schwarmes zu erkennen. Das Prinzip ist einfach: Jeder Akteur teilt der CPU mit, welche Richtungsänderung er durchgeführt hat. Hat sich z.b. die Richtung überhaupt nicht geändert, gibt der Akteur der CPU das Zahlentripel [0, 0, 0] zurück. Somit erhöht die CPU die Anzahl der Akteure, welche keinen Richtungswechsel durchgeführt Abb. 3.5: Scattering-Matrix [3.2] haben, um eins. Das bedeutet, die CPU speichert die Anzahl der Akteure, welche einen Richtungswechsel in eine bestimmte Richtung vorgenommen haben in den Scattering-Matrix ab. Somit kann die CPU bestimmen, ob nun die Nachbarn neu berechnet werden müssen, oder nicht. Ist z.b. ein große Anzahl der Akteure in einem Feld gespeichert, so hat (fast) der komplette Schwarm dieselbe Richtungsänderung durchgeführt und die Nachbarn haben sich nicht verändert. Sollte jedoch eine spärliche Verteilung auf mehrere Zellen in dieser Matrix gegeben sein, so muss die CPU die Nachbarn neu berechnen, da diese sich mit sehr hoher Wahrscheinlichkeit geändert haben

11 Anhang: Quellenangaben [1.1] Methoden der Computeranimation Dietmar Jackel, S. Neunreither, F. Wagner [1.2] Computergrafik und OpenGL D. Orlamünder, W. Mascolus [1.3] Jeff Lander: The Ocean Spray in Your Face [2.1] Stephan Gsöllpointner: Modellierung eines Wasserfalls mit einem Partikelsystem [3.1] Homepage von Craig Reynolds [3.2] Simulation eines Vogelschwarmes