Analyse und Vergleich von Programmen zur glaubhaften Zerstörung von virtuellen Objekten

Transkript

1 Analyse und Vergleich von Programmen zur glaubhaften Zerstörung von virtuellen Objekten Fachbereiche IEM und MND der Fachhochschule Gießen-Friedberg Diplomarbeit vorgelegt von Johannes Stamm geb. in Friedberg durchgeführt bei 3D Maximal GmbH Referent der Arbeit: Dr.-Ing. Cornelius Malerczyk Korreferentin der Arbeit: Dipl.-Math. (FH) Sabine Langkamm Betreuer bei 3D Maximal: Garrit Pieper Fachbereiche Informationstechnik-Elektrotechnik-Mechatronik IEM und Mathematik, Naturwissenschaften und Datenverarbeitung MND Friedberg, 2010

2

3 Danksagung Verschiedene Personen haben zum Gelingen dieser Arbeit beigetragen, und bei denen möchte ich mich an dieser Stelle ganz herzlich bedanken. An erster Stelle möchte ich mich bei meinen Referenten Dr.-Ing. Cornelius Malerczyk, sowie Dipl.-Math. (FH) Sabine Langkamm für ihre Hilfestellung und die vielen Ratschläge bedanken. Dank gilt auch meinem Betreuer Garrit Pieper für seine Hilfe, sowie Hannah Dewies und Martin Trippen für die zur Verfügung gestellte Software und Modelle. Ebenfalls möchte ich mich bei Florian Wittwer und Sebastian Schäfer für das Korrekturlesen der Diplomarbeit bedanken. Auch meinen Eltern möchte ich explizit für die langjährige Unterstützung während des Studiums bedanken. Mein besonderer Dank gilt meiner Freundin Carmen Spitzhorn für ihre Fürsorge, Geduld und Unterstützung während der Diplomarbeit. i

4

5 Selbstständigkeitserklärung Ich erkläre, dass ich die eingereichte Diplomarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Friedberg, Juni 2010 Johannes Stamm iii

6

7 Inhaltsverzeichnis Danksagung Selbstständigkeitserklärung Inhaltsverzeichnis Abbildungsverzeichnis i iii v ix 1 Einleitung Motivation Problemstellung und Zielsetzung Organisation der Arbeit Zusammenfassung der wichtigsten Ergebnisse Stand der Technik Einleitung Hardware Mehrkernprozessoren Grafikbeschleunigung CUDA PhysX Rigid Body Dynamics Soft Bodies Cloth Fluids Software RayFire Blast Code Kiloton Megaton Particle Flow Particle Flow Tools: Box 1,2, Thinking Particles Volume Breaker v

8 Inhaltsverzeichnis vi 2.4 Taxonomie Fazit Zusammenfassung Analyse der Software Einleitung RayFire Aufbau Funktionsweise Objects Fragmentation Physics Layers Particle Flow Aufbau Funktionsweise Menüleiste Depot Ereignisbildschirm Particle Flow Tools: Box Zusammenfassung Vergleich der Software Einleitung Testszene Aufbau Problemstellung RayFire Explosion Vorbereitungen Probleme Ergebnis Particle Flow Explosion Vorbereitungen Probleme Ergebnis Auswertung Arbeitsweise und Funktionalität Benutzerfreundlichkeit Optischer Vergleich Simulationszeit Schlussfolgerung Testszene

9 Inhaltsverzeichnis Story der Testsequenz Problemstellung Aufbau RayFire Vorbereitungen Fragmentierung Particle Flow Vorbereitungen Probleme Ergebnis Auswertung und Diskussion Zusammenfassung Zusammenfassung und Ausblick 79 Literaturverzeichnis 81 vii

10

11 Abbildungsverzeichnis 1.1 Modellvergleich Mehrkernprozessoren Grafikbeschleunigung Rigid Bodies Soft Bodies Cloth Fluids Megaton Taxonomie RayFire GUI RayFire Objects RayFire Shooting RayFire Physics RayFire Reactor RayFire Fragmentation Übersicht RayFire Layers Übersicht RayFire Objects Übersicht RayFire Custom Properties RayFire Fragmentierungs-Typen RayFire Fragmentierungs-Typen RayFire Detailization und Noise RayFire Fragmentation RayFire Physical Options RayFire PhysX Simulation Properties RayFire Bomb RayFire PhysX Simulation Properties RayFire PhysX Demolition Properties RayFire PhysX Demolition Properties RayFire Layers PFlow Particle View PFlow Depot Komponenten ix

12 Abbildungsverzeichnis 3.23 PFlow Operators PFlow Flows PFlow Standard Flow PFlow Presets PFlow Tests PFlow Test Beispiel PFlow PhysX Komponenten PFlow PhysX Flow Testszene 1 Aufbau Testszene 1 Bomb Radius Testszene 1 Grundmauer Testszene 1 RayFire Ergebnis 1a Testszene 1 RayFire Ergebnis 2a Testszene 1 RayFire Ergebnis Testszene 1 RayFire Ergebnis Testszene 1 PFlow Explosion Testszene 1 PFlow Box Testszene 1 PFlow Glue Binding Testszene 1 Particle Flow Ergebnis Testszene 1 Particle Flow Ergebnis Testszene 2 Aufbau Testszene 2 Fragmentierungs-Objekte Testszene 2 Fragmentierung Abgeschlossen Testszene 2 Particle Flow System Testszene 2 Ergebnis x

13 Kapitel 1 Einleitung 1.1 Motivation Die Produktion von Film und Fernsehen hat sich in den letzten drei Jahrzehnten grundlegend verändert. Die Implementierung von computergenerierten Bildinhalten in den traditionellen, analogen Film, hat zu einem Paradigmenwechsel in der Filmindustrie geführt. Mit fortschreitender Entwicklung der Hard- und Software von Computersystemen, erhöht sich der Anteil von digital erzeugten Bildelementen. Die Fähigkeit jedes beliebige Bildelement wie z.b. Vegetation, Gebäude, Charaktere, Licht Situationen, etc. digital nachzubilden, ermöglicht eine realitätsnahe Darstellung der Wirklichkeit, ohne Einsatz und Nachbau von physischen Modellen. Für die Produktion des ersten Krieg der Sterne Films aus dem Jahr 1977, Krieg der Sterne - Episode IV: Eine neue Hoffnung wurden ausschließlich Miniaturmodelle zur Visualisierung von Raumschiffen eingesetzt ( siehe Abbildung 1.1 ). Sogar ganze Filmsets 1, wurden in Originalgröße nachgebaut. Nahezu 30 Jahre später, in Krieg der Sterne - Episode III: Die Rache der Sith werden die Raumschiffe und ein Großteil des gesamten Films mit Hilfe von 3D Visualisierungssoftware auf Computersystemen erstellt ( siehe Abbildung 1.1 ). Abbildung 1.1: Modellvergleich. Links: Ein reales Miniaturmodell. Rechts: Ein computergeneriertes Modell. Lucasfilm Ein Grund hierfür ist, dass die Filmsets und/oder Modelle auch nach deren Erstellung am Computer veränderbar bleiben und nach den Vorstellungen des Regisseurs manipuliert 1 deutsch: Schauplätze 1

14 1. Einleitung werden können. Dagegen muss nach der traditionellen Methode eine Szene immer und immer wieder gedreht werden, bis sie den Ansprüchen des Regisseurs gerecht wird. Dies ist bei dem Einsatz von Spezialeffekten jedoch nicht in jedem Fall möglich. Handelt es sich z.b. um die Sprengung eines Gebäudes, sei es ein aufwendig modelliertes Miniaturmodell oder ein reales Gebäude, kann diese in den meisten Fällen nur ein einziges Mal durchgeführt werden. Mißlingt der Dreh, kann dies, aus Zeit- und/oder Kostengründen, die Beendigung des gesamten Projekts zur Folge haben. Filmemacher sehen deshalb immer häufiger von der Verwendung von Miniaturmodellen ab und entscheiden sich für eine digital generierte Umsetzung von Effektszenen. Es sind zahlreiche Plug-ins, sowie externe Programme zur Zerstörung von virtuellen Objekten auf dem Software-Markt erhältlich, was die Wahl des optimalen Programms erschwert. Jedoch lässt sich die vorhandene Software grundsätzlich in zwei Kategorien einteilen. Auf der einen Seite existieren Programme, welche ausschließlich Starrkörper Berechnungen, so genannte Rigid Body Dynamics, durchführen können. Auf der anderen Seite existieren Partikel Simulationssysteme. 1.2 Problemstellung und Zielsetzung Die glaubhafte Zerstörung von virtuellen Objekten gehört zu den anspruchsvollsten Aufgaben in der 3D Branche. Es existieren eine Vielzahl von Programmen, die sich nicht nur in ihrer Funktionsweise voneinander unterscheiden. Auch werden sie teilweise mit unterschiedlichen Software-Paketen vertrieben und sind somit nur durch den Erwerb dieser spezifischen Software funktionsfähig. Ein Vergleich der, vom Hersteller beworbenen, Fähigkeiten der Produkte ist kein ausreichendes Kriterium um sich für oder gegen einen Kauf zu entscheiden. Die jeweiligen Stärken und Schwächen der einzelnen Produkte zeigen sich meist erst nach längerem Einsatz in einer Produktion. Die vorhandenen Produkte lassen sich grundsätzlich in zwei Kategorien einteilen. Auf der einen Seite existieren Produkte, die ausschließlich Starrkörper- Berechnungen durchführen können. Es wird hierzu eine Physik-Engine verwendet, um das Verhalten der Starrkörper möglichst realistisch erscheinen zu lassen. Auf der anderen Seite stehen die Produkte basierend auf Partikelsystemen. Ursprünglich entwickelt um Effekte wie Feuer, Rauch, o.ä. darzustellen, sind sie mittlerweile zu einer Art Universal-Programm avanciert. Durch Erweiterungsmodule, so genannte Plug-ins, ist es nun ebenfalls möglich eine Physik-Engine zu implementieren und diese gleichzeitig mit den schon vorhandenen Möglichkeiten zu kombinieren 2. Um sich einen Eindruck über jedes der zur Verfügung stehenden Produkte zu verschaffen, müssten diese erworben und ausführlich getestet werden. Eine aus finanzieller-, sowie aus zeitlicher Sichtweise unökonomische Lösung. Auch fehlen bisher Publikationen, die beide Systemarten miteinander vergleichen. Ziel dieser Diplomarbeit ist es deshalb, beide Ansätze zu vergleichen, um die Verfahrensauswahl bei der Erstellung von Effektszenen zu erleichtern. In 2 Auf die Unterschiede beider Ansätze wird in Abschnitt 2.4 näher eingegangen. 2

15 1.3. Organisation der Arbeit beiden Kategorien wird jeweils die in der Industrie am weit verbreitetste Software ausgewählt. Für die Berechnung von Starrkörpern wird Mir Vadim s RayFire 3, ein Plug-in für 3ds Max, verwendet. Als Partikel Simulationssystem kommt das in 3ds Max 4 integrierte Particle Flow von Autodesk 5 zum Einsatz. Zusätzlich zu Particle Flow ist mit der Implementierung des Plug-in Particle Flow Tools: Box 2 6 die Verwendung von NVIDIA s Physik-Engine PhysX 7 gewährleistet. Es folgt eine Analyse der Funktionsweise beider Programme und deren verwendeten Techniken. Diese werden anhand von Beispiel-Szenen verglichen. Anschließend folgt eine Ausarbeitung der Vor- und Nachteile beider Techniken. 1.3 Organisation der Arbeit Die vorliegende Arbeit unterteilt sich in die folgenden Kapitel: In dem nun folgenden Kapitel 2 Stand der Technik, wird dem Leser ein Überblick über die aktuell verfügbare Hard- und Software gegeben. Anschließend werden aus beiden Software- Kategorien die jeweils am weitesten verbreitetste ausgewählt. Das nächste Kapitel Analyse der Software beschäftigt sich mit den im vorherigen Kapitel ausgewählten Programmen und deren Aufbau. Der Leser erhält zudem einen Einblick in den Funktionsumfang beider Programme. Darauf aufbauend erfolgt im vierten Kapitel Vergleich der Software eine Gegenüberstellung beider Programme und insbesondere deren Möglichkeiten zur Zerstörung von virtuellen Objekten. Es folgt eine Testreihe von zwei Szenen, auf die beide Programme angewandt werden. Die Ergebnisse der Gegenüberstellung beider Programme werden im fünften Kapitel Ergebnisse vorgestellt und ausführlich behandelt. Als Abschluss werden die Ergebnisse der gesamten Arbeit in dem Kapitel Zusammenfassung und Ausblick zusammengefasst. 1.4 Zusammenfassung der wichtigsten Ergebnisse Diese Diplomarbeit sollte Programme basierend auf Starrkörper-Berechnungen, sowie Programme basierend auf Partikelsystemen analysieren und deren Techniken miteinander vergleichen. Dafür wurde ein Vergleich von RayFire und Particle Flow und deren Funktionalität durchgeführt. Dieser Vergleich hat ergeben, dass keines der beiden Programme für die Zerstörung von virtuellen Objekten ansich zu empfehlen ist. Beide Programme weisen in wichtigen Aspekten eine praktikable Funktionalität auf. Particle Flow verfügt über keine Möglichkeit Objekte zu fragmentieren. Ohne diese Möglichkeit ist eine glaubhafte Zerstörung von virtuellen Objekten jedoch nicht möglich. RayFire fällt hingegen negativ durch die extrem hohen

16 1. Einleitung Simulationszeiten auf, welche in zeitkritischen Projekten sehr ungeeignet sind. Eine Kombination der Programme anhand einer professionellen Effekt-Szene hat ergeben, dass dies die beste Lösung darstellt. Beide Programme können ihre Stärken nutzen und in Verbindung miteinander ein gutes Endergebnis erzielen. 4

17 Kapitel 2 Stand der Technik 2.1 Einleitung In dem vorangegangenen Kapitel wurde veranschaulicht, welche Problemstellung die Produktauswahl bei der Zerstörung virtueller Objekte mit sich bringt. Ohne funktionsfähige Hardware kann nicht ein einziger Effekt am Computer erstellt werden und ist somit Grundvoraussetzung für jeden 3D Artisten. Jedoch gibt es signifikante Unterschiede der verfügbaren Hardware. Durch gezielten Einsatz von spezieller Hardware, kann die Arbeitsgeschwindigkeit um ein vielfaches erhöht, sowie die Qualität des Endergebnisses gesteigert werden. Diesbezüglich werden in diesem Kapitel die Hardwarekomponenten und technischen Errungenschaften vorgestellt, welche die Industrie dahingehend revolutioniert haben. Anschließend wird ein Überblick über die auf dem Markt erhältliche Software, bzw. Plug-ins gegeben. Firmeninterne Software kann hierbei nicht berücksichtigt werden, da sie weder auf dem freien Mark erhältlich ist, noch genügend Informationen über sie vorliegen. Abschließend werden die vorgestellten Produkte in einer Taxonomie gemäß verschiedener Kategorien klassifiziert und die zu gegenüberstellenden Produkte ausgewählt. 2.2 Hardware In den folgenden Abschnitten wird auf die Entwicklung von Mehrkernprozessoren und Grafikbeschleunigern eingegangen und deren Relevanz in der 3D Visualisierung verdeutlicht. Darauf aufbauend wird das GPGPU-Computing und im speziellen die CUDA Architektur näher beleuchtet. Abschließend werden die Möglichkeiten der PhysX Engine erläutert Mehrkernprozessoren Um die Bedeutung der Existenz von Mehrkernprozessoren nachvollziehen zu können, folgt zunächst ein Überblick der ( Einkern- ) Prozessorentwicklung. Der Prozessor, auch CPU ( Central Processing Unit ) genannt, ist die zentrale Recheneinheit eines Computersystems. Er verarbeitet die Befehle der Software, wandelt sie in, für die Hard- 5

