Universität Innsbruck

Universität Innsbruck Institut für Informatik Intelligente und Interaktive Systeme Physic Integration für Viz-Artist Mathias Hölzl Bachelorarbeit Betreuer: Justus Piater 24. Juni 2016

Abstract Der erste Teil dieser Bachelorarbeit befasst sich mit der Evaluation der verfügbaren Physik Engines für Echtzeitsimulationen. Dabei werden folgende Kategorien bewertet: Allgemeines, Simulationsarten, Kollisionsgeometrien, Gelenke und Motoren und die Hardwareunterstützung. Die Physik Engine mit der besten Bewertung wird im zweiten Teil dieser Arbeit in dem Programm Viz-Artist integriert. Zusätzlich soll ein Plug-in entwickelt werden, welches die Simulation starrer Körper ermöglichen soll. i

ii

Inhaltsverzeichnis Abstract Inhaltsverzeichnis Erklärung i iii v 1 Einführung 1 1.1 Hintergrund....................................... 1 1.1.1 Viz-Artist.................................... 1 1.1.2 Physikalische Simulation............................ 1 1.1.3 Vor- und Nachteile der Animationssysteme................. 2 1.2 Arbeitsbeschreibung.................................. 2 1.3 Verwandte Arbeit.................................... 2 2 Physik-Engine 5 2.1 Simulationsarten.................................... 5 2.1.1 Physik starrer Körper............................. 5 3 Evaluierung 7 3.1 Anforderungen..................................... 7 3.2 Evaluierte Engines................................... 7 3.2.1 PhysX...................................... 7 3.2.2 Bullet...................................... 8 3.2.3 Open Dynamics Engine............................ 8 3.2.4 Newton Game Dynamics............................ 8 3.2.5 Weitere Physik Engines............................ 8 3.3 Bewertung........................................ 8 3.3.1 Resultate.................................... 9 3.3.2 Zusammenfassung............................... 10 4 Design 13 4.1 Use-Cases........................................ 13 4.2 Viz-Artist Plug-in System............................... 13 4.3 Komponenten...................................... 14 4.3.1 Viz-Artist.................................... 14 4.3.2 Plug-in..................................... 15 4.3.3 PhysicWrapper................................. 15 5 Konvexe Zerlegung 17 5.1 V-HACD........................................ 18 iii

6 Implementierung 19 6.1 Technologien...................................... 19 6.2 API Programmierung................................. 19 6.2.1 Binäre Kompatibilität............................. 19 6.2.2 Laden einer DLL zur Laufzeit......................... 19 6.2.3 Referenzzählung................................ 20 6.3 PhysicWrapper..................................... 20 6.3.1 Kollisionsgeometrie............................... 20 6.3.2 Komplexe Geometrien für dynamische Körper................ 20 6.4 Objektorientierte Plugin Benutzeroberfläche..................... 21 6.4.1 Visualisierung.................................. 21 7 Resultate 23 7.1 Umwandlung komplexer Geometrie.......................... 23 7.2 Plug-ins......................................... 24 7.2.1 Rigidbody Plug-in............................... 24 7.2.2 Kinematic Platform Plug-in.......................... 25 7.2.3 Canon Plug-in................................. 25 8 Schlussfolgerung 27 8.1 Zusammenfassung................................... 27 8.2 Aussicht......................................... 27 8.2.1 Bewegungsunschärfe.............................. 27 8.2.2 Erweiterungen................................. 27 8.2.3 Geometrieumwandlung auf der GPU..................... 28 Literaturverzeichnis 29 Abbildungsverzeichnis 31 Tabellenverzeichnis 33 iv

Erklärung Ich erkläre hiermit an Eides statt durch meine eigenhändige Unterschrift, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Alle Stellen, die wörtlich oder inhaltlich den angegebenen Quellen entnommen wurden, sind als solche kenntlich gemacht. Signiert:...................................................... Datum:.. 24.06.2016..................... v

vi

Kapitel 1 Einführung In der digitalen Unterhaltungsbranche versucht man vermehrt eine realitätsnahe Illusion zu schaffen. Dies lässt sich dadurch erreichen, dass man Objekte naturgetreu darstellt. Das alleine reicht jedoch nicht aus, denn die Objekte müssen sich zudem natürlich verhalten. Solche Verhaltensweisen lassen sich am besten mit Gesetzen der Physik beschreiben. Die Formulierung und Programmierung solcher Prozesse sind keineswegs trivial. Aus diesem Grund ist es sinnvoll, bereits existierende Physik-Engines zu verwenden. Da die Anzahl an verfügbaren Physik-Engines so groß ist, ist es umso wichtiger, die richtigen Entscheidungen bei der Auswahl zu treffen. 1.1 Hintergrund Bei der Produktion von digitalen Inhalten für Fernsehausstrahlungen ist es üblich, Grafiken über ein bestehendes Video zu legen. Charakteristisch ist die sogenannte Bauchbinde. Dabei wird mit einer Grafik im unteren Bildrand, der Name und die Funktion einer Person erklärt. Heutzutage ist diese jedoch nur noch ein kleiner Teil der Produktion. Animierte 3D-Grafiken und anspruchsvolle Effekte sind bereits der Standard. Auch der Einsatz der erweiterten Realität nimmt immer mehr zu. Dabei stehen reale und virtuelle Objekte im dreidimensionalen Zusammenhang. 1.1.1 Viz-Artist Der Viz-Artist [15] ist ein Programm der Firma Vizrt [16]. Vizrt bietet Softwarelösungen für die Broadcasting-Branche. Mit fast 600 Mitarbeitern und 40 Niederlassungen weltweit gilt Vizrt als Marktführer in dieser Sparte. Im Viz-Artist können die 2D- und 3D-Grafiken für die Einblendungen erstellt und animiert werden. Für die Animation werden sogenannte Schlüsselbilder verwendet. Ähnlich wie bei einem Video, besteht die Animation aus einzelnen Schlüsselbildern, welche Informationen wie Position und Orientierung der Objekte zu einem gewissen Zeitpunkt beinhalten. Durch die Interpolation zwischen zwei Schlüsselbildern verringert sich die Anzahl der benötigten Schlüsselbilder für eine ruckelfreie Darstellung. Die einzelnen Bilder werden bei der Produktion aufgenommen und gespeichert. Die Interpolation erfolgt erst bei der Wiedergabe. 1.1.2 Physikalische Simulation Bei der physikalischen Simulation verhalten sich die Objekte nach den Gesetzen der Physik. Jedes Objekt erhält physikalische Parameter wie Masse, Reibung und Elastizität. Bei der Wiedergabe werden diese durch einen Simulationsschritt kontinuierlich aktualisiert. Wie bei der Schlüsselbildanimation, ist auch bei der physikalischen Simulation eine Interpolation zwischen 1

