OpenTP. HOCHSCHULE TRIER Trier University of Applied Sciences Informatik - Computer Science. Entwicklung eines Textur Atlas Generators

Transkript

1 HOCHSCHULE TRIER Trier University of Applied Sciences Informatik - Computer Science OpenTP Entwicklung eines Textur Atlas Generators Christopher Kaster Hausarbeit zur Vorlesung Tool- und Pluginprogrammierung Betreuer: Prof. Dr. Christof Rezk-Salama, Dipl.-Inf. Trier, 3. Oktober 2013

2 Inhaltsverzeichnis 1 Motivation und Lösungsansatz Einleitung Lösungsansatz Anforderungen Der Algorithmus Der Prototyp Die Software Implementierung Entwurf des Algorithmus Algorithmus als Pseudo-Code Implementierung des Prototypen Erste Optimierungen Weitere Optimierungen Implementierung der Software Konklusion Anhang Danksagungen Links Quellen

3 1 Motivation und Lösungsansatz 1.1 Einleitung Ein Textur Atlas ist eine Sammlung von mehreren kleinen Grafiken, welche zu einer großen Grafik zusammengesetzt werden. In einer Applikation die oft mehrere kleinere Texturen benötigt ist das Benutzen von Textur Atlanten oft effizienter, da diese von der Grafikkarte als eine einzige Einheit behandelt werden. Aus dem Textur Atlas lesen und rendern lassen sich die Grafiken meistens über eine seperate Datei, welche Informationen über Position und Größe der jeweiligen Textur beinhaltet. Die Aufgabe eines Textur Atlas Generators besteht darin eine Sammlung von kleinen Grafiken möglichst effizient in einen oder mehrere Textur Atlanten zu packen. Es gibt bereits einige Textur Atlas Generatoren, jedoch sind diese meistens proprietär, lediglich auf der Windows Plattform verfügbar und/oder besitzen keine Möglichkeit als Tool in eine Content Pipeline eingebunden zu werden (Da diese Tools oft nur eine Grafische Benutzeroberflächen besitzen, jedoch kein Command- Line Interface zur Verfügung stellen). 1.2 Lösungsansatz Die Entwicklung eines eigenen Tools schien im Rahmen dieser Projektarbeit die beste Idee zu sein. Dieses Tool soll unter einer freien Lizenz auf einer Plattform wie z.b. Github 1 veröffentlicht werden, auf allen gängigen Betriebssystemen verfügbar sein (Windows, Linux und OS X) und ein Command-Line Interface besitzen, welches in einer Content Pipeline automatisiert verwenden kann. Wünschenswert wäre außerdem ein selbstentwickelter Algorithmus, welcher möglichst einfach, intuitiv verständlich und möglichst schnell ist (Wartezeiten von mehr als 1-2 Sekunden sollten vermieden werden). Aus Gründen der Einfachheit bietet sich eine Implementierung in der Programmiersprache Python an. Unter Gesichtspunkten der schnelleren Ausführungszeit wäre eine Implementierung in C++ jedoch vermutlich besser geeignet. 1

4 2 Anforderungen 2.1 Der Algorithmus Der Algorithmus soll folgende Anforderungen erfüllen: Einfach verständlich Intuitiv Alle Texturen in einem angegebenen Verzeichnis erkennen Texturen möglichst platzsparend im Atlas anbringen Generieren einer Datei welche Informationen über Position und Größe der einzelnen Texturen beinhaltet. 2.2 Der Prototyp Da sich die Programmiersprache Python sehr gut für Rapid Application Development eignet, fiel die Entscheidung leicht diese Sprache für die Entwicklung eines Prototypen zu benutzen. Der Prototyp soll folgende Anforderungen erfüllen: Erste Implementierung des Algorithmus Prototyp sollte einen Umfang von etwa 200 Zeilen Code haben. Eine annehmbare Ausführungszeit, erste Optimierungen sollten also bereits vorhanden sein Kein Command-Line Interface, Testwerte werden über konstante Werte geladen Funktionsfähige Generierung von Textur Atlanten Dateiformat in XML und JSON