18 2. Stand der Technik ware verständliche, Befehle um und erzeugt eine Ausgabe. Ein Prozessor kann aus einem oder mehreren Prozessorkernen bestehen. Zu Beginn der Entwicklung bestand ein Prozessor aus nur einem Kern. Mit steigender Leistungsfähigkeit von Einkernprozessoren, sind auch die Anforderungen an die Prozessoren stetig gestiegen. Wurden z.b. Computer in den achtziger Jahren überwiegend über eine Kommandozeile vom Benutzer gesteuert, hat sich ein Jahrzehnt später eine grafische Benutzeroberfläche zur Bedienung von Computern durchgesetzt. Die kontinuierliche Steigerung der Leistungsfähigkeit von Einkernprozessoren wurde ursprünglich durch die Erhöhung der Taktfrequenz erzielt. Doch diese Erhöhung kann meistens nur durch die Strukturverkleinerung von Transistoren, den Grundbausteinen von Prozessoren, erreicht werden. Dies wiederum hat eine exponentielle Steigerung des Strombedarfs zur Folge. Somit muss immer mehr Abwärme aus dem Rechner abgeführt werden. Die Implementierung von zwei, oder später auch mehreren Kernen in einen Prozessor, umgeht diese Probleme. Durch eine niedrigere Taktfrequenz beider Kerne kann der produzierte Stromverbrauch enorm reduziert werden, wobei gleichzeitig eine signifikante Geschwindigkeitserhöhung erreicht werden kann. Diese Entwicklung hat die Halbleiterindustrie dazu veranlasst, anstatt die Erhöhung der Taktfrequenzen, die Implementierung von multiplen Kernen zu forcieren. Der bedeutendste Vorteil von Mehrkernprozessoren ist jedoch die Möglichkeit mehrere Prozesse, auch Threads genannt, parallel abzuarbeiten. Falls die benutzte Software Mehrkernprozessoren unterstützt, ist eine theoretische Leistungssteigerung von bis zu 100 pro Kern möglich. Die Multithread Programmierung ist jedoch ein sehr komplexer Themenbereich. Die Anforderungen an den Software-Entwickler, alle Kerne vollständig auszulasten, steigen mit jedem zusätzlich vorhandenen Kern weiter an. Ein Beispiel der Leistungssteigerung durch Mehrkernprozessoren ist in Abbildung 2.1 zu sehen. Ist der Geschwindigkeitsvorteil zwischen einem und zwei, sowie zwei und vier Kernen noch deutlich zu sehen, nimmt er mit steigender Kernanzahl immer weiter ab. Obwohl in der Praxis die Effizienz mit steigender Kernanzahl abnimmt, kann gerade die Branche der 3D-Visualisierung massiv von jedem zusätzlich vorhandenen Kern profitieren. Die in der Branche verwendeten Software Pakete sind fast ausschließlich auf Mehrkernprozessoren optimiert. Auch eine Render Farm, ein Netzwerk von mehreren Computern zur simultanen Bildberechnung, profitiert maßgeblich von Mehrkernprozessoren. Es werden hierbei weniger einzelne Computersysteme benötigt, um eine vergleichbare Leistung zu erreichen, was sich in geringeren Kosten und geringerem Stromverbrauch ausdrückt. Aktuell werden Mehrkernprozessoren von allen führenden Prozessorherstellen angeboten. Im Endkundenbereich sind Prozessoren mit 2, 3 und 4 Kernen, wie z.b. dieintel Core 2 Duo 1 Serie ( 2 Kerne ), die AMD Athlon II X3 2 Serie ( 3 Kerne ) oder auch die Intel Core i7 3 Serie ( 4 Kerne ) seit 2006, 2009, bzw auf dem Markt erhältlich. Seit März 2010 bietet Intel mit dem i7-980x Extreme 4 den ersten nativen 6-Kern Prozessor an. AMD verkauft

19 2.2. Hardware Abbildung 2.1: Übersicht der Leistungssteigerung von Mehrkernprozessoren gegenüber Einkernprozessoren bei optimierter Software. [DG09] den Phenom II X6 1055T 5 mit 6 Kernen seit Ende April diesen Jahres. Im Serverbereich erscheinen die Prozessor Pendants meistens deutlich früher als im Endkundenbereich. Auch sind hier schon Prozessoren mit 8 Kernen, Intel Xeon und sogar 12 Kernen, AMD Opteron 6176 SE 7 verfügbar Grafikbeschleunigung Grafikbeschleunigung erreichte erstmals mit der Serienproduktion des Apple II Microcomputer im Jahre 1977 eine weitere Verbreitung. Dienten sie zu dieser Zeit nur als Bindeglied zwischen CPU und Bildschirmausgabe, wurden im Laufe ihrer Weiterentwicklung immer mehr Berechnungen auf Grafikbeschleunigern, im Allgemeinen Grafikkarten genannt, ausgeführt. Mitte der neunziger Jahre erschienen die ersten 3D-Beschleuniger Grafikkarten. Sie wurden als zusätzliche Steckkarte zu der schon vorhandenen 2D Grafikkarte vertrieben und übernahmen die Berechnung und Darstellung dreidimensionaler Objekte. Die leistungsfähigeren Grafikkarten ermöglichten eine höhere visuelle Qualität in Computerspielen. Proportional zur Qualität stiegen die Anforderungen an die Grafikkarten, was wiederum die Entwicklung von leistungsfähigeren Grafikkarten erforderte. Demzufolge ist die Computerspiele-Industrie ein essenzieller Bestandteil der kontinuierlichen technologischen Weiterentwicklung von Grafikkarten. Mit der Einführung der GPU ( Graphic Processing Unit ) durch NVIDIA, im August 1999 durch die GeForce 256 Serie, erreichte die Entwicklung von Grafikkarten einen wich

20 2. Stand der Technik tigen technologischen Meilenstein. Grafikkarten dieser Generation vereinten 2D- und 3D Berechnungen in einem Gehäuse. Eine zusätzliche Beschleuniger Karte ist somit obsolet. Die GPU Architektur gilt als Grundlage von programmierbaren GPU s, wie sie heute existieren. NVIDIA s technische Definition einer GPU lautet: Ein Einzelchip-Prozessor mit integrierten Transform-, Lighting-, Triangle-Setup/- Clipping und Rendering-Engines, der in der Lage ist, mindestens 10 Millionen Polygone in der Sekunde zu erzeugen.. Die Fähigkeit diese Berechnungen auf der Grafikkarte durchzuführen, führt zu einer Entlastung des Prozessors und ermöglichte einen deutlichen visuellen Qualitätssprung in Computerspielen. Nach 10 Jahren kontinuierlicher Weiterentwicklung haben Grafikkarten die Prozessoren als komplexeste Komponente in Computersystemen überholt. Die Anzahl an verbauten Transistoren einer Grafikkarte übertrifft deutlich die eines Prozessors. Die Differenz zwischen NVIDIA s neuester Grafikkarten Generation GeForce GTX 480 ( 2,9 Milliarden Transistoren 8 ), und Intel s neuesten Desktop Prozessor Core i7-980x EE ( 1,17 Milliarden Transistoren 9 ), ist mit 1,73 Milliarden Transistoren immens 10. Zudem steigt die Performanz von Grafikkarten mit einer Rate von 1.7x (Pixel/Sekunde) und 2.3x (Eckpunkte/Sekunde) pro Jahr deutlich höher an [JDO05], als bei Prozessoren. Dort liegt die Rate gemäß dem Moore schen Gesetz 11 bei ca. 1.4x. Abbildung 2.2 verdeutlicht den signifikanten Leistungsanstieg von GPUs gegenüber CPUs, gemessen in GFLOP 12 pro Sekunde. Ein weiterer Vorteil gegenüber CPU s ist die stärkere Ausrichtung auf Parallelität. Die heutige architektonische Bauweise von Grafikkarten unterscheidet sich grundsätzlich von der Bauweise von zentralen Prozessoreinheiten. Während ein größerer Teil einer CPU für die Steuerung des Kontrollflusses verwendet wird und somit für arithmetische Berechnungen nicht mehr zur Verfügung steht, sind GPU s auf das Rendern spezialisiert. Durch die Hardwarebeschleunigung können GPU s diese Aufgabe deutlich schneller durchführen, als CPU s, welche mit softwarebasierten Ansätzen arbeiten[bal07]. Zur Hardwarebeschleunigung zählen Techniken wie NVIDIA s CUDA, sowie PhysX, welche in den folgenden Abschnitten näher betrachtet werden. Im Bereich der 3D-Visualisierung werden Grafikkarten auf Grund dieser Eigenschaften immer öfter zum Rendern eingesetzt CUDA Compute Unified Device Architecture 13 ist eine paralleleberechnungsarchitektur und wurde von NVIDIA im Sommer 2007 veröffentlicht. Mit CUDA ist es möglich, komplexe Berechnungen aller Art auf der GPU durchzuführen. Ist der Programmcode entsprechend auf die jeweils, Stand: April Nach dem, von Gordon Moore im Jahre 1965, aufgestellten Gesetz, wird sich die Anzahl von Transistoren auf einem Prozessor alle 24 Monate verdoppeln. Siehe auch: 12 Ein Giga-Flop ist gleichbedeutend mit einer Milliarde Gleitkommaoperationen in der Sekunde

21 2.2. Hardware Abbildung 2.2: Historie der Leistungssteigerung von NVIDIA GPUs gegenüber Intel CPUs, gemessen in GFLOP/s. [NVI10] CUDA Architektur optimiert, kann hierbei eine drastische Geschwindigkeitserhöhung gegenüber der Berechnung auf einer CPU erreicht werden. 14. Die Anwendungsgebiete sind dabei nicht auf Computerspiele oder grafische ( 3D- ) Bildbearbeitung beschränkt. Auch in der wissenschaftlichen Forschung werden Berechnungen z.b. zur Medikamentenentwicklung, im Finanzwesen, in der Astrophysik oder für die Bildrekonstruktion bei der Computertomographie auf CUDA Grafikkarten durchgeführt. Die CUDA Architektur ist NVIDIA s Beitrag zur immer populärer werdenden GPG- PU General Purpose Graphic Processing Unit Technik. Die GPGPU Technik ermöglicht es, Grafikkarten nicht nur für grafische Berechnungen zu nutzen, sondern auch allgemeine ( General Purpose ) Berechnungen wie bei einer CPU, auf einer GPU durchzuführen. Den ersten ernstzunehmenden Schritt in Richtung GPGPU machte NVIDIA 1999 mit der Entwicklung der GeForce 256. Durch die Implementierung von programmierbaren Register Combiners 15, erfolgte ein Richtungswechsel in der Industrie. Die bestehende Fixed-Function Pipeline 16, sollte durch eine programmierbare GPU Architektur ( Programmable Pipeline ) abgelöst werden. Eine weitere Veränderung brachte die Einführung von Microsofts DirectX API 17 Version 8 im Jahr DirectX 8 ermöglichte erstmals die Programmierung Combiner sind Teiler von Registern, welche Farbwerte berechnen und ausgeben. 16 sinngemäß: nicht programmierbare Architektur 17 Application Programming Interface, ist eine Programmierschnittstelle für multimedia Anwendungen 9

22 2. Stand der Technik von Vertex und Pixel Shadern 18 auf der Grafikkarte. Waren die Fähigkeiten, allgemeine Berechnungen auf der Grafikkarte auszuführen, bei der 1. Shader Generation noch sehr begrenzt, änderte sich dieser Zustand mit der Shader Version 2. Die Shader API 2 entfernte die meisten Beschränkungen, die nicht-grafische Berechnungen auf der GPU verhinderten, bzw. einschränkten. Dies führte zu einer Vielzahl von Veröffentlichungen, unter anderem von Brook for GPU s von der Stanford University[IB04]. BrookGPU ist eine Entwicklungsumgebung für die Programmiersprache Brook 19, um die GPU als mathematischen Co-Prozessor zu benutzen wurde mit DirectX 9, dem Shader Modell 3, sowie den unterstützenden Grafikkarten der nächste wichtige Schritt vollzogen. Bei dem Shader Modell 3 wurde unter anderem ein Zugriff auf Texturen durch den Vertex Shader möglich, was bis zu diesem Zeitpunkt ausschließlich den Pixel Shadern vorbehalten war. Durch diese Erweiterung konnte ein großer Teil des Datenflusses zwischen CPU und GPU minimiert werden, was zu einer beträchtlichen Geschwindigkeitssteigerung bei vielen Anwendungen führte. Besonders GPU basierte Partikel Engines profitierten von dieser technischem Neuerung[Krü06]. Anschließend wurde mit DirectX 10 das Shader Modell 4 veröffentlicht, welches auch als Unified Shader Model ( deutsch : vereinigtes Shader Modell ) bezeichnet wird. Mit diesem Modell wurde der Geometry Shader 20 eingeführt. Das Prinzip des Unified Shader Modell ist die Benutzung von einheitlichen Befehlssätzen von allen Shader Typen. Somit haben Vertex, Pixel, sowie Geometrie Shader grundsätzlich die gleichen Einsatzmöglichkeiten. Diese Möglichkeiten bringen einen deutlichen Geschwindigkeitszuwachs, sowie mehr Flexibilität in Bezug auf die allgemeine Programmierung mit sich. Im Oktober 2009 veröffentlichte Microsoft die neueste DirectX Version 11. Diese ist nun stark auf die GPGPU, bzw. CUDA ausgerichtet. Sie führt unter anderem Compute Shaders als Neuerung ein. Sie verfolgen das gleiche Ziel wie CUDA und stellen nun das letzte Glied zur frei programmierbaren Grafikkarte dar PhysX PhysX ist eine echtzeitfähige Physik Engine, die zur Simulation von physikalischen Prozessen in der 3D Visualisierung in Computerspielen, aber auch bei Film und Fernsehen verwendet wird. Die PhysX Technologie wurde ursprünglich von der Firma Ageia entwickelt. Neben der softwarebasierten Physik Engine, wird auch eine PPU ( Physics Processor Unit ) als eigenständige Erweiterungskarte vertrieben. Die Software Lösung, auch PhysX SDK 21 genannt, steht für Entwickler kostenlos zur Verfügung, wobei der Kaufpreis der Erweiterungskarte bei ihrer Einführung mehrere hundert Euro beträgt. Dieser Umstand führte zu einer weiten Verbreitung der PhysX Engine in Computerspielen, sowie dem finanziellen Misserfolg der Erweiterungskarte. Nach der Übernahme von Ageia durch NVIDIA im Februar 2008, wurde die PhysX Engine in die nächste Grafikkarten Generation in Verbindung mit CUDA implementiert. Diese Implementation ermöglichte eine hardwarebeschleunigte Durchführung 18 Shader sind Recheneinheiten. Vertex Shader können die geometrische Form von Objekten, sowie deren Position und Beleuchtungsverhalten verändern. Pixel Shader können die Farbe, sowie andere Attribute von jedem Pixel berechnen Der Geometry Shader kannzusätzliche Primitive, wie Punkte, Linien und Dreiecke für die geometrischen Objekten erzeugen, die an ihn übergeben werden. 21 Software Development Kit, deutsch: Entwicklungsumgebung 10

23 2.2. Hardware von physikalischen Berechnungen auf der Grafikkarte. Das PhysX SDK ist für Einkern-, aber auch für Mehrkernprozessoren optimiert. Ebenso profitiert das SDK von multiplen Kernen auf der Grafikkarte. Die PhysX Engine bietet vielseitige Einsatzmöglichkeiten. Man unterscheidet im Allgemeinen vier verschiedene Arten von Simulationen: Rigid Body Dynamics Mit Rigid Body Dynamics ( deutsch: Dynamik starrer Körper ), wird das Verhalten von Starrkörpern simuliert. Um ein möglichst realitätsnahes Verhalten der Körper zu erreichen, werden in der 3D Umgebung verschiedenste physikalische Konzepte aus der realen Welt imitiert. Für jeden in der Simulation vorhandenen Körper werden z.b. Berechnungen für die Position, Geschwindigkeit, Beschleunigung und die Rotationsgeschwindigkeit durchgeführt. Zudem besteht die Möglichkeit jedes Objekt mit unterschiedlichen Materialeigenschaften auszustatten. Die sich dadurch ergebenden variierenden Reibungswiderstände, sowie die Elastizität von Objekten werden ebenfalls berücksichtigt. Bei Kollisionen von Körpern werden vereinfachte Berechnungen durchgeführt, um die Performanz der Simulation zu gewährleisten. Die geometrische Form der Kollisionskörper wird durch verschiedene Primitive Körper, wie z.b. Sphären oder Würfel, ersetzt ( siehe Abbildung 2.3 ). Möglich ist auch eine Annäherung der geometrischen Form durch rein konvexe Oberflächen. Abbildung 2.3: Die komplexe Geometrie des Vogels wird durch eine Vielzahl von Würfeln ersetzt.[an05] Diese Methoden sind als Kompromiss zwischen korrektem physikalischem Verhalten und der Performanz der Simulationen anzusehen, welche zwingend abhängig von der Leistungsfähigkeit der verwendeten Hardware ist. Es ist anzunehmen, dass in Zukunft mit leistungsfähigerer Hardware die Genauigkeit der physikalischen Simulation zunimmt und sich somit den realen Gegebenheiten immer mehr annähern wird. Ebenfalls werden so genannte Ragdoll 22 Algorithmen unterstützt. Mit diesen prozeduralen Algorithmen wird das Bewegungsverhalten von unbelebten menschlichen Körpern ( Ragdolls 22 deutsch: Stoffpuppe 11

24 2. Stand der Technik ) simuliert. Dieses Verfahren wird oft in Computerspielen angewendet, um das Verhalten der virtuellen Charaktere nach ihrem Ableben möglichst realitätsnah abzubilden. Soft Bodies Mit Soft Bodies, ( deutsch: weiche Körper ) wird die Deformation von Objekten simuliert. Hierbei kann sich die äußere Form des Objektes bei einer Kollision mit anderen Objekten verändern, aber auch anschließend wieder in ihre ursprüngliche Form zurückfinden. Man spricht dabei auch von einer Elastizität von Objekten. Wirft man z.b. einen Gummiball mit genügend Kraft gegen eine Wand, wird sich der Ball bei dem Aufprall zusammendrücken und nach dem Abprallen von der Mauer wieder seine ursprüngliche Form zurückgewinnen. Ähnlich verhalten sich Schuhe aus weichem Material, die mit einem festen Körper kollidieren ( siehe Abbildung 2.4 ). Abbildung 2.4: Schuhe Kollidieren mit einem Starrkörper und verformen sich.[mm05] Cloth Cloth ( deutsch: Gewebe/Stoff ) ermöglicht die Simulation von Gegenständen, welche aus Stoff, bzw. Gewebe bestehen. Häufige Verwendung findet Cloth z.b. bei im Wind wehenden Fahnen oder bei virtuellen Charakteren, die Kleidung tragen, sowie bei der Simulation von Ketten oder Seilen. Es besteht zudem die Möglichkeit der Rissbildung bei den simulierten Objekten, sowie die Ausübung von Druck bei z.b. Ballons. Wie auch bei Soft Bodies, sind Deformationen möglich. Ebenso spielt eine effiziente Kollisionserkennung von deformierbaren Objekten eine Schlüsselrolle ( siehe Abbildung 2.5 ). Anwendungsmöglichkeiten sind unter anderem Beulen in Fässern oder Türen aus Metall, sowie Deformationen von Autoteilen