2 KAPITEL 1. EINFÜHRUNG zwei Simulationsschritten möglich. 1.1.3 Vor- und Nachteile der Animationssysteme Schlüsselbildanimation: + Konstanter Zeitaufwand bei der Wiedergabe + Einfaches Vor- und Zurückspulen + Wiedergabe an einem beliebigen Zeitpunkt + Deterministische Wiedergabe + Definierter Zustand zu einem exakten Zeitpunkt Natürliche Vorgänge können nicht per Hand animiert werden (Rauch, Wasser, herabfallende Gegenstände,... ) Muss vorher aufgenommen und gespeichert werden Änderungen sind aufwändig Physikalische Simulation: + Natürliches Verhalten der Objekte + Einfache Modellierung + Geringer Änderungsaufwand + Geringer Speicherbedarf + Verarbeitung von Events (z.b. Objekt A hat Objekt B berührt) Variable Simulationszeit Wiedergabe an einem beliebigen Zeitpunkt bzw. das Zurückspulen ist ineffizient Nichtdeterminismus (geringe Abweichungen bei wiederholter Wiedergabe möglich) 1.2 Arbeitsbeschreibung Im ersten Teil dieser Bachelorarbeit wird der Auswahlprozess einer Physik-Engine beschrieben. Dabei ist ein Anforderungskatalog hilfreich. Dort werden die Anforderungen aufgelistet und in Muss-, Soll- und Kann-Anforderungen unterteilt. Der zweite Schritt ist die Evaluation: Die verfügbaren Leistungen der einzelnen Physik-Engines werden bewertet. Im letzten Schritt erfolgt die Auswahl. Im zweiten Teil soll diese Physik-Engine in das Programm Viz-Artist integriert werden. Ziel ist es, ein Plug-in zu entwickeln, das die einfache Erstellung von starren Körpern und deren Simulation ermöglicht. 1.3 Verwandte Arbeit Die Verwendung einer Physik-Engine für die Simulation physikalischer Effekte in Echtzeit ist keineswegs Neuland. In modernen Computerspielen, in der Robotik und auch in der Medizin

1.3. VERWANDTE ARBEIT 3 werden vermehrt Physik-Engines eingesetzt. Anders als in der Broadcasting-Branche, wo hauptsächlich vorberechnete Animationen verwendet werden. Bei der Evaluation von Physik-Engines ist der Artikel, Evaluation of real-time physics simulation systems [1] zu erwähnen. Boeing entwickelte dafür das Programm Physics Abstraction Layer kurz PAL [9]. Die Schnittstelle ermöglicht es, mit nur einem Test mehrere Physik-Engines vergleichen zu können. PAL unterstützt zehn verschiedene Physik-Engines und davon wurden sieben für die Evaluation herangezogen. Die Ergebnisse sind veraltet und deshalb nicht mehr aussagekräftig. Ähnlich wie PAL ist das Physics Engine Evaluation Lab, kurz PEEL [10] von Pierre-Terdiman, welches 2015 veröffentlicht wurde. Eine einfache Plug-in Schnittstelle ermöglicht das Hinzufügen neuer Physik-Engines. PEEL enthält bereits ein Plug-in für Bullet [2], Newton [7] und PhysX [11].

4 KAPITEL 1. EINFÜHRUNG

Kapitel 2 Physik-Engine Eine Physik-Engine wird für die Simulation von physikalischen Prozessen verwendet. Sie finden hauptsächlich in Computerspielen oder in Simulationsprogrammen Gebrauch. In Computerspielen ist oft die physikalische Exaktheit irrelevant, wenn dadurch eine Simulation in Echtzeit garantiert werden kann. Bei Simulationsprogrammen ist wiederum oft die physikalische Korrektheit von Bedeutung. Dies führt dazu, dass sich die meisten Physik-Engines auf eines der beiden Einsatzgebiete spezialisieren. Unabhängig davon ist die Grundidee einer Physik-Engine, nämlich eine vereinfachte Programmierung von physikalischen Simulationen zu ermöglichen. 2.1 Simulationsarten Bei den physikalischen Prozessen wird zwischen folgenden Simulationsarten unterschieden: Physik starrer Körper Nicht elastische Physik mit Deformationen Masse-Feder Systeme Partikelsysteme Diese Arbeit befasst sich hauptsächlich mit der Physik starrer Körper, wobei die Evaluation alle Simulationsarten einbezieht. Dadurch können zukünftig weitere Simulationsarten hinzugefügt werden. 2.1.1 Physik starrer Körper Die Physik starrer Körper befasst sich mit der Simulation von frei beweglichen Körpern. Körper Körper besitzen eine oder mehrere Kollisionsgeometrien und physikalische Parameter wie Reibung und Elastizität. Generell wird zwischen drei Arten von Körpern unterschieden: Statische Körper Dynamische Körper Kinematische Körper 5