5 2.3 Die Software Die Software Ohne eine schnelle Ausführungszeit ist dieses Tool für den Gebrauch in einer Content Pipeline nutzlos, daher eignet sich für die Implementierung die Programmiersprache C++ besonders gut. Die Software soll folgende Anforderungen erfüllen: Wahl einer geeigneten freien Lizenz Da bei Open Source Tools die Mitentwicklung von dritten Personen erwünscht ist sollte es möglich sein die meisten IDEs 1 zur Entwicklung zu benutzen Einfache Möglichkeit das Projekt auf verschiedenen Plattformen zu kompillieren Das Tool sollte ein funktionierendes Command-Line Interface besitzen Schnelle Ausführungszeit (Optimalerweise weniger als 2 Sekunden 2 ) 1 Integrated Development Environment, z.b. Visual Studio, Eclipse, Xcode oder Code::Blocks 2 Weniger als 2 Sekunden bei der Generierung der Textur Atlanten aus 300 Texturen auf einem handelsüblichen Notebook.

6 3 Implementierung 3.1 Entwurf des Algorithmus Zunächst sieht sich der Algorithmus alle Texturen in einem spezifizierten Verzeichnis an, merkt sich den Namen der Grafik, und ihre Größe und fügt diese Informationen als Objekt verpackt in eine Liste, dies wird für jedes Bild wiederholt. Sobald alle Bilder abgearbeitet sind, wird die zuvor genannte Liste sortiert, Maßgeblich ist hier die Anzahl der von der jeweiligen Textur konsumierten Pixel (Die Anzahl der konsumierten Pixel erhält man durch die Multiplikation zwischen Breite und Höhe der Textur). Anschließend wird eine Schleife so lange durchlaufen, bis die Kardinalität der zuvor genannten Liste gleich 0 ist. Innerhalb dieser Schleife wird eine neue leere Textur erzeugt gefolgt von einer Datenstruktur, die einer zweidimensionalen Matrix nachempfunden ist. Diese Matrix repräsentiert jeden Pixel innerhalb der neuen Textur und zeigt an, ob dieser bereits belegt ist. Als nächstes folgen zwei Schleifen, welche jeden Pixel in der neuen Matrix durchgehen und für jede Grafik prüfen, ob diese an die folgende Stelle passt. Ist dem so, wird die aktuelle Grafik in die Atlas Textur kopiert, die Positionen in der Matrix als belegt markiert und die Grafik aus der Liste entfernt. Dieser Vorgang wird solange wiederholt, bis der letzte Pixel des Atlanten erreicht ist. Nun wird der gefüllte Atlas auf die Festplatte gespeichert (An eine vom Benutzer definierte Position). Sollte die Liste noch Elemente beinhalten, folgt nun eine weitere Iteration der äußersten Schleife, welche zugleich eine neue leere Textur erstellt und die Matrix zurücksetzt. Sobald die Liste leer ist endet die Ausführung des Algorithmus.