25 2.3. Software Abbildung 2.5: Anwendungsbeispiele für Cloth. Links: Tuch über einem Objekt.[MT05] Rechts: Rissbildung bei einem Teppich NVIDIA Fluids Zu Fluids ( deutsch: Strömungsmittel ) werden Flüssigkeiten, Feuer, Rauch, sowie Wolken u.ä. gezählt. Die Simulation dieser Strömungsmittel wird auf Basis von Partikelsystemen 24 durchgeführt. Hierbei sind auch Interaktionen mit Rigid Bodies, Cloth und Soft Bodies möglich. Beispiele für Anwendungsmöglichkeiten sind Simulationen von Wasser ( siehe Abbildung 2.6 ) und Wellengang, sowie Explosionen mit Rauch, Feuer und Trümmerteilen. Abbildung 2.6: Ein Glas wird mit Wasser gefüllt[mm03]. 2.3 Software Es folgt nun eine nähere Betrachtung von einzelnen Plug-ins, sowohl für die 3D Visualisierungssoftware 3ds Max, als auch für Maya. Es wird auf den Funktionsumfang der Software, sowie deren Unterschiede eingegangen. 24 Partikelsysteme werden in Kapitel 3 erläutert 13

26 2. Stand der Technik RayFire RayFire 25 wurde 2007 von Mir Vadim als Plug-in für 3ds Max 26 entwickelt. Unterstützt werden sowohl Havok 27, als auch PhysX. RayFire wird hauptsächlich zur Fragmentierung von Objekten und für Zerstörungen eingesetzt. Es sind diverse Möglichkeiten zur Zerstörung von Objekten vorhanden, wie z.b. ein integriertes Schusssystem, dynamische Explosionen allerart, sowie dieanbindungan externe Plug-ins wieafterburn 28 und FumeFX 29 zur Rauch und Feuer Simulation. Seit der Implementation des PhysX SDK und der damit einhergehenden Geschwindigkeitssteigerung wird RayFire immer öfter bei professionellen Projekten, in Computerspielen, sowie im Film- und Werbebereich eingesetzt. RayFire wird seit 3ds Max 9 von allen Versionen unterstützt, sowie regelmäßig aktualisiert und um neue Funktionen erweitert. Die aktuelle RayFire Version 1.5 ist seit Februar 2010 erhältlich und unterstützt das PhysX SDK 2.0. Eine Einzellizenz kostet 285$. Werden 3 oder mehr Lizenzen gleichzeitig erworben, erhält der Käufer einen Rabatt Blast Code Die Firma Blast Code Inc. 30 ist der Entwickler der Kiloton und Megaton Plug-ins für die 3D Visualisierungssoftware Maya 31. Beide Produkte enthalten gemeinsame Grundfunktionen, wie unter anderem die Fragmentierung von Oberflächen, virtuelle Sprengstoffe zur Deformation und Zerstörung von Objekten, sowie die Unterstützung der PhysX Engine zur Simulation von Starrkörper Berechnungen. Ebenfalls ist es mit Kiloton, sowie Megaton möglich, auf die in Maya vorhandenen Partikel Attribute zur Erstellung von Staub, Rauch und Feuer zuzugreifen. Die Unterschiede beider Produkte werden in den Folgenden Abschnitten erläutert. 14 Kiloton Blast Code Kiloton 32 ist eine stark eingeschränkte Variante von Megaton. Der Funktionsumfang beschränkt sich zusätzlich zu den Standard Funktionen auf die Fragmentierung und Zerstörung von NURBS 33 Oberflächen. Kiloton ermöglicht die Simulation von unterschiedlichen Materialien, wie z.b. Stein, Keramik, Glas, sowie Metall und Plastik. Hierbei fließt auch der Härtegrad der Materialien in die Simulation mit ein. Ein Objekt aus Glas bricht, sobald genügend Kraft ausgeübt wird. Hingegen kann sich ein Objekt aus Metall zuerst verbiegen, bevor es bricht Havok ist eine Physik Engine. Ursprünglich von der Firma Havok entwickelt, ist Havok mittlerweile in 3ds Max durch das Reactor Plug-in integriert Non Uniform Rational B-Splines. NURBS ist eine mathematische Methode um Kurven und Oberflächen zu beschreiben. Sie werden meist zur Darstellung von organischen und industriellen Objekten eingesetzt.

27 2.3. Software Megaton Blast Code Megaton 34 ist der große Bruder von Kiloton. Es enthält zusätzlich zu den Standard und Kiloton Funktionen die Möglichkeit Objekte aneinander haften zu lassen. Ein Beispiel dafür ist ein Gebäude aus Stein und Holz, sowie zusätzlichen Materialien, die bei der Zerstörung aneinander haften ( siehe Abbildung 2.7 ). Eine weitere Funktion ist die Generierung von zusätzlichen Teilen wie Rohre, Leitungen, Drähte ö.ä., die zu einem realistischerem Gesamteindruck bei einer Zerstörung beitragen. Abbildung 2.7: Holzteile und Teile der Außenwand des Gebäudes haften zusammen. Dadurch kann die Simulation glaubhafter wirken. Blast Code Demolition Software Die Blast Code Produkte wurden mehrfach bei großen Filmproduktionen eingesetzt, wie z.b. King Kong, Transformers oder Monsters Vs. Aliens 35. Kiloton, sowie Megaton sind für Maya ( 32 Bit ) Version 7 bis Version 2010 erhältlich. Eine Einzellizenz für Kiloton kostet 395$, sowie 1495$ für Megaton. Die aktuellen Kiloton und Megaton Versionen 1.6 sind im Januar 2008 veröffentlicht worden. Seitdem wurden ausschließlich Aktualisierungen für die Maya Versionen 2009 und 2010 veröffentlicht Particle Flow Particle Flow ist ein komplexes, nicht lineares, sowie Event ( deutsch: Ereignis ) basiertes Partikelsystem. Particle Flow wurde von Orbaz Technologies 36 im Auftrag von Autodesk 37 entwickelt und seit Juli 2003 mit 3ds Max 6 als integriertes Partikelsystem vertrieben. Die Anwendungsgebiete von Particle Flow sind die Simulation von Feuer, Rauch, Wolken, Schnee, Wasser, Gras, ö.ä. Particle Flow ist bedingt durch seine Integration in 3ds Max kostenlos. Es wird in unregelmäßigen Zeitabständen aktualisiert. Der Vollständigkeit halber sei an dieser Stelle der Preis für eine Einzellizenz von 3ds Max von 3495$ zu nennen. Erweiterungen

28 2. Stand der Technik für Particle Flow werden von Orbaz Technologies angeboten und im folgenden Abschnitt vorgestellt. Particle Flow Tools: Box 1,2,3 Particle Flow Tools: Box 1, 2 und 3 sind Sammlungen von zusätzlichen Funktionen, sowie Software Erweiterungen für Particle Flow. Sie wurden von Orbaz Technologies entwickelt, um die Möglichkeiten von Particle Flow zu erweitern und es für Entwickler von Spezialeffekten attraktiver zu gestalten 38. Particle Flow Tools: Box 1 39 enthält 14 zusätzlichefunktionen und erweitert das Grundprogramm in den Kategorien Painting, Groups und Utilities. Mit ihnen ist es z.b. möglich, durch bemalen einer bestimmten Stelle an einem Objekt Partikel nur von dort emittieren zu lassen. Auch die Manipulation von einzeln erstellten Partikelgruppen ist möglich. Die Particle Flow Tools: Box 1 ist seit 3ds Max 2010 fester Bestandteil von Particle Flow und somit in dem Preis von 3ds Max enthalten. Für Besitzer der älteren 3ds Max Version 2009, inklusive einem Abonnement, besteht jedoch die Möglichkeit der Installation der Creativity Extension 40, um Particle Flow Tools: Box 1 zu erhalten. Die Particle Flow Tools: Box 2 41 integriert die Unterstützung für NVIDIA PhysX und ermöglicht damit die physikalische Simulation zwischen Particle Flow Partikeln und Starrkörpern. Durch die PhysX Unterstützung kann Particle Flow auf alle Attribute und Funktionen des PhysX SDK zugreifen und sie mit Partikeln und Starrkörpern kombinieren. Möglich ist auch das Haften von Gegenständen, sowie das Hinzufügen von Reibungswiderstand zu Simulationsobjekten. Zusätzlich werden weitere Funktionen implementiert, mit denen unter anderem die Sichtbarkeit von Objektteilen durch Partikelaktivierung reguliert werden kann. Particle Flow Tools: Box 2 ist kompatibel mit 3ds Max ab Version 9 und wird auf jede neu erscheinende 3ds Max Version angepasst. Eine Einzellizenz kostet 595$. Wird zusätzlich zur Box 2 auch Particle Flow Tools: Box 3 erworben, erhält der Käufer einen Rabatt von 100$. Particle Flow Tools: Box 3 42 ermöglicht die Erstellung von in sich geschlossenen Systemen ( Black Boxes ), die wiederum als Operatoren in bestehende Systeme integriert werden können. Auch erarbeitete Ergebnisse, d.h. Systeme oder Teile von Systemen, können als so genannte Presets abgespeichert werden, um sie bei belieben wieder aufrufen zu können. Weiterhin stehen Cache Operatoren zur Verfügung. Bei komplexen Systemen können Teile der Simulation mit Hilfe der Cache Operatoren auf der Festplatte abgespeichert werden, wodurch sie nicht bei jedem Simulationsdurchlauf neu berechnet werden müssen. Somit wird die CPU entlastet, was wiederum zu einem Geschwindigkeitszuwachs führen kann. Particle Flow Tools: Box 3 wird seit 3ds Max 9 auf jede neu erscheinende Version angepasst. Eine

29 2.3. Software Einzellizenz kostet 495$. Wird wie oben beschrieben, zusätzlich Particle Flow Tools: Box 2 erworben, erhält der Käufer 100$ Rabatt Thinking Particles ThinkingParticles 43 isteinvon Cebas VisualTechnologies 44 entwickeltes Partikelsystem und wird als Plug-in für 3ds Max vertrieben. Anwendungsgebiete sind unter anderem die Generierung von Effekten, wie Feuer, Rauch, Wasser, sowie alle damit verbundenen Variationen, wie Explosionen, Schnee oder auch Regen. Auch NVIDIA s PhysX Engine wird unterstützt, sowie alle damit einhergehenden Funktionen, wie z.b. die Interaktion zwischen Partikeln und Starrkörpern. Thinking Particles enthält eine Vielzahl von Operatoren, um beispielsweise einzelne Simulationsschritte aufzuzeichnen und sie auf der Festplatte zwischenzuspeichern, um sie anschließend in Echtzeit abspielen zu können. Die abgespeicherten Simulationsschritte müssen nun bei den nächsten Simulationsdurchläufen nicht mehr mitberechnet werden, was sich positiv auf die Gesamtdauer der Simulation auswirkt. Auch können geschlossene Systeme als Black Box in neue Systeme 45 eingebunden werden. Diese Funktion kann dann nützlich sein, wenn z.b. eine System erstellt wurde, welches eine bestimmte Aktion ausführt, die sehr oft, auch in anderen Situationen gebraucht wird. So kann man dieses System als einzelnen Operator ( Black Box ) abspeichern und bei späterer Verwendung in andere Systeme integrieren. Ebenfalls können Morph Operatoren benutzt werden, wodurch ein Objekt die Form und das Aussehen eines anderen Objektes annehmen kann.thinking Particles wurde bei Die neueste Version 3 von Thinking Particles ist im März 2008 erschienen und ist mit jeder Version ab 3ds Max 6 kompatibel. Eine Einzellizenz kostet 1495$ Volume Breaker Volume Breaker ist ein Plug-in für 3ds Max zur Fragmentierung von 2D Oberflächen, sowie 3D Objekten. Volume Breaker wurde im Jahre 2009 von Cebas Visual Technologie, während der Produktion des Films , in Zusammenarbeit mit dem Film-Produktionsstudio Uncharted Territory 47 entwickelt. Volume Breaker ist speziell für die Fragmentierung von geometrischen Objekten ausgelegt. Die mit Volume Breaker generierten Objekt-Fragmente können anschließend in bestehende Partikel- oder Festkörper-Simulationen integriert werden. Die Dauer der Fragmentierung kann durch den Einsatz von Mehrkernprozessoren deutlich verringert werden. Volume Breaker wird zusammen mit scalpelmax 48, einem zusätzlichen 3ds Max Objekt Modifizierer vertrieben. scalpelmax bietet die Möglichkeit komplexe Modelle zur besseren Visualisierung zu zerschneiden, womit der Betrachter, z.b. bei einer Vorführung in das Innere Als System bezeichnet man den Simulationsaufbau von Partikelsystemen, in denen die gewünschten Effekte erzeugt werden

30 2. Stand der Technik des Modells sehen kann. Das besondere hierbei ist, dass durch das Zerschneiden alle Teile ihre Texturkoordinaten beibehalten, wodurch die Materialien und Texturen der Modellteile nicht beeinträchtigt werden. Volume Breaker und scalpelmax sind für 3ds Max 2008, 2009, sowie 2010 erhältlich. Eine Einzellizenz kostet 395$. 2.4 Taxonomie In den vorangegangenen Abschnitten wurde ein Überblick über die vorgestellten Programme, sowie deren Funktionsumfang gegeben. Es wurden sowohl Programme basierend auf Starrkörper Berechnungen, als auch Programme basierend auf Partikelsystemen vorgestellt. Um nun jeweils ein Programm aus beiden Kategorien auszuwählen und eine bessere Übersicht der vorhandenen Funktionen zu gewährleisten, folgt an dieser Stelle eine Einteilung der Programme nach verschiedenen Kategorien. Zuerst werden die Produkte nach ihrer Funktionsweise aufgeteilt. Hier existieren zwei unterschiedliche Ansätze. Zu dem ersten Ansatz werden Programme gezählt, welche Simulationen mit Rigid Bodies, also Starrkörpern, durchführen. Das Verhalten der Starrkörper wird dabei durch eine Physik-Engine simuliert. Als Starrkörper sind hierbei geometrische Körper anzusehen. Der zweite Ansatz beinhaltet Programme, welche auf Partikelsystemen basieren. Bei diesen Systemen wird das Verhalten von einzelnen Partikeln simuliert. Die Partikel können dabei die Gestalt von geometrischen Körpern annehmen, dabei jedoch immer noch wie Partikel gesteuert werden. Es ist ebenfalls möglich, das Verhalten dieser Partikel durch eine Physik-Engine zu simulieren. Nachdem die Einteilung nach Starrkörper basiert und Partikelsystem erfolgt ist, werden die durch die Programme unterstützten Physik Engines aufgezeigt. Es folgt das mit dem Produkt zu verwendende Software Paket, sowie abschließend der Preis der Produkte für Endkunden. Abbildung 2.8: Taxonomie der vorgestellten Programme 18