6 KAPITEL 2. PHYSIK-ENGINE Wie der Name schon vermuten lässt, bleiben die statischen Körper während der gesamten Simulation unverändert in Position und Orientierung. Dynamische Körper werden durch äußere Kräfte, wie z.b. Gravitation beeinflusst. Dabei wird die Position und Orientierung in jedem Simulationsschritt neu berechnet. Anders ist es bei den kinematischen Körpern: Position und Orientierung werden hier von dem Programm bestimmt. Beispielsweise würde ein Gebäude einem statischen Körper zugewiesen werden. Hätte das Gebäude einen Aufzug, so würde dies einem kinematischer Körper entsprechen. Ein Apfel, der von einem Baum fällt, könnte durch einen dynamischen Körper repräsentiert werden. Kollisionsgeometrien Die komplexen Geometrien, welche für die Visualisierung benützt werden, sind für die Echtzeitsimulation meist zu rechenintensiv. Deshalb werden effiziente Kollisionsgeometrien wie zum Beispiel Würfel, Kugeln, Kapseln und konvexe Hüllen benützt. Durch diese Vereinfachung gehen jedoch oft wichtige Informationen verloren. Problematisch sind zum Beispiel Geometrien mit Löchern. Eine Lösung für die effiziente Verwendung von konkaven Objekten wird später vorgestellt. Materialeigenschaften Je nach Physik-Engine stehen dafür mehrere Parameter zur Verfügung. Damit lassen sich materialspezifische Eigenschaften simulieren. Haft- und Gleitreibung beschreiben die Oberflächenbeschaffenheit und für dynamische Körper ist die Elastizität sowie die Masse von Bedeutung.

Kapitel 3 Evaluierung 3.1 Anforderungen Die Anforderungen werden ähnlich wie bei einem Lastenheft unterteilt in Muss-, Soll- und Kann- Anforderungen. Folgende Anforderungen werden an die Physik-Engine gestellt: Anforderung Muss Soll Kann Echtzeit Keine Lizenzkosten C/C++ Windows/Linux Mac OS X Hardwarebeschleunigung Physik starrer Körper Box Kugel Kapsel Dreiecksnetz Simulation von Partikeln Simulation von Seilen Simulation von Stoffen Tabelle 3.1: Anforderungen an die Physik Engine 3.2 Evaluierte Engines Folgende Kandidaten erfüllen die Muss-Anforderungen und wurden für die Evaluation ausgewählt: 3.2.1 PhysX Anfangs wurde die PhysX Engine [11] von der Firma Novodex AG unter dem Namen Novodex entwickelt. Diese wurde später von Ageia übernommen. Dabei erhielt die Physik Engine den heutigen Namen PhysX. Ageia wurde 2008 von dem Grafikkartenhersteller Nvidia übernommen. 7

8 KAPITEL 3. EVALUIERUNG 3.2.2 Bullet Bullet [2] ist eine Open-Source Physik Engine. Neben PhysX ist Bullet eine der bekanntesten Physik Engines. Neben hochrangigen kommerziellen Spielen wurde Bullet auch oft als Erweiterung in Form eines Plugins verwendet. Dabei ist wohl die Integration in Blender am bekanntesten. 3.2.3 Open Dynamics Engine Open Dynamics Engine (ODE) [8] ist ein Open-Source-Projekt von Russell Smith. ODE unterstützt nur die Physik starrer Körper. Einsatz findet diese Physik Engine in kommerziellen Computerspielen, Modellierungs- und Simulationsprogrammen. Besonders im Bereich der Robotiksimulation wird sie von vielen Programmen verwendet. 3.2.4 Newton Game Dynamics Newton Game Dynamics [7] spezialisiert sich ebenfalls auf die Physik starrer Körper. Sie ist Bestandteil von Spiele-Engines, wie die Leadwerks Engine und die HPL Engine. Auch dieses Projekt ist als Open Source verfügbar und zu den Hauptautoren gehören Julio Jerez und Alain Suero. 3.2.5 Weitere Physik Engines Neben diesen Kandidaten wurden noch weitere bekannte Physik Engines untersucht, welche sich jedoch als ungeeignet herausstellten. Unter anderem würde sich die Havok Physic-Engine [3] bestens eignen, wäre sie nicht kostenpflichtig. Die Physik-Engines True Axis [14], Tokamak [13] und die Simple-Physic-Engine [12] wurden ebenfalls oft referenziert, jedoch werden diese nicht mehr weiterentwickelt. 3.3 Bewertung Für die Evaluation wurden fünf Kategorien ausgewählt. Eine Kategorie besteht wiederum aus mehreren Kriterien. Die Engine, die ein Kriterium am besten erfüllt, erhält 100% und dient als Richtwert für die restlichen Engines. Die 5 Hauptkategorien: Allgemeines Simulationsarten Kollisionsgeometrien Gelenke und Motoren Hardwarebeschleunigung