7 3.1 Entwurf des Algorithmus Algorithmus als Pseudo-Code 1 f u n c t i o n g e n e r a t e a t l a s ( ) { 2 // get a l l t e x t u r e s from a s s e t s / t e x t u r e s 3 var supported images : L i s t <Image> = g e t s u p p o r t e d i m a g e s ( 4 a s s e t s / t e x t u r e s ) ; 5 6 // s o r t the l i s t by consumed p i x e l s ( image. width image. h e i g h t ) 7 supported images = s o r t b y a m o u n t o f p i x e l s c o n s u m e d ( supported images ) ; 8 9 var a t l a s c o u n t e r : I n t = 0 ; // s p e c i f i y a t l a s s i z e 12 var a t l a s w i d t h : I n t = ; 13 var a t l a s h e i g h t : I n t = w h i l e ( supported images. l e n g t h ( ) > 0) { 16 // c r e a t e new empty Image 17 a t l a s = new Image ( a t l a s w i d t h, a t l a s h e i g h t ) ; // c r e a t e matrix and f i l l i t with f a l s e 20 var matrix : Array<Bool >; 21 memset ( matrix, f a l s e, a t l a s w i d t h a t l a s h e i g h t ) ; f o r ( var y : I n t = 0 ; y < a t l a s h e i g h t ; y++) { 24 f o r ( var x : I n t = 0 ; x < a t l a s w i d t h ; x++) { // i f x, y i s s e t t r u e i n the matrix, c o n t i n u e 27 i f ( i s o c c u p i e d ( matrix, x, y ) ) { 28 c o n t i n u e ; 29 } f o r ( img i n supported images ) { // i f image f i t s at the c u r r e n t p o s i t i o n 34 i f ( i m a g e f i t s ( matrix, img, x, y ) ) { 35 // p a s t e img i n t o a t l a s 36 a t l a s. p a s t e ( img, x, y ) ; 37 // s e t the occupied p i x e l s to t r u e 38 s e t o c c u p i e d ( matrix, x, y, img. width, img. h e i g h t ) ; // remove element from l i s t 41 supported images. remove ( img ) ; 42 } 43 } 44 } 45 } // t h i s a t l a s i s f u l l, save i t 48 a t l a s. save ( a s s e t s / a t l a s / a t l a s + ( a t l a s c o u n t e r++) +. png ) ; 49 } 50 }

8 3.2 Implementierung des Prototypen Implementierung des Prototypen Für die Entwicklung des Prototypen entschied ich mich für die Programmiersprache Python, da ihre einfache Syntax und die sehr mächtige Standard-Bibliothek mir erlaubte möglichst schnell einen funktionsfähigen Prototypen zu entwickeln. Eine Image Processing Bibliothek ist leider nicht in der Standard-Bibliothek enthalten, hier entschied ich mich für die Python Image Library (PIL) 1. Dank Python und PIL war ich in der Lage den Algorithmus innerhalb weniger Stunden funktionsfähig umzusetzen, jedoch kamen dabei bereits die ersten Probleme auf. Der Algorithmus war langsam, die ersten Ausführungszeiten varierten in einem Bereich von vier bis fünf Stunden 2, bei etwa 300 Texturen auf meinem System Erste Optimierungen Ich fing an, an dem Algorithmus zu zweifeln, ob es nicht vielleicht besser wäre, einen in der Praxis bewährten Algorithmus zu verwenden. Jedoch entschied ich mich stattdessen die Ursache der schlechten Performance zu finden. Zuerst habe ich die Matrix Datenstruktur, welche zu diesem Zeitpunkt ein normales Python Array war, in ein array 4 umgewandelt. Diese Array Implementierung verspricht eine hohe Effizienz bei der Verwendung von numerischen Werten, welche durch die Verwendung von C-Typen erreicht wird. Dies hatte jedoch nicht zu einer erkennbaren Performance Steigerung geführt (Im Schnitt habe ich wenige Minute gewonnen). Als nächstes habe ich verschiedene Aktionen mit print-befehlen versehen, welche mir den Zeitverbrauch einer jeweiligen Aktion ausgeben. Mit die meiste Zeit wurde während dem Iterieren der Zeilen während der Methode image fits verbraucht. Diese Methode iteriert durch die Matrix Datenstruktur und schaut ob, die Textur, die der Algorithmus momentan auf den Atlas kopieren will, auch passen würde. Diese Aktion wird für jeden Pixel und jede Textur einmal durchlaufen, was bei einem Atlas mit der Größe 512x512 und 300 Texturen zu Iterationen führen würde. Es ist also wichtig, dass diese Operation so selten wie möglich aufgerufen wird. Die Methode prüft, ob ein Bild auch wirklich Pixelgenau an die angegebene Position passen würde. Also entschied ich mich eine einfache Approximation zu versuchen: Passt das Bild überhaupt noch an die aktuelle Position? Übersteigt (ausgehend von der aktuellen Position) die Breite die Kapazität des Atlanten? 1 i f x + image. width > a t l a s s i z e w i d t h : 2 c o n t i n u e 1 Python Image Library (PIL): 2 Hierbei handelt es sich um Hochrechnungen: Ich habe die Zeit pro Textur gemessen nach einer Laufzeit von 10 Minuten und aus diesen Daten eine Hochrechnung erstellt. 3 MacBook Pro 13 inch 8.1, Intel Core i5 4

9 3.2 Implementierung des Prototypen 7 Dieses kleine Code-Schnipsel führte dazu das die Ausführungszeit auf meinem System (Texturen sind gleich geblieben) von durschnittlich vier bis fünf Stunden auf etwa 100 Sekunden gesunken ist Weitere Optimierungen Ein erster Schritt war getan, verständlicherweise sind 100 Sekunden immer noch nicht genug. Als erstes fing ich mit einer weiteren kleinen Optimierung an, die Grundsätzlich auf der letzten basiert. Ich prüfe ob ein Bild noch in die x-achse passt, das gleiche lässt sich natürlich auch auf die y-achse anwenden: 1 i f y + image. h e i g h t > a t l a s s i z e h e i g h t : 2 c o n t i n u e Um die Anzahl der image fits Aufrufe weiter zu reduzieren, kopiere ich die Liste, welche die zu prüfenden Texturen beinhaltet, zur gleichen Zeit wie die Matrix- Datenstruktur erzeugt wird und verändere die Abfrage von eben wie folgt: 1 i f y + image. h e i g h t > a t l a s s i z e h e i g h t : 2 images. remove ( image ) # the c o p i ed l i s t 3 c o n t i n u e Statt nun durch die eigentliche Liste zu iterieren, wird stattdessen die kopierte Liste durchlaufen, welche je länger der Algorithmus läuft immer kleiner wird. Ein Bild das nicht mehr in die Y-Koordinate passt, wird auf dem aktuellen Atlanten definitiv keinen Platz mehr finden. Dies spart also einige unnütze Iterationen. Da ich die Bilder nicht im Speicher lassen will, habe ich diese bis zu diesem Zeitpunkt immer nach Bedarf von der Festplatte geladen, ihre Größe gelesen und wieder vom Garbage Collector löschen lassen. Dies erschien relativ schnell zu sein, weswegen ich mich bis jetzt nicht darum gekümmert habe. Statt nun die Bilder immer wieder von der Festplatte zu laden, habe ich eine Datenstruktur geschrieben, welche die Maße jeder Textur beinhaltet, diese jedoch nicht nachladen muss. Während der Algorithmus anfangs nach Bildern in einem Verzeichnis sucht, werden Objekte dieser Datenstruktur erzeugt und in einer Liste gespeichert (In dieser Liste waren zuvor die Pfade der Texturen). Jedes Bild wird dadurch nur noch 2 mal in den Speicher geladen: Einmal am Anfang, um ein Objekt der Datenstruktur zu erzeugen und ein zweites mal, um das Bild in den Atlas zu kopieren. Diese Optimierung führte zu einem deutlichen Performance Gewinn auf meinem System mit den selben 300 Texturen wurde eine Ausführungszeit von durschnittlich 5 Sekunden erreicht. Ich hatte Hoffnungen, dass eine C++ Portierung in einem weiteren Performanceschub resultieren würde, daher habe ich ab diesem Zeitpunkt die Entwicklung des Prototypen gestoppt.

10 3.3 Implementierung der Software Implementierung der Software Um meinen Anforderungen gerecht zu werden, musste ich ein Tool finden, welches mir erlaubt Projektdateien für bestimmte Entwicklungsumgebungen zu generieren, sodass dieses Projekt unabhängig vom Betriebssystem kompilliert werden kann. Die Wahl fiel hier auf das Cross-Platform Build Tool CMake 5. Als erstes brauchte ich eine neue Image Processing Bibliothek. Meine Wahl fiel hier auf CImg 6, da diese für ihre Standardfunktionalität keine Abhängigkeiten besitzt. Während dem portieren fiel mir auf, dass C++ in seiner Standard-Bibliothek keine Möglichkeit besitzt plattformunabhängig Pfade zu verwalten. Dies lies sich jedoch mit dem filesystem Modul der boost 7 Bibliothek lösen. Die Portierung verlief weitestgehend ohne größere Probleme und das Tool lief erwartet gut auf OS X. Die durschnittliche Ausführungszeit ist auf meinem System von durschnittlich fünf Sekunden auf durschnittlich 0.9 Sekunden gesunken. Nun musste ich das Tool natürlich auch auf anderen Betriebssystemen testen, falls nötig, um Anpassungen machen zu können. Da ich das Projekt bis jetzt primär auf OS X entwickelt habe, entschied ich mich als erstes auf dem anderen größeren Unixioden System Linux die Funktionsfähigkeit zu prüfen. Anfangs gab es Komplikationen zwischen den Compilern. Der GNU Compiler benutzt Standardmäßig z.b. kein C++11, welches mit einem separaten Argument ( -std=c++0x ) mitteilen muss. Dank des fehlenden Paket Managers erwies sich alleine das Kompillieren auf der Windows Plattform als umständlich. Alle von mir benötigten Bibliotheken müssen seperat heruntergeladen und selbst kompilliert werden. Das Command-Line Interface habe ich mit dem boost-modul program options realisiert, welches mir erlaubt mit relativ wenig Aufwand ein sehr mächtiges CLI zu entwickeln. Das Projekt habe ich zu diesem Zeitpunkt unter der MIT Lizenz 8 auf Github veröffentlicht ( 5 CMake: 6 CImg: 7 Boost library: 8 MIT Lizenz:

11 4 Konklusion Ich habe das Tool bereits erfolgreich in meine Content Pipeline integriert. Der Algorithmus erkennt zuverlässig Texturen in einem angegebenen Verzeichnis, ordnet diese relativ platzsparend in einer neuen Textur an und generiert eine XML Datei welche Informationen zu Position und Maße der einzelnen Texturen beinhaltet.

12 5 Anhang 5.1 Danksagungen Vielen Dank an folgende Personen für ihre Unterstützung. Michael Peter Kick Ricardo Helms Ben Raus 5.2 Links OpenTP Github Repository Quellen Wikipedia