31 2.5. Zusammenfassung Fazit Nachdem mit der Taxonomie eine Einteilung der Produkte nach den oben genannten Kategorien durchgeführt, sowie die Funktionen der Produkte in jeweils einer Übersicht zusammengetragen wurde, kann nun eine Auswahl getroffen werden. Als auf Starrkörper Berechnungen basierendes Programm wird das RayFire Tool von Mir Vadim ausgewählt. Es bietet nur einen geringfügig kleineren Funktionsumfang als Blast Code Megaton und ist dabei für ein fünftel des Preises verfügbar. Zusätzlich unterstützt es beide Physik Engines und ist mit dem Softwarepaket 3ds Max lauffähig. Bei den Partikelsystemen wird Particle Flow mit der vorhandenen Particle Flow Tools: Box 2 verwendet. Im Gegensatz zu Thinking Particles ist Particle Flow in der Verkaufsversion von 3ds Max bereits enthalten. Es bietet grundsätzlich den gleichen Funktionsumfang. Jedoch fehlt hierbei die Unterstützung der PhysX Engine. Um dieses Problem zu umgehen, wird es mit Particle Flow Tools: Box 2 verwendet, welche die Integration der PhysX Engine sowie zusätzliche Erweiterungen des Funktionsumfangs mit sich bringt. Damit ist der Anschaffungspreis noch knapp ein drittel geringer, als Thinking Particles. 2.5 Zusammenfassung Dieses Kapitel lieferte einen Überblick über die zur Zeit existierende Hard- und Software, sowie deren Entstehungsgeschichte. Es wurde die Bedeutung von Mehrkernprozessoren und Grafikbeschleunigern und dessen immer stärkere Ausrichtung auf Parallelität aufgezeigt. Auch das GPGPU-Computing, die CUDA Architektur und ihre Entstehungsgeschichte sind erläutert worden. Zusätzlich wurden die Fähigkeiten und Simulationsarten der PhysX Engine beschrieben. Anschließend folgte eine Übersicht über eine Auswahl von auf dem Software Markt erhältlichen Plug-ins für die Visualisierungssoftware 3ds Max und Maya. Die Unterschiede der einzelnen Software Pakete wurde anschließend in einer Taxonomie dargestellt. Abschließend wurden die Produkte zur Gegenüberstellung ausgewählt. 19

32

33 Kapitel 3 Analyse der Software 3.1 Einleitung In dem Kapitel Stand der Technik wurde ein Überblick über die aktuelle Prozessor und Grafik Hardware, NVIDIA s CUDA Architektur, sowie der PhysX Engine gegeben. Anschließend wurde eine Reihe von Plug-ins zur Erstellung von visuellen Effekten in der 3D Visualisierung vorgestellt. Daraufhin folgte eine Taxonomie und abschließend eine Auswahl von zwei Plugins, welche nun folgend in diesem Kapitel analysiert werden. Dieses Kapitel wird die zuvor ausgewählten Programme, Mir Vadim s RayFire und Particle Flow inklusive Particle Flow Tools: Box 2, deren Aufbau, sowie deren Funktionsweise genauer betrachten und diesbezüglich analysieren. 3.2 RayFire RayFire wurde von Mir Vadim im Jahre 2007 als Plug-in für 3ds Max entwickelt. War zu Beginn ausschließlich ein integriertes Schusssystem vorhanden, hat sich der Funktionsumfang bis heute stark erweitert. Nun sind vielfältige Zerstörungen von Objekten aller Art möglich. Auch die Sprengung von z.b. Häusern mittels einer virtuellen Bombe ist möglich. Durch die Unterstützung von Reactor und vor allem PhysX können diese Simulationen nach physikalischen Grundsätzen realitätsnah durchgeführt werden. Um z.b. Trümmerteile zu erzeugen, stehen dem Benutzer verschiedene Verfahren zur Fragmentierung von Objekten zur Verfügung Aufbau In den folgenden Abschnitten wird der Aufbau des RayFire Tools beschrieben. Auf die für diese Diplomarbeit relevanten Teilbereiche des Programms wird detaillierter eingegangen. Die Grafische Benutzeroberfläche, auch GUI 1 genannt, ist als eigenes Fenster in 3ds Max implementiert. Der Aufruf des RayFire Tools in 3ds Max erfolgt über Command Panel 1 Graphical User Interface 21

34 3. Analyse der Software / Create / Geometry - RayFire Tool. Die GUI besteht aus sechs Hauptschaltflächen, sowie fünf Menüpunkten ( siehe Abbildung 3.1 ). Abbildung 3.1: Menüpunkte und Hauptschaltflächen des RayFire Tools. Die Aktionen der Menüpunkte Execution, Manager, Tools, Options und About sind größtenteils redundant. Fast alle Aktionen können auch über die Hauptschaltflächen in den einzelnen Unterkategorien durchgeführt werden. Über Execution können die einzelnen Simulationsschritte, wie z.b. die Fragmentierung eines Objektes oder die Simulation einer Schusssequenz ausgeführt werden. Mit dem Manager kann auf einzelne Funktionen der Layer Kategorie zugegriffen werden. So können einzelne Layer selektiert oder gelöscht werden. Unter Tools befinden sich unter anderem einige Werkzeuge, welche schon in 3ds Max vorhanden sind, aber oft im Arbeitsablauf mit RayFire benötigt werden. Diesbezüglich ist insbesondere die Attach Funktion zu erwähnen, welche zwei selektierte Objekte zu einem Objekt zusammenfügt. Dadurch lassen sich in kurzer Zeit kleine Änderungen nach z.b. der Erstellung von Trümmerteilen durchführen, ohne das Objekt erneut zu fragmentieren. Über Options kann auf das Custom Properties Fenster zugegriffen werden. Hiermit können Objekten eigenständige Eigenschaften zugewiesen werden. Die hauptsächliche Bedienung des RayFire Tools erfolgt über die sechs Hauptschaltflächen: Objects, Shooting, Physics, Reactor, Fragmentation und Layer. Um eine Interaktion mit einem oder mehreren Objekten durchzuführen, unabhängig davon welche Aktion stattfinden soll, müssen die Objekte der Simulation hinzugefügt werden. Dies findet in der Objects Kategorie statt ( siehe Abbildung 3.2 ). Abbildung 3.2: Die Schaltfläche Objects und ihre Unterkategorien. 22

35 3.2. RayFire Hier werden die zur Simulation hinzugefügten Objekte nach ihrer Einsatzmöglichkeit eingeordnet. Für jede Art von Objekt-Typ können zusätzliche Materialeigenschaften vergeben werden. Eine genauere Beschreibung folgt im Abschnitt Unter Shooting ist das integrierte Schusssystem implementiert ( siehe Abbildung 3.3 ). Das Schusssystem verfügt über die Generierung von Einschusslöchern, sowie die daraus entstehenden Trümmerteile, Schussprojektile und Mündungsfeuer. Ebenso kann Rauch, Funkenschlag oder auch Blut erzeugt werden. RayFire bietet für jede Option eine vorgegebene Einstellung an. Es besteht aber auch die Möglichkeit die Standardeinstellungen durch eigene zu ersetzen. Abbildung 3.3: Das Schusssystem mit allen Funktionen. Über Physics ( siehe Abbildung 3.4 ) werden die Physik Simulationen konfiguriert, gestartet und gestoppt. Es kann zwischen der Reactor und PhysX Engine gewählt werden. Zusätzlich stehen zwei weitere Kategorien zur Verfügung, mit denen PhysX Simulationen konfiguriert werden können. So können z.b. weitere Kräfte wie Wind oder Gravitation, sowie eine virtuelle Bombe eingebunden werden, die dadurch bei einer Simulation auf die restlichen Objekte einwirken können. 23

36 3. Analyse der Software Abbildung 3.4: Unter Physics wird die zu verwendete Engine gewählt, sowie Simulationen gestartet. Über die Reactor Schaltfläche ( siehe Abbildung 3.5 ) kann der Benutzer, ähnlich wie bei Physics, eine virtuelle Bombe einfügen und konfigurieren. Ebenso ist eine Zerstörung von Objekten möglich, jedoch in sehr begrenztem Umfang mit weniger Konfigurationsmöglichkeiten, als es mit der PhysX Engine möglich ist. Abbildung 3.5: Reactor verfügt nur über eingeschränkte Konfigurationsmöglichkeiten. In der Kategorie Fragmentation ( siehe Abbildung 3.6) können Objekte fragmentiert werden. Es stehen dazu verschiedene Algorithmen, sowie Fragmentierungs-Typen zur Verfügung. Des weiteren können auch Texturen zur Fragmentierung eingebunden oder eigene Umrisse gezeichnet werden, nach denen eine Fragmentierung stattfindet. Abbildung 3.6: Eine Übersicht der Fragmentierungsmöglichkeiten. 24

37 3.2. RayFire Über Layers ( siehe Abbildung 3.20 ) werden die Simulationsschritte verwaltet. Es können hier einzelne z.b. Fragmentierungsschritte Rückgängig gemacht werden. Ebenfalls können Presets abgespeichert, sowie geladen werden. Abbildung 3.7: Hier werden alle vorhandenen Layer verwaltet Funktionsweise Nachdem ein kurzer Überblick über den Aufbau von RayFire und dessen Möglichkeiten gegeben wurde, folgt nun eine detailliertere Analyse der Funktionsweise des RayFire Tool. Es werden die für diese Diplomarbeit relevanten Teilbereiche Objects, Physics, Fragmentation und Layer ausführlicher behandelt. Für die nicht relevanten Teilbereiche Shooting und Reactor soll die Übersicht aus Abschnitt ausreichen. Objects Um eine Aktion über das RayFire Tool auszuführen, sei es das initiieren eines Simulationsdurchlaufs oder die Fragmentierung eines Objekts, muss immer mit der Zuordnung der Objekte in die Objects Kategorie begonnen werden. RayFire unterscheidet hierbei drei verschiedene Objekt-Typen: Impact Objects Unyielding Objects Inactive Objects Impact Objects sind geometrische Objekte, welche simuliert, fragmentiert oder zerstört werden können. Die Objekte können nicht nur statisch sein, sondern auch animiert werden. Bei einer Simulation mit z.b. PhysX wird die Geschwindigkeit des Objekts übergeben und von der Physik Engine weitergeführt. Unyielding Objects sind unnachgiebige Objekte. Sie können durch andere Objekte weder zerstört, noch verformt werden. Oft wird der Untergrund, auf dem eine Interaktion zwischen Objekten stattfindet, als Unyielding Object festgelegt. Er dient bei einer Simulation als Kollisionsobjekt, seine Form bleibt jedoch bestehen. 25

38 3. Analyse der Software Inactive Objects sind inaktive Objekte. Sie bleiben von der eigentlichen Simulation unberührt, bis sie aktiviert werden. Dies kann entweder durch die Kollision mit einem Impact Object oder durch die Einwirkung eines 3ds Max Kraftfeldes wie z.b. Gravitation oder Wind stattfinden. Abbildung 3.8: Links: Impact Objects und deren Eigenschaften. Mitte: Unyielding Objects. Rechts: Inactive Objects. 26 Soll eine Fragmentierung eines Objekts durchgeführt werden, kann dieses grundsätzlich immer als Impact Object deklariert werden. Die Objekt-Typen Unyielding Objects und Inactive Objects sind ausschließlich bei Simulationen mit PhysX relevant. Hierbei ist zu beachten, welche Rolle das jeweilige Objekt in der Simulation einnimmt. Wände oder Böden, die in einer Simulation als reine Deflektoren, bzw. Kollisionsobjekte verwendet werden, ohne beschädigt oder zerstört zu werden, sind klassische Beispiele für Unyielding Objects. Ebenso ist es möglich die unzerstörbare Eigenschaft von Unyielding Objects gezielt in einer Simulation einzusetzen. Da auch animierte Objekte unterstützt werden, kann so z.b. ein animiertes Unyielding Object andere Objekte zerstören, ohne dabei selbst in Mitleidenschaft gezogen zu werden. Bei allen drei Objekt-Typen können für die eingefügten Objekte spezifische Materialeigenschaften wie Masse, Reibung und Elastizität festgelegt werden. Dabei besteht die Möglichkeit auf vordefinierte Materialien zurückzugreifen. Die Auswahl reicht von sehr harten Materialien wie schweren und leichten Metallen, über verschiedene Arten von Steinen, bis hin zu leicht brechenden Materialien wie Holz, Glas oder Eis. Die Reibung, sowie die Elastizität verändern sich mit den ausgewählten Materialien, können jedoch auch frei angepasst werden. Die Masse der Objekte kann über die Dichte der gewählten Materialien automatisch festgelegt, oder über Wertebereiche gewählt werden. Wird ein Wertebereich festgelegt, besteht die Möglichkeit die Masse entweder durch Zufall oder nach Objekt-Volumen auf die vorhandenen Objekte zur verteilen. Wie auf Abbildung 3.8 zu sehen, ist Simulation geometry auf den Wert Automatic festge-

39 3.2. RayFire legt. Dieser Umstand ist auf die Benutzung der PhysX Engine zurückzuführen. Wie schon in Abschnitt erwähnt, nutzt die PhysX Engine bei der Simulation von Objekten nicht deren eigentliche, komplexe Geometrie, sondern ersetzt diese durch geometrische Primitive. Da die PhysX Engine bis zu dem jetzigen Zeitpunkt keine Unterstützung für dynamische konkave Geometrie unterstützt, können nur statische konkave Objekte korrekt simuliert werden. Sobald, sich in Bewegung befindliche, konkave Objekte simuliert werden, berechnet PhysX die Kollision solcher Objekte mit einer konvexen Hülle. Die Benutzung konkaver Objekte ist somit gewährleistet, wirkt sich jedoch negativ auf die Genauigkeit der Simulation aus. Die verschiedenen Materialeigenschaften wirken sich je nach Art der Simulation deutlich auf das Verhalten der Objekte aus. Mit den in Abbildung 3.8 dargestellten Optionen ist es jedoch nur möglich, ein Material für alle Objekte auszuwählen, welche sich in den entsprechenden Objektkategorien befinden. Sollen zwei Objekte, die z.b. beide als Impact Objects deklariert sind, unterschiedliche Materialeigenschaften erhalten, muss auf die Custom Properties zurückgegriffen werden ( siehe Abbildung 3.9 ). Damit ist es möglich für jedes einzelne Objekt spezifische Eigenschaften zu vergeben. Dabei können nicht nur Materialeigenschaften vergeben werden. Es stehen auch verschiedene Optionen zur Fragmentierung zur Verfügung. Auf die zusätzlich existierenden Funktionen unter Demolition Properties wird in Abschnitt näher eingegangen. Abbildung 3.9: Für jedes Objekt können spezifische Eigenschaften vergeben werden. Fragmentation Für die Fragmentierung von Objekten bietet das RayFire Tool mehrere Fragmentierungs- Typen, sowie Konfigurationsmöglichkeiten an. Folgende Fragmentierungs-Typen stehen zur Auswahl: Uniform Irregular Relative to Bomb/Impact Relative to Mouse 27

40 3. Analyse der Software Relative to Pivot Continuous Voronoi - Uniform Voronoi - Bomb/Impact Voronoi - Particle System Wood Splinters over Z axis Wie in Abbildung 3.10 zu sehen, bestimmen die unterschiedlichen Fragmentierungs-Typen die Form, sowie die Position der Objektfragmente. Bei der Uniform Variante besitzen die Fragmente ungefähr die gleiche Größe und sind gleichmäßig über die Fläche des ursprünglichen Objekts verteilt. Durch die Irregular Variante wird das Objekt in ungleichmäßig große Fragmente aufgeteilt. Die Position der Fragmente ist ebenfalls uneinheitlich. Mit der Relative to Bomb/Impact Methode wird das Objekt relativ zur Einschlagstelle eines Kollisionsobjektes oder einer virtuellen Bombe fragmentiert. Das bedeutet, je kleiner die Entfernung zur Einschlagstelle, desto mehr und gleichzeitig kleinere Fragmente sind vorhanden. Abbildung 3.10: Drei verschiedene Fragmentierungs-Typen. Links: Uniform. Mitte: Irregular. Rechts: Relative to Bomb/Impact. Mir Vadim 28 Nach dem gleichen Prinzip verhalten sich auch Relative to Mouse, sowie Relative to Pivot. Über Relative to Mouse besteht die Möglichkeit die zu fragmentierende Stelle in Echtzeit während der Fragmentierung mit der Maus zu bestimmen ( siehe Abbildung 3.11 ). Je länger sich der Maus Cursor an einer Stelle des Objektes befindet, desto höher ist die Anzahl und geringer die Größe der entstehenden Fragmente. Falls der Maus Cursor von dem Objekt wegbewegt wird, wird die Fragmentierung mit der Uniform Methode fortgesetzt. Bei Relative to Pivot wird relativ zu dem Pivot Punkt des Objektes fragmentiert. Auch hier entstehen kleinere Fragmente, je geringer die Entfernung zum Pivot Punkt ist.