3.3. BEWERTUNG 9 3.3.1 Resultate Allgemeines Diese Kategorie wird hauptsächlich durch die Qualität der API bestimmt, wobei sich die Qualität aus der verfügbaren Dokumentation, Beschreibung und den Beispielen ergibt. Engine Lizenz Plattformen Qualität Physx EULA 100% Bullet Open Source, ZLib 100% ODE Open Source, BSD/LGPL 60% Newton Open Source, ZLib 100% Tabelle 3.2: Evaluation: Allgemeines Simulationsarten Engine Starre Körper Partikel Seil Stoffe Physx Bullet ODE Newton Kollisionsgeometrien Tabelle 3.3: Evaluation: Simulationsarten Engine Kugel Box Kapsel Fläche Kegel Zylinder KH 1 KD 2 HF 3 Mesh 4 PhysX Bullet ODE Newton 1 Konvexe Zerlegung 2 Konvexe Hülle 3 Höhenfeld 4 Dreiecksnetz Gelenke und Motoren Tabelle 3.4: Evaluation: Kollisionsgeometrien Engine Gelenke Motor Limitierung Brechen PhysX 6 Bullet 6 ODE 9 Newton 6 Tabelle 3.5: Evaluation: Gelenke und Motoren

10 KAPITEL 3. EVALUIERUNG Hardwarebeschleunigung Nur PhysX nutzt die Hardwarebeschleunigung für fast alle Berechnungen. Dabei verwendet PhysX für die Parallelisierung CUDA, welche allerdings nur mit Nvidia Grafikkarten kompatibel ist. Einen anderen Weg schlägt Bullet ein, denn für die aktuelle Version (Bullet 3) existiert bereits eine experimentelle OpenCL Implementierung. Somit wäre die plattformunabhängige Hardwarebeschleunigung möglich. Engine PhysX Bullet ODE Newton Hardwarebeschleunigung CUDA OpenCL Tabelle 3.6: Evaluation: Hardwarebeschleunigung 3.3.2 Zusammenfassung Open Dynamics Engine Bei der Evaluierung kann die Open Dynamics Engine am wenigsten überzeugen. Sie fällt in fast jeder Kategorie auf den letzten Platz, ausgenommen der Anzahl der vordefinierten Gelenke. Durch die fehlende Hardwarebeschleunigung, die spärliche Dokumentation/Beschreibung der API und die Beschränkung auf die Physik starrer Körper, fällt die Open Dynamics Engine auch in der Gesamtbewertung auf den letzten Platz. Newton Game Dynamics Bei der Physik starrer Körper ist Newton Game Dynamics gleichauf mit Bullet und PhysX. Beispielsweise unterstützt Newton Game Dynamics im Gegensatz zu PhysX die konvexe Zerlegung, welche die Umwandlung komplexer Geometrien ermöglicht. Zusätzlich können schwimmfähige Körper modelliert werden. Da Newton jedoch die Simulation von Stoffen/Seilen nicht unterstützt und derzeit keine Hardwarebeschleunigung stattfindet, ergibt sich der dritte Platz in der Gesamtbewertung. Bullet Physics vs. PhysX In den Kategorien Allgemeines und Gelenke/Motoren sind beide Kandidaten gleichwertig. Die Qualität beider API s ist einwandfrei und der Einstieg wird mit einer großen Anzahl an Beispielen und Tutorials erleichtert. Auch in der Kategorie der Simulationsarten werden alle Anforderungen erfüllt, wobei PhysX im Gegensatz zu Bullet die Simulation von Partikeln unterstützt. Einen klaren Vorteil zieht Bullet in der Kategorie der Kollisionsgeometrie. Bullet stellt eine größere Auswahl an Kollisionsgeometrien bereit und bietet zusätzlich die konvexe Zerlegung mittels HACD an. Entscheidend war somit die letzte Sparte, nämlich die Hardwareunterstützung. Grundsätzlich macht der Einsatz von OpenCL für die Berechnung auf der GPU mehr Sinn, als die auf Nvidia Grafikkarten beschränkte Hardwarebeschleunigung mittels CUDA. Allerdings ist die OpenCL Entwicklung in Bullet erst in der Anfangsphase. Im Gegensatz dazu hat sich PhysX auf die hardwareunterstützte Simulation spezialisiert. Früher mit sogenannten Physikbeschleuniger und aktuell unter Verwendung der Grafikkarte. Dadurch, dass der Viz-Artist auf Nvidia-Grafikkarten optimiert ist und deshalb eine CUDA fähige Grafikkarte garantiert werden kann, ist PhysX besser geeignet als Bullet.

3.3. BEWERTUNG 11 Für die vollständige Evaluierung müssten die Physik Engines zusätzlich auf Genauigkeit, Stabilität und Performance getestet werden. Solche Eigenschaften lassen sich am besten mit einheitlichen Laufzeittests bewerten. Für solche Tests ist das PEEL [10] empfehlenswert.

12 KAPITEL 3. EVALUIERUNG

Kapitel 4 Design 4.1 Use-Cases Anforderungen an das Rigidbody Plug-in: Auswahl des Körper-Typs Statisch Dynamisch Kinematisch Auswahl der Reibung und Elastizität Haftreibung Gleitreibung Elastizität Visualisierung aktivieren/deaktivieren Dynamische Körper Auswahl der Dichte Auswahl der initialen Geschwindigkeit Auswahl der initialen Winkelgeschwindigkeit Gravitation aktivieren/deaktivieren Auswahl der Kollisionsgeometrie Box Kugel Dreiecksnetz Fläche (nur für statische/kinematische Körper) 4.2 Viz-Artist Plug-in System Abbildung 4.1: Plug-in Use- Cases Typisch für ein Plug-in System ist das dynamische Laden zur Laufzeit. Diese Methode wird auch beim Viz-Artist verwendet. Bei der Kompilierung vom Artist wird ein ausführbares Programm (.exe) erzeugt und zusätzlich eine statische Bibliothek (.lib) generiert. 13