41 3.2. RayFire Abbildung 3.11: Links: Relative to Mouse. Mitte: Continuous. Rechts: Voronoi. Mir Vadim Die Continuous Methode ist speziell für die Fragmentierung von Glas z.b. in Fenstern oder auch für Eis gedacht. Die Form der Fragmente ist dementsprechend angepasst. Die folgenden drei Fragmentierungs-Typen Voronoi - Uniform, Voronoi - Bomb/Impact und Voronoi - Particle System basieren auf dem Voronoi Diagramm, einer mathematischen Methode, um einen mehrdimensionalen Raum in eine bestimmte Anzahl von Regionen zu unterteilen. Durch Voronoi - Uniform entstehen ungefähr gleich große Fragmente mit gleichmäßiger Verteilung. Die Voronoi Bomb/Impact Methode erzeugt Fragmente relativ zum Einschlagspunkt eines Kollisionsobjektes oder zur einer virtuellen Bombe. Die Fragmente sind auch hier in direkter Nähe des Einschlagpunktes oder der virtuellen Bombe kleiner und werden nach außen hin größer und somit weniger. Mit der Voronoi - Particle System Methode können durch eine Anbindung an z.b. Particle Flow Partikel an die jeweils zu fragmentierenden Stellen eines Objektes platziert werden. Je nach Position der Partikel erfolgt dann die Fragmentierung. Der letzte Fragmentierungs-Typ Wood Splinters over Z axis ist für die Fragmentierung für splitterndes Holz, wie z.b. Latten oder auch Bretter vorgesehen. Wurde schließlich ein Fragmentierungs-Typ gewählt, können zusätzliche Konfigurationsmöglichkeiten vorgenommen werden. Dabei handelt es sich um Iterations, Chaos, Detailization, sowie Noise. Der Iterations Wert regelt die Fragmentierungsdurchläufe bei einem Objekt. Je höher der Wert, desto mehr Fragmente entstehen. Chaos definiert den Winkel der Fragmentecken. Je niedriger der Wert, desto rechteckiger der Winkel und demzufolge auch die Fragmente. Über Detailization kann die Oberflächenstruktur der Fragmente bestimmt werden ( siehe Abbildung 3.12 ). Mit steigendem Detailization Wert steigt auch die Komplexität des fragmentierten Objektes. Dies wirkt sich negativ auf die Dauer der Fragmentierung aus. Der Noise Wert regelt die Verzerrung der Objektoberfläche. Je niedriger der Wert, desto flacher und gleichmäßiger ist die Oberfläche des Objektes. Je höher der Wert, desto ungleichmäßiger die Oberfläche. 29

42 3. Analyse der Software Abbildung 3.12: Ein höherer Wert ist gleichbedeutend mit einer komplexeren Objektstruktur. Links: Detailization. Rechts: Noise. Mir Vadim Neben den Fragmentierungsmöglichkeiten über Custom Properties ( siehe Abbildung 3.9 ) bietet RayFire weitere Optionen zur Fragmentierung von Objekten. Unter der Fragmentation Schaltfläche ist unter anderem ein zweiter Iterations Wert zu finden. Dieser kann benutzt werden, um eine Variation in die Anzahl der Objektfragmente zu bringen. Durch die Fragmentierung eines Objektes entstehen neue Objektfragmente. Eine dem Objekt zugewiesene Textur ist somit nur noch auf den Außenseiten des ursprünglichen Objektes vorhanden. Die neu entstandenen Innenseiten der Objektfragmente haben dementsprechend keine Textur. Jedoch ist die manuelle Zuweisung von Texturen nur sehr umständlich und zeitaufwändig durch die in 3ds Max vorhandenen Möglichkeiten durchzuführen. Für dieses Problem bietet RayFire die Möglichkeit den entstehenden Fragmenten vor der Fragmentierung ein Material zuzuweisen ( siehe Abbildung 3.13 ). Die Materialien können entweder über den 3ds Max Materialeditor oder durch die Pick Option zugewiesen werden. Hierbei kann ein Objekt in der Szene angeklickt werden, woraufhin das dem Objekt zugewiesene Material übernommen wird. Abbildung 3.13: Die verfügbaren Optionen der Fragmentierung des RayFire Tools. 30 Die Fragmentierung des RayFire Tools kann auch über eine selbst gezeichnete Struktur, bzw. Form durchgeführt werden. Dafür steht die Option Draw Fragment zur Verfügung. Über Draw Fragments kann ein Objekt mittels der Maus beliebig durchschnitten werden. Dafür stehen Optionen wie Step Size, Segments, sowie Noise zur Verfügung. Mit Step Size wird die Länge eines Schrittes festgelegt. Je höher der Wert, desto länger ist eine Schnitt-

43 3.2. RayFire kante des Fragments. Segments definiert die Anzahl der Unterteilungen einer Schnittkante. Umso höher der Wert, desto detaillierter wird die Schnittkante modelliert. Noise bestimmt die Verzerrung der Schnittkantenoberfläche. Geht der Wert gegen null, wird die Oberfläche flacher. Ebenfalls ist eine Fragmentierung durch eine vordefinierte Struktur möglich. Hierbei können Bilddateien geladen werden, die anschließend von RayFire in eine Fragmentierungs-Struktur umgewandelt werden. Dabei ist darauf zu achten, dass die Bilddatei möglichst schwarz/weiß ist, sowie einen guten Kontrast aufweist. Ansonsten können Fehler während der Umwandlung nicht ausgeschlossen werden. RayFire bietet unterschiedliche Möglichkeiten, um ein Objekt zu fragmentieren. Ein Objekt kann z.b. als Impact Object deklariert und anschließend manuell fragmentiert werden. Eine andere Möglichkeit ist die Fragmentierung nach einer Kollision mit anderen Objekten. Die Fragmentierung erfolgt dabei automatisch direkt bei der Kollision. Das RayFire Tool benutzt dazu die Konfiguration der Fragmentation Options ( siehe Abbildung 3.13 ). Sollte das Kollisionsobjekt über Custom Properties verfügen, werden diese Einstellungen für die Berechnung der Fragmentierung verwendet. Bei der Fragmentierung nach einer Kollision können jedoch nur die eben erwähnten Einstellungen mit in die Berechnung einbezogen werden. Die Fragmentation by Shapes, sowie Draw Fragment Optionen können in diesem Fall nicht angewendet werden. Ein weiterer Nachteil dieser Variante ist, dass die Simulation wiederholt werden muss, falls das Ergebnis der Fragmentierung nicht zufriedenstellend verlaufen ist. Je nach Komplexität und Umfang der Simulation ist daher ein höherer Zeitaufwand unvermeidlich. Generell ist noch zu beachten, dass das RayFire Tool vor dem starten der Fragmentierung das zu fragmentierenden Objekt ausblendet und von ihm eine Kopie erstellt. Diese Kopie wird anschließend fragmentiert und ist im Gegensatz zu den entstehenden Fragmenten nicht mehr existent. Physics Die Option, die eine Fragmentierung bei einer Kollision von Objekten ermöglicht, befindet sich innerhalb der Physics Kategorie. Hier befinden sich auch alle PhysX Funktionen, sowie die Steuerungselemente für physikalische Simulationen, eines der Hauptbestandteile des RayFire Tools. Allgemein besteht Physics aus folgenden Unterkategorien: Physical Options PhysX Simulation Properties PhysX Demolition Properties Die Steuerungselemente für Simulationen befinden sich unter den Physical Options. Hier kann auch die zu verwendende Physik Engine ( PhysX oder Reactor ) gewählt werden. Jedoch stehen die Unterkategorien PhysX Simulation Properties, sowie PhysX Demolition Properties nur zu Verfügung, wenn als Physik Engine PhysX gewählt wird. Wie in Abbildung 3.14 zu sehen, existieren noch weitere Konfigurationsmöglichkeiten. 31

44 3. Analyse der Software Abbildung 3.14: Hier sind die Steuerungselemente, sowie weitere Konfigurationsmöglichkeiten für eine Simulation zu sehen. 32 So kann über Start frame der Startzeitpunkt, sowie über Time range die Dauer der Simulation festgelegt werden. So kann die Simulation über das RayFire Tool dynamisch gesteuert werden und kann zu einem beliebigen Zeitpunkt einer Animation gestartet und auch wieder beendet werden. Collision tolerance beschreibt die Genauigkeit mit der Kollisionen zwischen Objekten von der PhysX Engine berechnet werden.umso kleiner der Wert, desto höher die Genauigkeit. Wird der Wert zu sehr erhöht, könnten sich die kollidierenden Objekte gegenseitig durchdringen. Die Anzahl der Simulationszwischenschritte wird über Substeps festgelegt. Falls die Geschwindigkeit eines Objektes zwischen zwei Frames zu hoch ist, kann es ebenfalls zu sich gegenseitig durchdringenden Objekten kommen. In diesem Fall kann der Substeps Wert erhöht werden. Gravity ist als Multiplikator für den durch die PhysX Engine verwendete Gravitations-Wert anzusehen. Demzufolge resultiert ein Gravity-Wert unter eins für eine geringere, sowie ein Wert über eins, für eine höhere Schwerkraft. Mit der Time Scale Option kann ein so genannter Zeitlupen Effekt erzeugt werden.eine Verringerung des Time Scale Wertes verlangsamt die Simulation, eine Erhöhung lässt die Simulation schneller ablaufen. Dies wird durch eine Manipulation der zu verwendeten Frameanzahl erreicht. Soll also die Simulation langsamer ablaufen, werden mehr Frames genutzt, als das normaler Weise der Fall wäre. Wird die Move timeslider during simulation Option nicht aktiviert, bewegt sich der 3ds Max Zeit-Schieberegler während der Simulation nicht mit und deaktiviert somit das durch Time range festgelegte Ende der Simulation. Diese Option ist nur zu Testzwecken sinnvoll, da die Ergebnisse während einer Simulation nicht gespeichert werden können. Simulate by dragging timeslider erlaubt, die Simulation durch bewegen des Zeit-Schiebereglers zu bedienen.

45 3.2. RayFire Hierdurch kann Frame für Frame durchlaufen werden. Dabei kann die Dauer der Simulation selbst bestimmt werden. Start simulation from timeslider startet die Simulation an der Stelle, an der sich der Zeit-Schieberegler gerade befindet und ist somit als Alternative zu Start frame anzusehen. Zur eigentlichen Steuerung der Simulation, stehen vier Schaltflächen zur Verfügung ( siehe Abbildung 3.14 ). [1] stellt hierbei den Preview Modus dar. Nachdem die eingestellte Zeitspanne abgelaufen ist, wird die Simulation erneut gestartet. Während dieser Modus aktiv ist, können Optionen wie z.b. Gravitation oder Time scale in Echtzeit verändert werden. Wenn alle Konfigurationen getätigt sind, kann mit [2] die eigentliche Simulation gestartet werden. Der Unterschied zu [1] besteht darin, dass die Positionsdaten der einzelnen Objekte für jedes Frame abgespeichert werden. Man nennt diesen Vorgang auch Bakeing. Mit [3] kann die Simulation zu jeder Zeit pausiert, sowie fortgesetzt werden. Mit [4] wird die Simulation gestoppt. [1], [2] und [3] verfügen jeweils über eine ON, sowie OFF Funktion. Dabei sind mehrere Faktoren zu beachten. Der Preview Modus [1] sollte immer mit der OFF Funktion beendet werden, da die simulierten Objekte dadurch wieder in ihre Ausgangsposition zurückversetzt werden. Wird anstelle der OFF Funktion, die Stop Taste [4] betätigt, verharren die Objekte in der Position zum Zeitpunkt der Betätigung und müssen manuell in die gewünschte Ausgangsposition verschoben werden. Bei [2] werden die Positionsdaten der simulierten Objekte nur abgespeichert, wenn die Simulation durch die Stop Taste [4] beendet wurde. Wird die OFF Funktion verwendet, wird die Simulation abgebrochen und die Objekte werden in ihre Ausgangsposition zurückversetzt. PhysX Simulation Properties beinhaltet weitere Konfigurationsmöglichkeiten für eine Simulation mit der PhysX Engine( siehe Abbildung 3.15). Für eine noch dynamischere Simulation mit Objekten unterstützt die Physx Engine die in 3ds Max integrierten Kraftfelder wie Gravity, Wind oder auch Drag, sowie virtuelle Bomben und geometrische Objekte. Diese können der Simulation hinzugefügt werden, um zusätzliche Eigenschaften in eine Simulation miteinzubeziehen, sowie mit anderen Objekten in verschiedener Art und Weise zu interagieren. Abbildung 3.15: Hier können Objekte, Kraftfelder und virtuelle Bomben hinzugefügt werden. Über zusätzliche Optionen werden diese zur Aktivierung von Objekten genutzt. Links: Force options. Rechts: Activation options. 33

46 3. Analyse der Software Um die Stärke der zur Simulation hinzugefügten Kraftfelder zu manipulieren, steht ein Multiplikator Strength multiplier zur Verfügung. Dieser Wert wird mit dem über 3ds Max eingestellten Wert für die jeweilige Kraft multipliziert. Für eine noch realistischere Verhaltensweise kann Strength by mass aktiviert werden. Die Kraftfelder beziehen bei ihrer Wirkungsweise in Bezug auf die Objekte deren Masse mit ein. Mit Affect on Inactive objects wirken die Kraftfelder nicht nur auf als Impact Objects deklarierte Objekte, sondern auch auf inaktive Objekte. Dies stellt eine weitere Möglichkeit der Aktivierung von inaktiven Objekten dar. Bevor auf weitere Aktivierungsmöglichkeiten eingegangen wird, folgt an dieser Stelle eine kurze Erläuterung der Konfigurationsmöglichkeiten einer virtuellen Bombe. Eine virtuelle Bombe kann über Create / Helpers / RayFire Tool / RF Bomb erstellt werden. Es stehen hierbei eine Reihe von Konfigurationsmöglichkeiten zur Verfügung ( siehe Abbildung 3.16 ). Die virtuelle Bombe unterstützt drei verschiedene Varianten, nach denen sich die Explosion ausbreitet. Spherical steht für eine sphärische Ausbreitung, Planar für eine flache, sowie Cylindrical für eine Zylinder förmige Ausbreitung. Über Frame wird die Start Zeit, bzw. der Frame ausgewählt, an dem die Wirkung der virtuellen Bombe einsetzen soll. Strength definiert die Stärke der Explosion. Mit Chaos kann eine zufällige Variation in das Verhalten der Explosion hinzugefügt werden. Spin legt die Rotationsgeschwindigkeit pro Sekunde für die Objekte fest, welche von der Explosion betroffen sind. Über Range wird die Reichweite der Explosion definiert. Der Wert 0 bedeutet in diesem Fall eine unendliche Reichweite. Die aktuelle Reichweite der virtuellen Bombe kann unter dem Menüpunkt Options des RayFire Tools über die Option Show bombs range eingeblendet werden. Mit Angle kann der Öffnungswinkel bestimmt werden, in dem sich die Explosion ausbreitet. Wird die Shockwave aktiviert, breitet sich die Explosion wie eine Schockwelle aus. Das bedeutet, die Objekte werden nicht alle gleichzeitig der Wirkung der Explosion ausgesetzt, sondern ein Objekt nach dem anderen wird von der Schockwelle erfasst. Je höher der Wert gewählt wird, desto schneller ist die Ausbreitung der Schockwelle. Wird der Wert 0 gewählt, ist die Option deaktiviert. Abbildung 3.16: Die virtuelle Bombe und ihre Konfigurationsmöglichkeiten. 34

47 3.2. RayFire Es stehen noch weitere Aktivierungsmöglichkeiten unter PhysX Simulation Properties zur Verfügung. Mit den Optionen Deactivate static Impact objects, sowie Deactivate animated Impact objects können jeweils statische oder animierte Impact Objects deaktiviert werden. Während sie deaktiviert sind, verhalten sie sich wie Unyielding Objects, d.h. sie können durch andere Objekte weder zerstört, noch verdrängt werden. Diese Option ist ebenfalls unter Custom Properties über Deactivated Impact verfügbar ( siehe Abbildung 3.9 ). Wird diese Option aktiviert erkennt RayFire automatisch, ob es sich bei dem Objekt um ein statisches oder eine animiertes Impact Object handelt. Durch die Deaktivierung besteht die Möglichkeit die Objekte unabhängig voneinander zu einem späteren Zeitpunkt während der Simulation durch verschiedene Methoden zu aktivieren. Dafür stehen folgende Methoden für eine Aktivierung zur Auswahl: Activate by Force Activate by Geometry Activate by Mouse Activate by Texture Mit Activate by Force können die Objekte durch eine Kraft aktiviert werden. Diese Kraft kann entweder ein Kraftfeld, wie Wind oder eine virtuelle Bombe sein. Über Activate by Geometry werden die als Impact Objects deklarierten Objekte von anderen geometrischen Objekten aktiviert. Bei Activate by Mouse besteht die Möglichkeit die Aktivierung der Objekte mit der Maus+SHIFT Taste durchzuführen. Diese Aktivierung kann interaktiv während einer Simulation durchgeführt werden. Ebenfalls wird die Aktivierung durch eine Textur mit Activate by Texture unterstützt. Hierbei wird eine schwarz/weiß Textur benötigt, welche animiert werden muss. Dafür wird ein Material erstellt und die entsprechende animierte Textur in den Diffuse Channel gelegt. Anschließend wird das Material allen zu aktivierenden Objekten zugewiesen. Sobald die Simulation gestartet wurde und die Textur von schwarz nach weiß gewechselt ist, werden die Objekte aktiviert. Zusätzlich stehen eine Reihe weiterer Optionen zur Verfügung ( siehe Abbildung 3.17 ). Falls gruppierte Objekte einer Simulation hinzugefügt werden, bietet PhysX über die Option Treat Group as zwei unterschiedliche Möglichkeiten an, das Verhalten der Objekte zu simulieren. Es kann hierbei zwischen One concave object und A group of objects gewählt werden. Bei One concave object werden alle Objekte in der hinzugefügten Gruppe als ein konkaves Objekt betrachtet. Bei Verwendung dieser Methode ist es jedoch nicht möglich die Glue objects in groups Option zu benutzen ( siehe Abbildung ). Wird die A group of objects Methode angewandt, werden alle Objekte der Gruppe als einzelne Objekte angesehen und auch berechnet. Jedoch ist es hierbei nicht möglich die Demolish groups Option zu nutzen. Auf die Abhängigkeiten beider Methoden mit den oben beschriebenen Option wird in den nächsten zwei Abschnitten nochmals eingegangen. ÜberStick to mouse kann das Verhalten der Objekte in Echtzeit während der Simulation beeinflusst werden. Wird ein Objekt markiert, bewegt es sich in Richtung des Maus Cursors. Je höher der Wert, desto stärker ist der Drang des Objektes die Position des Maus Cursors zu erreichen. Das Drücken der SHIFT 35

48 3. Analyse der Software Abbildung 3.17: Weitere Konfigurationsmöglichkeiten für eine Simulation mit PhysX. Taste während der Simulation deaktiviert die Stick to mouse Option. Collision damping bewirkt eine Dämpfung im Verhalten von Kollisionsobjekten. Umso höher der Wert ist, desto stärker wird die Bewegungsgeschwindigkeit von kollidierenden Objekten verringert. Wie in Abschnitt bereits erwähnt, wird die Bewegungsgeschwindigkeit von animierten Objekten bei einer Simulation an PhysX übergeben und weitergeführt. Der Motion inheritance Wert liefert für diesen Fall einen zusätzlichen Multiplikator für die Geschwindigkeit von Objekten.Mit Max linear velocity und Max angular velocity kann die maximale Bewegungsgeschwindigkeit, sowie die maximale Rotationsgeschwindigkeit eines Objektes zwischen zwei Frames festgelegt werden. Der Wert 0 bei Max linear velocity ist gleichbedeutend mit keiner Begrenzung. Die letzte Unterkategorie von Physics ist PhysX Demolition Properties. Hier sind Einstellungen speziell zur interaktiven Zerstörung von Objekten zu finden ( siehe Interactive Demolition options in Abbildung 3.18 ). Ebenfalls existieren Glue options, sowie Glue breaking options ( siehe Abbildung 3.19 ). Mit diesen Optionen ist ein Zusammenkleben, sowie Zerbrechen von den, durch die Zerstörung entstandenen, Objektfragmenten möglich. Abbildung 3.18: Weitere Konfigurationsmöglichkeiten für eine Simulation mit PhysX. 36

49 3.2. RayFire Wie schon in Abschnitt erwähnt, ist die manuelle Fragmentierung von Objekten nicht die einzige Möglichkeit, die das RayFire Tool bietet. Ebenfalls können Objekte erst bei ihrer Kollision mit anderen Objekten fragmentiert werden. Dies ist durch die Interactive Demolition options möglich. Hier kann die Option Demolish geometry aktiviert werden. Diese Option ist Grundvoraussetzung für eine Fragmentierung von Objekten bei ihrer Kollision. Jedoch hängt die Art und Weise ob und vorallem wie ein Objekt fragmentiert wird von weiteren Konfigurationsmöglichkeiten ab. Zum einen ist eine Zerstörung über diese Optionen nur möglich, wenn das Steuerungselement [2] ( siehe Abbildung 3.14 ) zum starten des Simulationsvorganges betätigt wird. Das bedeutet, dass bei einem Simulationsvorgang die Positionsdaten aller Objekte für jedes Frame abgespeichert werden. Hierbei ist noch zu beachten, dass das RayFire Tool, wie auch bei einer Fragmentierung ( siehe Abschnitt ), vor dem starten des Simulationsvorganges alle zu simulierenden Objekte ausblendet und davon jeweils eine Kopie erstellt. Der komplette Simulationsvorgang wird somit mit den Kopien und nicht mit den originalen Objekten durchgeführt.zum anderen ist die Zerstörung der Objekte abhängig von deren zugewiesenen Materialien. Wenn beispielsweise ein Objekt mit einem harten Stein Material auf ein Objekt mit Glas Material trifft, wird das Objekt aus Glas zerstört. Zu beachten ist auch, dass Objekte mit zugewiesenen Metall Material nicht zerstört werden können. Eine Möglichkeit die härte von Materialien zu manipulieren und damit z.b. zu erreichen, dass bei oben beschriebenem Beispiel das Glas Objekt und das Stein Objekt gegenseitig zerstören, ist die Material solidity Option. Diese Option steht als Multiplikator für die Härte der Materialien. Wird er kleiner als 1, verringert sich damit der Härtegrad aller Materialien und eine Zerstörung wie oben beschrieben wird möglich. Wenn diese Option nur auf ein bestimmtes Objekt angewendet werden soll, stehen hierfür die schon in Abbildung 3.9 dargestellten Custom Properties zur Verfügung. Ebenfalls in beiden Kategorien vorhanden, ist die Option Depth level ( siehe Abbildung 3.9 und 3.18 ). Hierüber kann die Anzahl der Zerstörungsdurchläufe gesteuert werden. Bei einem Wert von 1 wird das zerstörte Objekt einmal fragmentiert. Bei einem Wert von 2 werden die nach der ersten Fragmentierung entstandenen Objektfragmente jeweils ein weitere Mal fragmentiert. Dabei werden die eingestellten Fragmentierungsparameter an die mit jedem Durchgang neu entstehenden Objektfragmente weitergegeben. Für diese Option ist ein Maximalwert von 100 festgelegt. Jedoch führt schon ein Wert von 3 zu einem erheblichen Anstieg der Simulationsdauer. Um den Vererbungsvorgang der Fragmentierungsparameter besser regulieren zu können, kann die Depth ratio Option benutzt werden. Dieser Wert bestimmt den Anteil der weitergegebenen Fragmentierungsiterationen. Wurde beispielsweise vor der ersten Fragmentierung ein Iterationswert von 100 eingestellt ( d.h. 100 Objektfragmente ), werden bei einem Depth ratio Wert von 0,5 die neu entstandenen Objektfragmente jeweils nur noch 50 mal fragmentiert. Die minimale Größe eines zu zerstörenden Objektes kann über Minimal size limit konfiguriert werden. Das Objekt wird nicht zerstört, falls die Distanz zwischen den am weitesten auseinander liegenden Eckpunkten des Objektes kleiner ist, als das eingestellte Minimal size limit. Die Demolish by bomb Option ist zur Zerstörung von Objekten mittels einer virtuellen Bombe. Der Wert fungiert hierbei als Multiplikator für die Explosionsstärke einer virtuellen Bombe. Wird der Wert 0 verwendet, ist die Option deaktiviert.abschließend sei noch die 37

50 3. Analyse der Software Option Demolish groups erwähnt. Durch sie wird die Zerstörung von gruppierten Objekten möglich. Die Option ist jedoch nur verfügbar, wenn die in der Kategorie PhysX Simulation Properties vorhandene Option Treat Group as auf One concave object eingestellt wurde. Wenn ein Objekt durch eine Kollision mit einem anderen Objekt zerstört und demzufolge fragmentiert wird, ist eine weitere Beeinflussung der Objektfragmente möglich. Diese können bei Bedarf zusammenkleben und auch nach einer zusätzlichen Krafteinwirkung wieder zerbrechen. Hierfür stehen Glue options, sowie Glue breaking options zur Verfügung ( siehe Abbildung 3.19 ). Abbildung 3.19: Die Glue Optionen des RayFire Tools. 38 Die Glue 2 Funktion kann über Glue demolished objects aktiviert werden. Diese Option kann nur auf Objektfragmente angewendet werden, die über Demolish geometry aus einem Objekt entstanden sind. Mit Glue objects in groups können gruppierte Objekte verklebt werden. Analog zu dieser Funktion können mit Glue linked objects Objekte, die über die 3ds Max link 3 Funktion aneinander gekoppelt sind, verklebt werden. Über Glue radius kann ein Radius gewählt werden, in welchem die Glue Funktion angewendet wird. Swing angle legt den Winkel fest, in der die Objektfragmente ihr Bewegungsverhalten ändern dürfen. Um die Verbindung der verklebten Objektfragmente zu lösen, wird die Option Breakable unter Glue breaking options verwendet. Nachdem diese aktiviert wurde, kann über Strength die Kraft festgelegt werden, die bei einer Kollision nötig ist, um die Verbindung der verklebten Objektfragmente zu lösen. Jedoch ist die Kraft, welche benötigt wird, um die Verbindung zwischen den Objektfragmenten zu lösen von der Masse der jeweiligen Objekte abhängig. Das bedeutet ein kleines Objekt mit einer ebenso kleinen Masse benötigt einen viel kleineren 2 deutsch: Klebstoff 3 Mit der Link Funktion kann eine Eltern-Kind Hierarchie zwischen zwei Objekten hergestellt werden. Das Kind-Objekt erbt dabei das Verhalten des Eltern-Objekts.

51 3.2. RayFire Strength Wert, als ein großes Objekt mit einer großen Masse. Das macht es sehr schwierig, wenn nicht unmöglich, kleine und große Objekte gleichzeitig mit diesen Optionen zu simulieren. Um dieses Problem zu umgehen, kann Strength by mass aktiviert werden. Dies hat zur Folge, dass alle Objekte und die benötigte Kraft, um die Objektfragmente zu zerbrechen, relativ zu ihrer Masse berechnet werden. Sollte diese Option nicht aktiviert werden, kann mit Strength variation eine prozentuale Variation des Strength Wertes vorgenommen werden. Layers Die Verwaltung der einzelnen Simulationsschritte findet über die Kategorie Layers statt. Sobald ein Objekt manuell fragmentiert oder über Demolish geometry zerstört wurde, wird für diesen Vorgang ein Layer angelegt. Wie schon erwähnt, wird bei einer Fragmentierung nicht das originale Objekt, sondern eine Kopie fragmentiert. Das originale Objekt wird vor der Fragmentierung verborgen und bleibt somit erhalten. Über Layers können alle erstellten Layer, sowie deren einzelnen Effekte, selektiert ( Select ), gelöscht ( Delete ), verborgen ( Hide ), sowie eingefroren 4 ( Freeze ) werden ( siehe Abbildung 3.20 ). Hide und Freeze können durch erneutes Drücken der Schaltflächen wieder aufgehoben werden. Abbildung 3.20: Die Verwaltung der Simulationsschritte erfolgt über Layers. Links: Layers. Rechts: Presets. Über Presets können die über RayFire vorgenommenen Einstellungen abgespeichert werden. So wird ermöglicht, dass für spezifische Situationen, welche häufig benötigt werden, nur einmal konfiguriert werden müssen. Anschließend können sie als Preset abgespeichert und zu jedem Zeitpunkt wieder geladen werden. wird. 4 Eingefrorene Objekte können solange nicht selektiert werden, bis sie das Einfrieren wieder aufgehoben 39

52 3. Analyse der Software 3.3 Particle Flow Particle Flow ist ein nicht lineares, Ereignis basiertes Partikelsystem. Particle Flow wurde von Orbaz Technologies im Auftrag von Autodesk entwickelt. Die Veröffentlichung von Particle Flow erfolgte 2003 als integriertes Partikelsystem in 3ds Max 6. Particle Flow wird hauptsächlich zur Simulation von Feuer, Rauch, Wasser, Eis, Schnee und ähnlichen Effekten eingesetzt. Orbaz Technologies entwickelte später Particle Flow Tools: Box 1. Particle Flow Tools: Box 1 erweitert Particle Flow um zusätzliche Funktionen und ist in 3ds Max 2010 integriert. Für Besitzer von 3ds Max 2009 inklusive einem Abonnement ist es durch die Installation der Creativity Extension ebenfalls kostenlos verfügbar Aufbau Die Bedienung von Particle Flow erfolgt innerhalb von 3ds Max über den so genannten Particle View. In diesem Fenster sind die alle Bedienungselemente und Funktionen für den Erstellung von Simulationssystemen vorhanden ( siehe Abbildung 3.21 ). Abbildung 3.21: Über den Particle View erfolgt der Aufbau der Simulationen. 40

53 3.3. Particle Flow Die Menüleiste [1] enthält Funktionen zum Editieren, sowie Selektieren von Depot [3] Komponenten und zur Erstellung von Partikelsystemen. Es können hierüber ebenfalls verschiedene Einstellungen für die Darstellung der Systeme vorgenommen werden. Auch der Zugriff auf grundlegende Optionen für die Analyse und Fehlerbehebung der Simulationssysteme ist über die Menüleiste möglich. In dem Ereignisbildschirm [2] werden die Simulationssysteme erstellt. Hier werden die Depot Komponenten eingefügt und in so genannten Partikeldiagrammen [7] strukturiert. Das Depot [3] enthält alle Particle Flow Komponenten. Mit ihnen werden die Simulationssysteme aufgebaut. Die Konfiguration der Komponenten findet im Parameter Panel [4] statt. Hierüber können alle verfügbaren Parameter verändert werden. Eine Funktionsbeschreibung der im Depot verfügbaren Komponenten ist unter [5] vorhanden. Mit den Darstellungswerkzeugen [6] kann die Ansicht auf die Partikeldiagramme verändert werden. Über die Partikeldiagramme [7] entstehen die eigentlichen Simulationssysteme. Sie werden durch verschiedene Depot-Komponenten aufgebaut und gesteuert Funktionsweise Wie schon erwähnt, ist Particle Flow ein nicht lineares, Ereignis basiertes Partikelsystem. Die Nichtlinearität bedeutet hierbei, dass dem Benutzer alle Freiheiten in Bezug auf den Aufbau eines Simulationssystems gegeben sind. Um einen bestimmten Effekt zu erzeugen, sind vielfältige Möglichkeiten durch verschiedene Depot-Komponenten und den Ereignis basierten Ansatz gegeben. Ein Simulationssystem wird durch das Kombinieren verschiedener Depot-Komponenten aufgebaut. Die Depot-Komponenten beschreiben unter anderem die Eigenschaften von Partikeln, wie z.b. die Form, die Geschwindigkeit, die Rotation, sowie die Richtung und bestimmen wie sich diese Eigenschaften innerhalb einer bestimmten Zeit verändern. Die Depot-Komponenten werden in Partikeldiagrammen angeordnet. Diese Partikeldiagramme bestehen aus Events 5. Über die Events findet die eigentliche Steuerung des gesamten Simulationssystems statt. Nachdem ein kurzer Überblick über den Aufbau und die Funktionsweise von Particle Flow gegeben wurde, soll nun eine Analyse der einzelnen Funktionen einen tieferen Einblick und ein besseres Verständnis über Particle Flow gewährleisten. Menüleiste Die Menüleiste [1] ist überwiegend ein redundantes Steuerungselement. Aktionen wie das Einfügen von Depot-Komponenten in den Ereignisbildschirm [2], die Selektierung von einzelnen Komponenten-Typen, sowie der Zugriff auf Darstellungswerkzeuge [6] sind ebenfalls direkt über die jeweiligen Kategorien verfügbar. Dennoch verfügt die Menüleiste über Optionen, auf welche nur von dort aus zugegriffen werden kann. Zu erwähnen sind hierbei unter anderem die Möglichkeit, nur Partikel in ausgewählten Events zu rendern. Ebenfalls nützlich ist das Einblenden eines Particle Counts für jedes Event. Es wird hierbei die Anzahl der Partikel für jedes einzelne Event angezeigt. Diese Option kann zur Fehlerbehebung 5 deutsch: Ereignisse 41