14 KAPITEL 4. DESIGN Diese Bibliothek wird von den Plug-ins verwendet, um auf die Funktionalität vom Viz-Artist zugreifen zu können. Bei der Kompilierung des Plug-ins entsteht eine DLL, welche vom Artist zur Laufzeit geladen wird. Abbildung 4.2: Plug-in System 4.3 Komponenten Das Projekt setzt sich aus drei Komponenten zusammen: Viz-Artist PhysicWrapper Plug-in Der Viz-Artist bildet dabei die Basis und ermöglicht die Kommunikation zwischen Plug-in sowie PhysicWrapper. Beide werden vom Viz-Artist über eine DLL-Schnittstelle angesprochen. Abbildung 4.3: Komponenten 4.3.1 Viz-Artist Der Viz-Artist ist für die Instanziierung und Initialisierung des Plug-ins und des PhysicWrappers zuständig. Der PhysicWrapper wird nicht beim Programmstart instanziiert, sondern bei der ersten Verwendung. Bei der Instanziierung des PhysicWrappers wird ein globaler Kontext erstellt. Dieser wird vom Viz-Artist selbst und vom Plug-in verwendet. Über diesen gemeinsamen Kontext kann das Plug-in den PhysicWrapper ansprechen.

4.3. KOMPONENTEN 15 4.3.2 Plug-in Das Plug-in ist einerseits für die Benutzeroberfläche und deren Logik zuständig und andererseits für die Erstellung der benötigten Physikobjekte. Hierbei wird der im Viz-Artist erzeugte Kontext verwendet. Für die Benutzeroberfläche wurde der Prototyp (siehe Abb. 4.4) entworfen. Für die beiden Geometrietypen Box und Kugel soll je nach Auswahl die Dimension beziehungsweise der Radius wählbar sein. Diese Werte können jedoch auch automatisch berechnet werden. Dafür wird die Dimension des Hüllkörpers (Bounding Box) verwendet. (a) UI für statische/kinematische Körper (b) UI für dynamische Körper Abbildung 4.4: Prototyp für die Benutzeroberfläche 4.3.3 PhysicWrapper Der PhysicWrapper ist das Kernstück dieses Projekts. Zu seinen Hauptaufgaben zählen: Initialisierung von PhysX Erstellung und Verwaltung von physikalischen Objekten Visualisierung Konvexe Zerlegung Abkapselung der verwendeten Bibliotheken

16 KAPITEL 4. DESIGN

Kapitel 5 Konvexe Zerlegung Die Kollisionserkennung zwischen zwei konkaven Geometrien ist ineffizient und deshalb nicht für die Echtzeitsimulation geeignet. Eine Möglichkeit ist die Geometrie mit einer konvexen Hülle (siehe Abb. 5.1a) oder einer vereinfachten Geometrie (Kapsel, Ellipsoid, Kugel,... ) anzunähern, jedoch ist dies in den meisten Fällen zu ungenau. Eine bessere Annäherung bietet die konvexe Zerlegung. Dabei wird die konkave Geometrie in einzelne konvexe Hüllen umgewandelt. Für eine schnelle Kollisionserkennung ist es wichtig, die Anzahl der generierten konvexen Hüllen so niedrig wie möglich zu halten (Abb. 5.1b zeigt die perfekte konvexe Zerlegung). Dies lässt sich dadurch erreichen, dass man eine bestimmte Abweichung von der ursprünglichen Geometrie zulässt (siehe Abb. 5.1). (a) Konvexe Hülle (b) Exakte konvexe Zerlegung (c) Zerlegung mit V-HCAD Abbildung 5.1: Konvexe Zerlegung [5] 17

18 KAPITEL 5. KONVEXE ZERLEGUNG 5.1 V-HACD V-HACD Volumetric Hierarchical Approximate Convex Decomposition [5] ist ein Open-Source Projekt von Khaled Mamou für konvexe Zerlegung. Khaled Mamou publiziert 2009 den HCAD Algorithmus. Eine überarbeitete Version davon wurde später unter dem Namen V-HCAD als Open Source Projekt veröffentlicht. Der Algorithmus überzeugt durch Stabilität, Genauigkeit und Performance. Deshalb verwenden viele Projekte diese Bibliothek (Unreal Engine 4, Blender).

Kapitel 6 Implementierung 6.1 Technologien Die gesamte Programmierung fand rein in C/C ++ statt. Dafür wurde Visual-Studio 2015 verwendet. Diese Version unterstützt bereits die Funktionalität des C ++ 14 Standards. Für die Dokumentation wurde Doxygen verwendet. 6.2 API Programmierung 6.2.1 Binäre Kompatibilität Bei der API Programmierung ist eine binär-kompatible Schnittstelle oft vorteilhaft. Dies lässt sich dadurch erreichen, dass man für die Schnittstellen C-Funktionen verwendet und nur Basisdatentypen für die Argumente beziehungsweise den Rückgabeparameter verwendet. Ebenfalls zu beachten ist die Form der Speicherallozierung. Dadurch, dass eine DLL einen eigenen Speicherbereich für dynamisch-allozierte Objekte besitzt, ist es nicht möglich, eine Adresse außerhalb von der DLL zu nutzen und umgekehrt. Dazu kommt, dass der Speicher immer dort freigegeben werden muss, wo er alloziert wurde. Befolgt man all dies, so lässt sich die Bibliothek unabhängig von der Compiler-Version sowie von verschiedenen Programmiersprachen verwenden. 6.2.2 Laden einer DLL zur Laufzeit Beim Einbinden einer DLL gibt es zwei Methoden: Das Einbinden zur Compile-Zeit oder das Einbinden zur Laufzeit. Bei der ersten Variante wird die DLL vom Compiler eingebunden. Dabei verwendet der Linker die von der DLL exportierten Symbole in der LIB-Datei. Beim Programmstart wird dann die DLL in den Speicherbereich eingebunden. Bei der zweiten Methode ist die Vorgehensweise ähnlich. In C ++ kann eine DLL zur Laufzeit mit der Funktion LoadLibrary() in den Prozess eingebunden werden. Die exportierten Funktionen können unter Angaben des Funktionsnamens mittels GetProcAddress() geladen. Wird die DLL nicht mehr benötigt, so kann sie mittels FreeLibrary freigegeben werden. Die verwendeten Methoden sind windowsspezifisch. Unter UNIX/Linux stehen die Funktionen dlopen(), dlsym() und dlclose() zur Verfügung. Der größte Vorteil beim Laden zur Laufzeit ist, dass die DLL nur für die Zeit ihrer Verwendung geladen wird. Beim Einbinden zur Compile-Zeit ist die DLL für die gesamte Programmlaufzeit geladen. Dazu kommt, dass bei der Kompilierung die LIB-Datei benötigt wird, welche Compilerspezifisch ist. 19