54 3. Analyse der Software genutzt werden. Auch der Aktualisierungs-Typ kann über die Menüleiste gewählt werden. Falls während dem Abspielen einer Simulation im Viewport von 3ds Max ein Parameter in Echtzeit geändert wird, kann hiermit festgelegt werden, ob die Simulation ab dem ersten Frame oder ab dem aktuellen Frame geändert wird. Dies kann zu deutlich kürzeren Simulationszeiten führen. Depot Über das Depot können alle in Particle Flow verfügbaren Komponenten aufgerufen werden. Sie sind der grundlegende Bestandteil von Partikelsystemen. Abbildung 3.22: Das Depot ermöglicht den Zugriff auf alle in Particle Flow verfügbaren Komponenten. Die mit einem Stern gekennzeichneten Komponenten sind Bestandteil von Particle Flow Tools: Box Wie in Abbildung 3.22 zu sehen, existieren verschiedene Arten von Komponenten. Obwohl die Komponenten mit vier verschiedenen Farben gekennzeichnet sind, existieren nur drei Kategorien: Operators Flows Tests

55 3.3. Particle Flow Operators repräsentieren hierbei die grundlegenden Elemente von Partikelsystemen. Operators beschreiben die charakteristischen Eigenschaften der Partikel über einen bestimmten Zeitraum. Über sie können unter anderem Bewegungs- und Rotationsgeschwindigkeit, Richtung, Form, sowie Oberflächeneigenschaften von Partikeln konfiguriert werden. Zu Operators werden alle Komponenten mit blauen, sowie grünen Symbolen gezählt. Diese sind wiederum in zwei Gruppen eingeteilt. Die erste Gruppe enthält Operatoren, welche das Verhalten der Partikel beeinflussen. In der zweiten Gruppe ( in Abbildung 3.23 am Ende des Depots zu sehen ) sind eher funktionelle Operatoren vorhanden, mit denen unter anderem das Erscheinungsbild der Partikel im 3ds Max Viewport definiert wird. Abbildung 3.23: Zu den Operators zählen Komponenten mit blauen, sowie grünen Symbolen. Diese werden ebenfalls in zwei Gruppen eingeteilt. Innerhalb der Gruppen sind sie alphabetisch geordnet. Flow-Komponenten liefern die Grundstruktur für ein Simulationssystem. Ein Simulationssystem kann aus einem oder mehreren Flows bestehen. Ein einzelner Flow besteht immer aus einer Sequenz von Events. Ein typischer Flow beinhaltet ein globales Event 6, ein Birth Event, sowie eine Anzahl an weiteren, lokalen Events. Die Events bestehen wiederum aus Operator- oder Test-Komponenten. 6 Auf die Bedeutung der verschiedenen Events wird im Abschnitt näher eingegangen. 43

56 3. Analyse der Software Abbildung 3.24: Die Symbole der Flow-Komponenten sind grau. Der Aufbau eines Simulationssystems beginnt in Particle Flow immer mit dem Platzieren eines Flows. Im Depot stehen dafür entweder ein leerer Flow, oder vordefinierte Flow-Komponenten zur Verfügung ( siehe Abbildung 3.24 ). Ein vordefinierter Standard Flow enthält dabei verschiedene Operator-Komponenten, um ein Partikelsystem in seiner einfachsten Form darzustellen ( siehe Abbildung 3.25 ). Abbildung 3.25: Ein Standard Flow enthält die grundlegenden Operatoren für ein simples Partikelsystem. Links: Standard Flow in der Particle View-Ansicht. Rechts: Ein Standard Flow im 3ds Max Viewport. 44

57 3.3. Particle Flow Es besteht ebenfalls die Möglichkeit ein Preset Flow zu erstellen. Über den in Particle Flow integrierten Preset Manager können erstellte Flows als Preset abgespeichert werden. Diese können anschließend über die Preset Flow-Komponente wieder geladen werden. Ein Preset kann nicht nur einen Flow, sondern eine Vielzahl von Flows enthalten. So können Abbilder von kompletten Systemen erstellt und per Knopfdruck wieder geladen werden. Diese Funktion ermöglicht es auf einfache Art und Weise Partikelsysteme zu archivieren. Abbildung 3.26: Systeme können mit Hilfe der Preset Funktion gespeichert und durch die Preset Flow-Komponente wieder geladen werden. Zur Übersicht kann eine Beschreibung des gespeicherten Preset hinzugefügt werden. Es werden hierbei nicht nur die Partikelsysteme gespeichert, sondern auch eine vollständige 3ds Max Datei mit allen beinhaltenden Komponenten und Einstellungen. Durch die Archivierung der Szenendateien können die abgespeicherten Presets durch über die Modifizierung der einzelnen Szenendateien nachträglich verändert werden. Test-Komponenten können wie auch Operator-Komponenten ebenfalls in Events eingefügt werden. Ihre Symbol-Farbe ist gelb ( siehe Abbildung 3.27 ).Test-Komponenten beeinflussen in einem Event jedoch nicht das Verhalten der Partikel, sondern sind für die Steuerung der Partikel innerhalb der Partikeldiagramme zuständig. Die grundlegende Funktion von Test-Komponenten ist demzufolge die Prüfung von Partikeln auf ein oder mehrere Bedingungen, abhängig von der jeweiligen Test-Komponente. Sie lenken die Partikel über ihre Bedingungen von einem Event zum nächsten Event. Erfüllen die Partikel die Bedingungen, werden sie an ein anderes Event weitergeleitet. Erfüllen sie die Bedingungen nicht, bleiben sie in dem Event bestehen, durchlaufen das Event ein weiteres Mal und die Abfrage beginnt erneut. Aufbauend auf diesem Prinzip existieren vielfältige Test-Komponenten in Particle Flow. 45

58 3. Analyse der Software Abbildung 3.27: Die Symbole der Test-Komponenten sind gelb. Die einzelnen Test-Komponenten unterscheiden sich untereinander hauptsächlich in ihren Bedingungen. Ein Beispiel für die oben Beschriebene Funktionsweise ist in Abbildung 3.28 zu sehen. Hier wird der simple Aufbau eines Partikelsystems aus Abbildung 3.25 durch Test-Komponenten erweitert. Dem Standard Flow wird ein Collision Test hinzugefügt. Die Bedingung des Collision Test ist erfüllt, sobald eine Kollision der Partikel mit einem Deflector 7 stattfindet. Nachdem eine Kollision stattgefunden hat, werden die kollidierten Partikel in das nächste Event weitergeleitet. Abbildung 3.28: Ein Beispiel für den Einsatz von Test-Komponenten. Links: Aufbau des Partikelsystems. Rechts: Ansicht im 3ds Max Viewport. Der Deflektor wird durch die zweidimensionale viereckige Fläche in der Mitte des Bildes repräsentiert deutsch: Deflektor. Deflektoren sind planare Flächen, welche in 3ds Max für Interaktionen mit Partikeln eingesetzt werden.

59 3.3. Particle Flow In Event 02 befindet sich ein Display Operator, sowie ein Age Test. Der Display Operator ändert die Farbe der sich in dem Event befindlichen Partikel in Grün. Der Age Test überprüft das Alter der Partikel. In diesem Beispiel wurde als Bedingung das Alter in diesem Event überprüft. Um die Bedingung zu erfüllen, müssen sich die Partikel länger als 4 Frames ( Event > 4 ) in diesem Event aufhalten. Ist die Bedingung erfüllt, werden sie in Event 03 weitergeleitet. Erfüllen sie die Bedingung nicht, durchlaufen sie das Event in jedem Frame erneut, bis die Bedingung erfüllt ist. Event 03 enthält einen weiteren Display Operator, welcher die Farbe der Partikel in Blau abändert. Ereignisbildschirm Der Ereignisbildschirm beinhaltet alle erstellten Partikeldiagramme und ist somit für die logische Darstellung der Partikelsysteme zuständig. Partikeldiagramme bestehen aus Flows und diese wiederum aus mehreren Events. Wie bereits erwähnt, besteht ein typischer Flow aus einer Sequenz von Events. In Particle Flow werden Events immer von oben nach unten abgearbeitet. Dabei ist zu beachten, dass es zwei verschiedene Event Kategorien gibt: Global Event Local Event Das Global Event ist bei einem Particle Flow immer das erste Event. Die Eigenschaften, von sich in dem Global Event befindlichen Depot-Komponenten, beeinflussen die Partikel des gesamten Flows. In einem typischen Global Event befindet sich nur ein Render-Operator. Sollen weitere Eigenschaften überschrieben werden, können hier beliebige Operatoren zusätzlich eingefügt werden. Es ist dabei jedoch zu beachten, dass alle nachfolgenden Operatoren des selben Typs die Partikel nicht mehr beeinflussen, da sie den Global Event-Operatoren überschrieben werden. Alle dem Global Event nachfolgenden Events sind Local Events. Sie werden als Local Events bezeichnet, da alle Depot-Komponenten die sich in einem Event befinden, auch nur Partikel in diesem Event beeinflussen können. Die Birth Events sind spezielle Local Event-Typen. Sie gelten als eigentlicher Startpunkt von Flows, da die erste Depot-Komponente immer ein Birth Operator ist, durch den die Partikel emittiert werden. Aus diesem Grund folgen Birth Events grundsätzlich direkt auf ein Global Event. Particle Flow Tools: Box 2 Particle Flow Tools: Box 2 wurde, wie auch Particle Flow und Particle Flow Tools: Box 1, ebenfalls von Orbaz Technologies entwickelt. Es implementiert die Unterstützung der NVIDIA PhysX Engine in Particle Flow und ermöglicht somit realistische Simulationen auf physikalischer Basis. Der Zugriff auf die integrierte PhysX Engine findet über spezielle Testund Operator-Komponenten statt. Diese sind, wie alle anderen Komponenten, im Depot abgelegt. Sie sind dort jeweils durch einen zusätzlichen Stern gekennzeichnet. 47

60 3. Analyse der Software Abbildung 3.29: Die durch Particle Flow Tools: Box 2 in Particle Flow integrierten Komponenten. Wie in Abbildung 3.29 zu sehen, befindet sich ebenfalls eine zusätzliche Flow-Komponente im Depot. PhysX Flow ist eine vordefinierte Flow-Komponente, welche grundlegende Operator- Komponenten für ein simples Partikelsystem auf Basis der Physx Engine enthält. Der hauptsächliche Unterschied gegenüber einem Standard Flow sind die Operator-Komponenten PhysX World, sowie PhysX Shape. Über PhysX World wird die PhysX Engine aktiviert. Ebenfalls können globale Einstellungen der Simulation definiert werden. PhysX Shape legt dabei die zu simulierende Form bei einer Simulation fest. Abbildung 3.30: Links: Logische Ansicht der PhysX Flow- Komponente. Rechts: Ausschnitt einer gerenderten Animation der PhysX Flow-Komponente. 48 Die Partikel werden bei der PhysX Flow-Komponente standardmäßig im 3ds Max Viewport als Quader dargestellt. Sobald sie emittiert werden, wird ihr physikalisches Verhalten durch den PhysX World-Operator gesteuert. Sie fallen durch die einwirkende Gravitation

61 3.4. Zusammenfassung nach unten, kollidieren mit dem Untergrund und kommen anschließend zur Ruhe ( siehe Abbildung 3.30 ). 3.4 Zusammenfassung In diesem Kapitel wurde eine detaillierte Analyse der im vorigen Kapitel ausgewählten Software-Komponenten, RayFire und Particle Flow durchgeführt. Zuerst wurde ein Überblick über den Aufbau der Programmstruktur geliefert. Anschließend folgte eine Analyse der Funktionsweise der Software-Komponenten. Es wurde auf einzelne Optionen eingegangen, sowie auf potentielle Fehlerquellen aufmerksam gemacht. Nachdem nun ein tieferes Verständnis über die Programme und deren Funktionsweise vorliegt, können die Programme im folgenden Kapitel anhand von zwei Testszenen miteinander verglichen werden. 49

62

63 Kapitel 4 Vergleich der Software 4.1 Einleitung In dem Kapitel Analyse der Software wurde eine detaillierte Analyse des RayFire Tools, sowie Particle Flow durchgeführt. Bei beiden Programmen wurde ein Einblick in den strukturellen Aufbau gegeben. Ebenfalls hat eine Untersuchung der Funktionsweise beider Produkte stattgefunden. Wie in Kapitel 3 bereits dargestellt, verfügen sowohl RayFire, als auch Particle Flow über einen weitreichenden Funktionsumfang. Beiden Programmen stehen vielfältige technische Möglichkeiten zur Verfügung, um eine glaubhafte Zerstörung von virtuellen Objekten durchzuführen. Mit einer Auswahl dieser Fähigkeiten werden die Produkte auch von dem jeweiligen Hersteller beworben. Die beworbenen Fähigkeiten gelten hierbei meist als Hauptmerkmale, welche diese Produkte auszeichnen und sie somit attraktiv für potenzielle Käufer machen sollen. Beispiele dafür sind unter anderem die Unterstützung der PhysX Engine, Glueing, ein interaktives Zerstörungssystem oder auch verschiedene Fragmentierungstypen. Um einen Kunden von dem Produkt, welches nicht selten mehrere hundert oder tausend Euro kostet, zu überzeugen, werden häufig visuelle Beispiele in Form von Bildern und Videos erstellt. Diese beinhalten Effekt-Szenen welche mit den jeweiligen Produkten erstellt wurden. Ebenfalls werden Demo Versionen entweder mit eingeschränktem Funktionsumfang, oder mit zeitlicher Begrenzung angeboten. Oft reichen die vom Hersteller zur Verfügung gestellten Möglichkeiten jedoch nicht aus, um die Stärken und Schwächen eines Produktes objektiv beurteilen zu können. Der Kunde muss sich in diesem Fall auf die vom Hersteller angepriesene Funktionalität verlassen. Die Probleme, die bei der Umsetzung eines Effektes mit dem jeweiligen Programm entstehen, treten meistens erst während des Produktionszyklus auf. In diesem Kapitel soll eine Auswahl der technischen Hauptmerkmale von RayFire und Particle Flow anhand von praktischen Beispielen miteinander verglichen werden. Eine Grundvoraussetzung ist hierbei die Verwendung der PhysX Engine. Zu diesem Zweck sollen zwei Testszenen erstellt werden. Die beiden Testszenen unterscheiden sich dabei in ihrem Schwer- 51

64 4. Vergleich der Software punkt. In Testszene 1 sollen die vom Hersteller angepriesenen Hauptmerkmale an einem funktionellen, praktischen Beispiel auf ihre Funktionalität getestet werden. Mit der Testszene 2 sollen die Produkte auf ihre Einsatzfähigkeit in einer professionellen Effekt-Szene getestet werden. Anschließend sollen die Vor- und Nachteile anhand der Testszenen herausgearbeitet werden. Abschließend erfolgt eine Bewertung der angewandten Techniken anhand von verschiedenen Kriterien. 4.2 Testszene 1 Um die technischem Möglichkeiten von RayFire und Particle Flow anhand einer Testszene optimal miteinander zu vergleichen, müssen verschiedene Kriterien für die Erstellung und den Vergleich dieser Testszene festgelegt werden. Folgende Kriterien müssen hierbei beachtet werden: Kombination vieler Hauptmerkmale Die Erstellung von kleinen Testszenen, in denen wenige Funktionen getrennt voneinander getestet werden ist oft problemlos möglich. Die Stärken und Schwächen der Programme kommen jedoch meistens erst bei komplexeren Kombinationen der technischen Möglichkeiten zum Vorschein. Aus diesem Grund sollten möglichst viele Hauptmerkmale in Kombination miteinander getestet werden. Simulation durch PhysX Ein realitätsnahes Verhalten der Objekte ist Grundvoraussetzung für eine glaubhafte Zerstörung von virtuellen Objekten. Die Verwendung von PhysX gewährleistet ein glaubhaftes Verhalten der Objekte. Gleichzeitig ermöglicht es einen objektiven Vergleich beider Produkte. Übersichtlichkeit Um das Ergebnis der angewandten Techniken optimal beurteilen zu können, sollte eine größtmögliche Übersicht gewährleistet werden. Die visuelle Beschaffenheit, sowie der Aufbau der Szene sollte dezent und funktionell sein Aufbau Im Mittelpunkt der Szene befindet sich das Testobjekt, an dem der Vergleich der Techniken durchgeführt werden soll. Das Objekt repräsentiert den Rohbau eines Gebäudes und besteht aus 980 einzelnen, quaderförmigen Objekten, welche als Ziegelsteine fungieren ( siehe Abbildung 4.1 ).