20 KAPITEL 6. IMPLEMENTIERUNG 6.2.3 Referenzzählung Normalerweise sollte man die Referenzzählung in C ++ nicht anwenden. Für geteilte Ressourcen existiert dafür nämlich der std::shared_ptr. Jedoch gibt es manchmal Szenarien wo man auf das Referenzzählen nicht verzichten kann. Beispielsweise mussten für die Geometrie- und Material- Objekte die Referenzzählung angewendet werden, da diese Objekte über eine C-Schnittstelle erstellt und dann an einem Wrapper übergeben werden. Sobald der Destruktor des Wrappers aufgerufen wird, so gibt der das Objekt frei. Somit wird garantiert, dass die erstellten Objekte immer freigegeben werden und keine Speicherlecks entstehen können. Da aber Material- und Geometrieobjekte auch zu einem Körperobjekt hinzugefügt werden können, wäre es möglich, dass der Wrapper das Objekt zu früh freigibt. Deshalb wird für jede Referenz der Zähler um Eins erhöht. Wird das Objekt freigegeben so, wird der Zähler um Eins verringert. Ist dieser bei Null angelangt, so wird die Ressource endgültig freigegeben. 6.3 PhysicWrapper Die PhysicWrapper API erfüllt die Voraussetzungen für die binäre Kompatibilität und unterstützt das Laden zur Laufzeit. Für die Verwendung in C ++ stehen sogenannte Wrapper und eine Hilfsklasse für das Laden zur Laufzeit zur Verfügung. Dadurch wird das ursprüngliche objektorientierte Design wiederhergestellt. 6.3.1 Kollisionsgeometrie Folgende Kollisionsgeometrien werden von dem PhysicWrapper unterstützt: Box Kugel Dreiecksnetz Konvexe Hülle Fläche Das Dreiecksnetz und die Fläche können nur für nicht-dynamische Körper verwendet werden. 6.3.2 Komplexe Geometrien für dynamische Körper Beim Einsatz von komplexen Geometrien, also nicht-konvexen Objekten, muss die Geometrie vorher vereinfacht werden. Eine Möglichkeit ist die Vereinfachung durch eine konvexe Hülle. Ist dies zu ungenau so kann die Geometrie in mehrere konvexe Hüllen zerlegt werden. Beide Methoden werden vom PhysicWrapper zur Verfügung gestellt. Für die konvexe Zerlegung wird die Bibliothek V-HACD [5] von Khaled Mamou eingesetzt und für die Berechnung der konvexen Hülle wird der QuickHull Algorithmus angewandt. Dadurch, dass PhysX die maximale Anzahl an konvexen Polygonen auf 255 beschränkt, müssen die konvexen Hüllen zusätzlich reduziert werden. Für die Reduzierung wurde die 3D Mesh Decimation [4] Klasse ebenfalls von Khaled Mamou verwendet. Abb. 7.1 zeigt die nötigen Schritte für die Umwandlung komplexer Geometrien.

6.4. OBJEKTORIENTIERTE PLUGIN BENUTZEROBERFLÄCHE 21 Abbildung 6.1: Umwanldungsprozess für komplexe Geometrien 6.4 Objektorientierte Plugin Benutzeroberfläche Die Plug-in Programmierung für den Viz-Artist lässt sich in Registratur und Instanziierung einteilen. Die Registrierung erfolgt einmalig beim Start vom Viz-Artist. Im Registrierungsvorgang wird der Name des Plug-ins, die Version und zusätzliche Information an dem Viz-Artist übergeben. Im selben Schritt wird die Benutzeroberfläche erstellt. Die Plug-in Instanziierung erfolgt, sobald ein Plug-in in der Szene verwendet wird. Von Viz-Artist wird dafür ein vordefinierter Speicherbereich übergeben, welcher die Daten der UI-Elemente beinhaltet. Abb. 7.4 zeigt die Verbindung zwischen Registrierung sowie Instanziierung und wie die Daten der UI-Elmente auf den Speicherbereich abgebildet werden. Um beide Vorgänge zu vereinfachen, wurde ein objektorientiertes Template-Design entwickelt. Dafür wurde für jedes UI-Element ein eigener Wrapper entwickelt. Die UI-Elemente können durch Container zusammengefasst werden. Dies erleichtert das Ein- bzw. Ausblenden der Elemente bei Statusänderungen. Eine weitere Klasse fasst alle UI- Elemente zusammen und führt den Registrierungsvorgang durch. Bei der Instanziierung wird dieses Objekt an das jeweilige Plug-in übergeben. Abbildung 6.2: Plug-in Datenlayout 6.4.1 Visualisierung Motivation Die Visualisierung von physikalischen Effekten in Echtzeit benötigten viel Optimierung. Einfache Simulationen können vom Programm selbst dargestellt werden. Allerdings wäre eine Darstellung in Echtzeit bei Simulationen mit hunderten Objekten ohne Optimierung unmöglich. Da dies nur für Physiksimulationen benötigt wird, wäre es nicht sinnvoll dies in die Grafik-Architektur vom Viz-Artist zu integrieren. Deshalb wurde die Visualisierung in den PhysicWrapper implementiert.