65 4.2. Testszene 1 Abbildung 4.1: Aufbau der ersten Testszene. Um die Ergebnisse von RayFire und Particle Flow optimal vergleichen zu können, wird für beide Ansätze der identische Renderer, Render-Einstellungen, sowie eine identische Beleuchtung, Kameraposition und Länger der Sequenz verwendet. Zur Auswahl stehen die in 3ds Max vorhandenen Renderer Scanline und Mental Ray. Scanline verfügt im Vergleich zu Mental Ray über einen sehr eingeschränkten Funktionsumfang. In Bezug auf die Lichtgestaltung ist unter anderem die Verwendung von Final Gather 1 mit Scanline nicht möglich. Da Final Gather auf Grund der realistischeren Beleuchtung und des Schattenwurfs eingesetzt werden soll, wird als Renderer Mental Ray verwendet. Als Lichtquelle wird ein Mental Ray Area Omni Light verwendet. Die Auflösung der zu berechnenden Bilder beträgt 1024x768 Pixel. Auf Bewegungsunschärfe wird zwecks einer besseren Beurteilung des Ergebnisses verzichtet. Die Länge der zu simulierenden Sequenz wird auf 100 Frames festgelegt. 1 Final Gather ist ein Algorithmus der Bildsynthese, sowie eine Methodik der Indirekten Beleuchtung. 53

66 4. Vergleich der Software Problemstellung Das vorgegebene Testobjekt soll durch eine Explosion zerstört werden. Die Explosion soll hierbei innerhalb des Testobjektes stattfinden. Durch die entstehende Kraft der Explosion sollen die Wände des Testobjektes zerstört werden. Dabei sollen die einzelnen Ziegelsteine durch PhysX Glue zusammengehalten werden. Wird die durch die Explosion einwirkende Kraft zu groß, soll die Verbindung der einzelnen Steine an den jeweiligen Stellen aufgelöst werden. Zusätzlich sollen bei einer Kollision mit der Bodenfläche die kollidierenden Ziegelsteine zerbrechen, falls die einwirkende Kraft die Festigkeit der Ziegelsteine übersteigt RayFire Zunächst wird die Testszene mit RayFire bearbeitet. Um die vorgegebene Problemstellung zu lösen müssen verschiedenste Techniken angewandt werden. Im den folgenden Abschnitten wird die Vorgehensweise näher erläutert. Explosion Die eigentliche Explosion erfolgt in RayFire über die integrierte virtuelle Bombe RF Bomb. Die Ausbreitungsform der Explosion muss hierbei sphärisch sein. Da das vorgegebene Testobjekt eine rechteckige und keine quadratische Form besitzt, reicht eine virtuelle Bombe alleine nicht aus. Um auf alle vier Seitenwände eine gleichmäßige Kraft auszuüben, werden zwei virtuelle Bomben mit jeweils geringeren Strength-Werten eingesetzt ( siehe Abbildung 4.2). 54

67 4.2. Testszene 1 Abbildung 4.2: Links: Radius einer Bombe. Rechts: Radien beider Bomben. Die wirkende Kraft ist bei zwei Bomben besser auf das gesamte Testobjekt verteilt und ergibt damit ein gleichmäßigeres Ergebnis. Vorbereitungen Für ein glaubhafteres Ergebnis sollten Teile des unteren Mauerwerks auch nach der Explosion noch intakt sein. Aus diesem Grund wird eine ausgewählte Anzahl an Ziegelsteinen ( siehe Abbildung 4.3) als Unyielding Object definiert. Dadurch werden sie zwar als Kollisionsobjekte mit in die Simulation miteinbezogen, verändern jedoch weder ihre Position, noch können sie zerstört werden. Abbildung 4.3: Links: Komplettes Testobjekt. Rechts: Ausgewählte Ziegelsteine bleiben intakt. Um ein glaubhaftes Verhalten der Ziegelsteine zu erzielen, muss zunächst ein geeignetes 55

68 4. Vergleich der Software Material zugewiesen werden. Da es sich in der vorgegebenen Testszene um den Rohbau eines Gebäudes handelt, welches aus Ziegelsteinen besteht, wird ein Brick 2 -Material verwendet. Die den Objekten dadurch zugewiesenen PhysX-Parameter wie Reibungswiderstand, Elastizität, Dichte und Masse gewährleisten ein glaubhaftes Verhalten der Objekte während einer Simulation. Um das gewünschte Zusammenkleben der einzelnen Ziegelsteine zu gewährleisten, müssen die PhysX Glue-Optionen aktiviert werden. Da die noch zusammenklebenden Ziegelsteine bei zu großer Krafteinwirkung auseinander brechen sollen, werden diese zusätzlich als Breakable deklariert. Hierbei wird ein Breakable Wert mit einer zusätzlichen Variation festgelegt. Durch diese zufällige Verteilung der benötigten Krafteinwirkung auf alle Ziegelsteine, kann ein glaubhafteres Endergebnis erzielt werden. Für eine zusätzliche Zerstörung der einzelnen Ziegelsteine wird die Interactive Demolition 3 - Option aktiviert. Übersteigt die auf die Ziegelsteine einwirkende Kraft bei einer Kollision eine festgelegte Grenze, werden diese abhängig nach den konfigurierten Fragmentierungs- Einstellungen zerstört. Als Fragmentierungs-Typ wird hierbei Voronoi gewählt. Die durch diesen Algorithmus entstehenden Fragmente ähneln der Grundstruktur von Ziegelsteinen und sind deshalb sehr gut für diesen Zweck geeignet. Die Anzahl der entstehenden Fragmente pro Ziegelstein wird auf 6 festgelegt. Zusätzlich wird eine Variation von 3 gewählt, um eine zu gleichmäßige und deshalb unglaubwürdige Fragmentierung der Objekte zu verhindern. Probleme Im Laufe der Bearbeitung dieser Testszene mit RayFire sind mehrere Probleme aufgetreten, welche an dieser Stelle näher erläutert werden. Bei dem Aufbau der Testszene wurde darauf geachtet, dass die einzelnen Ziegelstein-Objekte direkt aufeinander liegen. Sobald die Simulation mit RayFire gestartet wird und die PhysX Engine die Berechnung der Objekte übernimmt, durchdringen sich diese gegenseitig. Die Durchdringung der Objekte ist zwar gering, aber sie führt dazu, dass alle Objekte eine geringe Zeitspanne nach unten fallen, bis sich die Berechnungshüllen, welche PhysX um die Objekte legt, berühren und aneinander abprallen. Dadurch kommt es zu Schwingungen, welche je nach Situation stärker oder schwächer ausfallen können. Im schlechtesten Fall wird die zu simulierende Struktur instabil und fällt in sich zusammen. Eine mögliche Lösung für dieses Problem ist, den Startzeitpunkt der Simulation so spät wie möglich festzulegen. Soll z.b. die komplette Konstruktion durch ein kollidierendes Objekt zerstört werden, so ist es ratsam die Simulation erst wenige Frames vor der Kollision mit dem Objekt zu starten. Dadurch kann die Dauer der Schwingung reduziert werden. Sobald das Objekt mit der Konstruktion kollidiert, wird diese zusätzlichen Kollisionskräften ausgesetzt und die Auswirkung der eigentlichen Schwingung kann dadurch minimiert werden. Eine weitere Möglichkeit besteht darin das Testobjekt durch die Kollisionsgeometrie, bzw Kollisionskraft aktivieren zu lassen. Somit bleibt das Testobjekt bis zum Zeitpunkt einer Krafteinwirkung inaktiv. Eine Durchdringung der Objekte findet hierbei nicht statt und es werden keine Schwingungen verursacht. 2 deutsch: Ziegelstein 3 deutsch: Interaktive Zerstörung 56

69 4.2. Testszene 1 Ein weiteres Problem stellt die Skalierung der Szenen-, sowie Objektgröße dar. PhysX berechnet die Masse eines Objektes entweder nach ihrem Volumen, nach einem manuell festgelegten Wert oder nach dem Volumen und zusätzlich der Dichte des verwendeten Materials. In dieser Testszene wurde die letzte Möglichkeit gewählt, welche sogleich den Umständen in der realen Welt entspricht. Ein Objekt mit kleinem Volumen hat folglich eine geringere Masse, als ein Objekt mit großem Volumen, falls beide Objekte das gleiche Material besitzen. Es sollte dabei jedoch auch auf die realitätsnahe Skalierung der Szene geachtet werden. Denn die in RayFire verwendeten Einheiten für z.b. Glue Radius stehen in Relation zu der Szenenskalierung. Dementsprechend stark sind die Auswirkungen auf die Objekte in einer Szene bei unterschiedlicher Skalierung. Dies hat während der Bearbeitung der Testszene teilweise sogar zu Abstürzen von RayFire, sowie 3ds Max und gleichzeitigem Datenverlust geführt. Um dies zu Vermeiden, sollte auf eine korrekte Einhaltung der Szenenskalierung in Relation zu den erstellten Objekten geachtet werden. Ergebnis Die Simulationszeit für 100 Frames betrug mit den im Abschnitt vorgegebenen Einstellungen etwa 9 Stunden und 40 Minuten. Durch die Interaktive Zerstörung sind 3223 neue Objekt-Fragmente entstanden ( siehe Abbildung 4.6 und 4.7 ). Die durchschnittliche Renderzeit eines Frames betrug etwa 5 Minuten. 57

70 4. Vergleich der Software Abbildung 4.4: 58

71 4.2. Testszene 1 Abbildung 4.5: Von links oben nach rechts unten: Zerstörung des Testobjektes durch Ray- Fire ohne Interaktiver Zerstörung. 59

72 4. Vergleich der Software Abbildung 4.6: 60

73 4.2. Testszene 1 Abbildung 4.7: Von links oben nach rechts unten: Zerstörung des Testobjektes durch Ray- Fire mit Interaktiver Zerstörung. 61

74 4. Vergleich der Software Particle Flow Nachdem die Testszene im vorigen Abschnitt mit RayFire bearbeitet wurde, folgt nun die Bearbeitung mit Particle Flow. Zusätzlich zu Particle Flow wird das in Kapitel 3 bereits vorgestellte Particle Flow Tools: Box 2 verwendet. Erst durch diese Erweiterung ist eine Simulation mit der PhysX Engine mit Particle Flow möglich. Explosion Für die Explosion kann bei Particle Flow nicht auf eine vordefinierte virtuelle Bombe zurückgegriffen werden. Um eine ähnliche Auswirkung auf das Testobjekt hervorzurufen, muss eine alternative Methode angewandt werden. Hierbei wird ein PFlow Emitter verwendet, welcher innerhalb eines Frames 100 achzigseitige Sphären mit hoher Geschwindigkeit emittiert ( siehe Abbildung 4.8 ). Die Ausbreitungsform des Emitters ist ebenfalls sphärisch, d.h. 360 Grad. Diese explosionsartige Ausstoßung der Sphären basiert grundlegend auf dem gleichen Prinzip wie eine virtuelle Bombe. Die Sphären kollidieren im selben Frame, in dem sie emittiert werden mit dem Testobjekt und führen somit zu dessen Zerstörung. Um eine exponentielle Krafteinwirkung auf die Ziegelsteine durch die hohe Geschwindigkeit der Sphären zu verhindern, sollte die Kollisionstoleranz erhöht werden. Die Kollisionsberechnung wird ungenauer und ermöglicht somit ein gegenseitiges, sowie partielles Durchdringen von Sphären und Ziegelsteinen. Eine zu hohe Kollisionstoleranz führt jedoch zu unbefriedigenden Ergebnissen, da die Ziegelsteine auch den Untergrund durchdringen. Hier muss ein geeigneter Mittelwert gefunden werden. Abbildung 4.8: Links: Das intakte Testobjekt von oben. Mitte: Die Sphären werden emittiert und kollidieren im selben Frame mit dem Testobjekt. Rechts: Ein Frame nach der Emission der Sphären. Die Sphären werden hier nur aus Gründen der Verdeutlichung mitgerendert. 62 Vorbereitungen Die Ziegelsteine des vorgegebenen Testobjektes werden über einen Birth Group Operator als einzelne Partikel instanziiert. Die Partikel nehmen dadurch die Form, Position, sowie die Ausrichtung im 3D-Raum der Ziegelsteine an und stehen nun zur weiteren Verwendung mit Particle Flow zur Verfügung. Das ursprüngliche Testobjekt wird ausgeblendet. Wie schon in Abschnitt beschrieben, soll auch hier ein Teil des unteren Mauerwerks von der

75 4.2. Testszene 1 Explosion unberührt bleiben. Hierfür wird ein geometrisches Objekt erstellt, welches alle von der Simulation auszuschließenden Ziegelsteine umschließt ( siehe Abbildung 4.9 ). Die von dieser Box umschlossenen Ziegelsteine werden durch einen Split Group-Test in ein anderes Event umgeleitet und bleibt somit von der Explosion unberührt. Abbildung 4.9: Links: Die von der Simulation ausgeschlossenen Ziegelsteine. Rechts: Die konstruierte Box, welche die Ziegelsteine umschließt. Die restlichen Ziegelsteine werden durch einen PhysX Glue-Operator zusammengehalten. Auch hier muss die Breakable Option aktiviert werden, damit die Verbindungen der Ziegelsteine bei einer zu hohen Krafteinwirkung wieder auseinanderbrechen. Die Konfiguration des Glue Binding wird durch die Visualisierung im Viewport erleichtert ( siehe Abbildung 4.10 ). Zusätzlich werden die PhysX-Parameter für ein realitätsnahes Verhalten der Ziegelsteine, wie Reibungswiderstand, Elastizität, Dichte und Masse zugewiesen. Da hierfür keine Presets ( z.b. Brick-Material ) zur Verfügung stehen, müssen die Parameter manuell zugewiesen werden. Probleme Auch bei der Bearbeitung der Testszene mit Particle Flow sind Probleme aufgetreten. Da die Sphären mit einer hohen Geschwindigkeit innerhalb eines Frames emittiert werden und mit dem Testobjekt kollidieren, steigt die Krafteinwirkung auf das Testobjekt exponentiell an. Dies hat einen Popkorn -Effekt zu Folge. Die Ziegelsteine werden in kürzester Zeit mit hoher Geschwindigkeit weggestoßen. Die Glue Binding- und Breaking-Werte sind nur sehr schwer zu kontrollieren, da extrem hohe Werte festgelegt werden müssen. Dies macht eine exakte Konfiguration, sowie eine kontrollierte Steuerung des Systems nahezu unmöglich. Um dem entgegenzuwirken kann die Kollisionstoleranz der PhysX Objekte erhöht werden. Die Objekte können sich dadurch etwas mehr durchdringen, bevor sie sich voneinander abstoßen. Ebenfalls können die durchzuführenden Berechnungsschritte innerhalb eines Frames reduziert werden. Dadurch reduziert sich die Krafteinwirkung auf das Testobjekt. Jedoch nimmt dadurch auch die Genauigkeit der Simulation ab, was ebenfalls zu Fehlern führen kann. Hier 63

76 4. Vergleich der Software Abbildung 4.10: Von links oben nach rechts unten: Das grüne Liniengitter repräsentiert das Glue Binding. Erreicht die einwirkende Kraft den Breaking-Wert, lösen sich die Verbindungen. Die Ziegelsteine sind hier rot dargestellt. muss ein geeigneter Mittelweg gefunden werden. 64 Particle Flow bietet keine direkte Möglichkeit ein geometrisches Objekt zu fragmentieren. Orbaz Technologies bewirbt Particle Flow Tools: Box 2 unter anderen mit einer Möglichkeit Objekte über einen Particle Skinner-Modifikator zu fragmentieren. Diese Methode ist jedoch äußerst umständlich, zeitaufwändig und qualitativ nicht mit den Fragmentierungsmöglichkeiten von RayFire zu vergleichen. Dies ist ein treffendes Beispiel für die in der Einleitung erwähnten Probleme, welche erst während des Produktionszyklus auftreten. Eine direkte Möglichkeit dieses Problem zu lösen, ist nicht vorhanden. Es existiert ebenfalls eine weitere Möglichkeiten über interne 3ds Max Modifikatoren die Objekte manuell zu zerschneiden. Hierbei ist der nötige Zeitaufwand jedoch noch höher als bei der erwähnten Methode über den Particle Skinner-Modifikator und daher ebenfalls unbrauchbar. Ein Vergleich mit der Interaktiven Zerstörung des RayFire Tools ist mit Particle Flow daher nicht möglich.