22 KAPITEL 6. IMPLEMENTIERUNG Dadurch ist der physikalische Teil komplett abgekoppelt. Verwendung In jedem Zeichenaufruf des Programms wird auch die Zeichenfunktion des PhysicWrappers aufgerufen. Dafür wird nur der aktive OpenGL Kontext und die Kameraeinstellung benötigt. Aussicht Zurzeit besteht die Visualisierung nur aus der Darstellung der Kollisionsgeometrie. Eine Möglichkeit für die Optimierung wäre die Verwendung von Instancing, womit mehrere Objekte mit derselben Geometrie unter einem Aufruf gezeichnet werden können.

Kapitel 7 Resultate 7.1 Umwandlung komplexer Geometrie Abb. 7.1 zeigt die unterschiedlichen Methoden für die Umwandlung von komplexen Objekten. Die Kollisionsgeometrien in Abb. 7.1a und Abb 7.1b können für alle Körper verwendet werden. Das Dreiecksnetz in Abb. 7.1c ist nur für statische/kinematische Körper nutzbar. (a) Konvexe Zerlegung (b) Konvexe Hülle (c) Dreiecksnetz (d) Original Abbildung 7.1: Umwandlung von komplexen Objekten 23

24 KAPITEL 7. RESULTATE 7.2 Plug-ins 7.2.1 Rigidbody Plug-in Das Rigidbody Plug-in war das eigentliche Hauptziel dieser Bachelorarbeit. Mit diesem Plugin können verschiedene Kollisionsgeometrien, materialspezifische Parameter und die Art der Simulation gewählt werden. (a) Statischer Körper (b) Dynamischer Körper Abbildung 7.2: Benutzeroberfläche Abbildung 7.3: Demo Benutzeroberfläche und Verwendung Abb. 7.2 zeigt die Benutzeroberfläche, die für das Rigidbody Plug-in entwickelt wurde. Für die Reibung, Elastizität und die Dichte stehen vordefinierte Werte zur Verfügung, welche die Bedienung erleichtern. Falls diese nicht ausreichen, können auch benutzerdefinierte Werte gesetzt werden. Wählt man eine Box beziehungsweise eine Kugel als Kollisionsgeometrie aus, so hat man die Möglichkeit die Dimension/den Radius manuell oder automatisch zu wählen. Im automatischen Modus wird der dreidimensionale Rahmen (Bounding-Box) der Geometrie verwendet. Bei der Auswahl eines dynamischen Körpers erscheinen zusätzliche Optionen: Dichte, initiale Geschwindigkeit, initiale Winkelgeschwindigkeit und die Option zum Abschalten der Gravitation. Zusätzlich verschwindet die Option zur Auswahl der Fläche als Kollisionskörper.

7.2. PLUG-INS 25 Der Kollisionskörper Mesh verwendet für statische/kinematische Körper ein Dreiecksnetz und für dynamische Körper wird die Geometrie in konvexe Hüllen zerlegt. Da die Zerlegung eine gewisse Zeit in Anspruch nimmt und die Benutzeroberfläche dadurch nicht ansprechbar wäre, erfolgt dieser Vorgang im Hintergrund. 7.2.2 Kinematic Platform Plug-in Dieses Plug-in soll die Funktionalität der kinematischen Körper demonstrieren. Das Plug-in erzeugt einen kinematischen Körper und verwendet als Kollisionsgeometrie eine konvexe Hülle. Dieser Körper wird dann eine gewisse Zeit in eine vorgegebene Richtung und wieder zurück bewegt, ähnlich wie bei einem Aufzug. Dabei sind Richtung, Geschwindigkeit und Länge frei wählbar. 7.2.3 Canon Plug-in Das dritte und zurzeit letzte Plug-in ist das Canon Plug-in. Es soll die Visualisierung mittels PhysicWrapper demonstrieren. Dabei wird in einem vorgegebenen Zeitintervall ein dynamischer Körper mit einer Kugel als Kollisionsgeometrie erzeugt. Dieser Körper erhält zusätzlich eine initiale Geschwindigkeit. Nach einer gewissen Zeit wird der Körper dann aus der Szene genommen. Im Benutzerinterface kann Intervall, Lebenszeit, Geschwindigkeit sowie der Radius frei gewählt werden. Abbildung 7.4: Canon Plug-in Demo

26 KAPITEL 7. RESULTATE

Kapitel 8 Schlussfolgerung 8.1 Zusammenfassung Die Evaluation zeigte, dass die einzelnen Physik-Engines bei der Simulation von starren Körpern in Puncto Funktionalität und Qualität nahezu ident sind. Wird nur diese Simulationsart benötigt, so bietet sich die Newton Dynamics Engine an. Benötigt man jedoch mehr Funktionalität so steht die Bullet und PhysX zur Auswahl. Für diese Bachelorarbeit stellte sich heraus, dass sich die PhysX Engine am besten eignet. Der Grund dafür ist, dass der Viz-Artist für die Grafikkarten von Nvidia ausgelegt ist. Deshalb ist die Hardwarebeschleunigung mittels CUDA vom Vorteil. Wäre dies nicht der Fall, so würde die Wahl auf Bullet fallen: Die Berechnungen werden mit OpenCL durchgeführt und dadurch können auch andere Grafikkarten genutzt werden. Mit dem neuen objektorientierten Plug-in System erleichtert sich die Plug-in Entwicklung um einiges. Beispielsweise wurden die Plug-ins Kinematic Platform sowie Conon in nur wenigen Stunden erstellt. 8.2 Aussicht 8.2.1 Bewegungsunschärfe Auch die sogenannte Bewegungsunschärfe wäre eine mögliche Erweiterung. Dabei werden schnelle Objekte unscharf dargestellt. In der Abb.8.1 wird dieser Effekt graphisch dargestellt. (a) Ohne Bewegungsunschärfe (b) Mit Bewegungsunschärfe Abbildung 8.1: Bewegungsunschärfe [6] 8.2.2 Erweiterungen Dieses Projekt befasste sich nur mit der Physik von starren Körpern. Gelenke und Motoren wurden noch nicht implementiert. Die Erweiterung auf Partikelsysteme wäre ebenfalls interessant. Damit ließen sich Effekte wie Rauch, Feuer und sogar Flüssigkeiten erzeugen. Für die 27

28 KAPITEL 8. SCHLUSSFOLGERUNG Berechnung der Partikel kann in PhysX die GPU verwendet werden. Mit der sogenannten Graphics Interoperability von CUDA kann die Partikel-Struktur nach der Berechnung direkt für die Visualisierung hergenommen werden. 8.2.3 Geometrieumwandlung auf der GPU Die Umwandlung der komplexen Geometrien findet zurzeit nur auf der CPU statt. Würde man die Berechnung auf die GPU verlagern, so ließe sich die Umwandlungszeit drastisch verkürzen. Für V-HACD gibt es bereits eine Implementierung in OpenCL. Dabei wurde bereits eine Beschleunigung von 30-50% gemessen.

Literaturverzeichnis [1] Adrian Boeing and Thomas Bräunl. Evaluation of real-time physics simulation systems. In Proceedings of the 5th International Conference on Computer Graphics and Interactive Techniques in Australia and Southeast Asia, GRAPHITE 07, pages 281 288, New York, NY, USA, 2007. ACM. [2] Bullet. http://bulletphysics.org/wordpress/, 2016. Aufgerufen am Juni 18, 2016. [3] Havok. http://www.havok.com/, 2016. Aufgerufen am Juni 18, 2016. [4] Khaled Mamou. Mesh-decimation. https://github.com/kmammou/meshdecimation, 2016. Aufgerufen am Juni 18, 2016. [5] Khaled Mamou. Volumetric-hierarchical approximate convex decomposition. https:// github.com/kmammou/v-hacd, 2016. Aufgerufen am Juni 18, 2016. [6] Bewegungsunschärfe. http://modo.docs.thefoundry.co.uk/modo/701/help/pages/ shaderendering/cameraitem.html, 2016. Aufgerufen am Juni 18, 2016. [7] Newton. http://newtondynamics.com/forum/newton.php, 2016. Aufgerufen am Juni 18, 2016. [8] Open dynamics engine. http://www.ode.org/, 2016. Aufgerufen am Juni 18, 2016. [9] Physics abstraction layer. http://www.adrianboeing.com/pal/index.html, 2016. Aufgerufen am Juni 18, 2016. [10] Physics engine evaluation lab. http://www.codercorner.com/blog/?p=748, 2016. Aufgerufen am Juni 18, 2016. [11] Physx. https://developer.nvidia.com/physx-sdk, 2016. Aufgerufen am Juni 18, 2016. [12] Simple physics engine. http://spehome.com/, 2016. Aufgerufen am Juni 18, 2016. [13] Tokamak physics engine. https://sourceforge.net/projects/tokamakp/, 2016. Aufgerufen am Juni 18, 2016. [14] True axis. http://trueaxis.com/physics/index.html, 2016. Aufgerufen am Juni 18, 2016. [15] Viz-artist. http://www.vizrt.com/products/viz_artist/, 2016. Aufgerufen am Juni 18, 2016. [16] Vizrt. http://www.vizrt.com/, 2016. Aufgerufen am Juni 18, 2016. 29

30 LITERATURVERZEICHNIS

Abbildungsverzeichnis 4.1 Plug-in Use-Cases................................... 13 4.2 Plug-in System..................................... 14 4.3 Komponenten...................................... 14 4.4 Prototyp für die Benutzeroberfläche......................... 15 5.1 Konvexe Zerlegung [5]................................. 17 6.1 Umwanldungsprozess für komplexe Geometrien................... 21 6.2 Plug-in Datenlayout.................................. 21 7.1 Umwandlung von komplexen Objekten........................ 23 7.2 Benutzeroberfläche................................... 24 7.3 Demo.......................................... 24 7.4 Canon Plug-in Demo.................................. 25 8.1 Bewegungsunschärfe [6]................................ 27 31

32 ABBILDUNGSVERZEICHNIS

Tabellenverzeichnis 3.1 Anforderungen an die Physik Engine......................... 7 3.2 Evaluation: Allgemeines................................ 9 3.3 Evaluation: Simulationsarten............................. 9 3.4 Evaluation: Kollisionsgeometrien........................... 9 3.5 Evaluation: Gelenke und Motoren........................... 9 3.6 Evaluation: Hardwarebeschleunigung......................... 10 33