Konzept und Design einer generischen Asset-Pipeline für 3D

Transcrição

Konzept und Design einer generischen
Asset-Pipeline für 3D-Games
Jan-Felix Wall
DIPLOMARBEIT
eingereicht am
Fachhochschul-Masterstudiengang
Digitale Medien
in Hagenberg
im September 2009
© Copyright 2009 Jan-Felix Wall
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Hagenberg, am 19. September 2009
Jan-Felix Wall
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
ix
1 Einleitung
1.1 Hintergrund und Motivation . . . . . . . . . . . . . . . . . . .
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
2 Vorbetrachtungen zum Thema
2.1 Vorhergehende Entwicklung . . . . . . . . . . . . . . . . . .
2.1.1 Besondere Anforderungen von Spielen . . . . . . . .
2.1.2 Die Situation an der FH-Hagenberg . . . . . . . . . .
2.2 Aufbau von Asset-Pipelines . . . . . . . . . . . . . . . . . .
2.2.1 Vergl. mit der Kompilierung in der SW-Entwicklung
2.2.2 Source-Engine als klassisches Beispiel . . . . . . . . .
2.2.2.1 Detaillierte Betrachtung der Model Pipeline
2.2.2.2 Überblick der sonstigen Assets . . . . . . .
2.2.3 Der Entwicklungsprozess bei Cogaen . . . . . . . . .
2.2.3.1 Einbindung von 3D-Daten . . . . . . . . . .
2.2.3.2 Levelerstellung . . . . . . . . . . . . . . . .
2.2.3.3 Direkte Folgerungen aus den Problemen . .
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
6
6
8
8
10
11
11
12
13
3 Asset-Pipelines
3.1 Pipeline Anforderungen . . . . . . .
3.1.1 Contenterstellung . . . . . . .
3.1.2 Anbindung des Contents . . .
3.2 Asset Workflow . . . . . . . . . . . .
3.2.1 Kollaboration . . . . . . . . .
3.2.2 Versionsmanagement . . . . .
3.2.3 Automatisierung und Pipeline
.
.
.
.
.
.
.
15
15
16
17
18
18
19
20
iv
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Management
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
3.3
v
Analogien zu klassischen Pipelines . . . . . . . . . . . . . . .
3.3.1 3D-Animation . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.1 Kollaboration . . . . . . . . . . . . . . . . . .
3.3.1.2 Renderfarmen . . . . . . . . . . . . . . . . .
3.3.2 Verwendbare Technologien aus der Softwareentwicklung
3.3.2.1 Cross-Platform Development . . . . . . . . .
3.3.2.2 Versionsmanagement . . . . . . . . . . . . . .
3.3.2.3 Continuous Integration . . . . . . . . . . . .
3.3.2.4 Release Packaging . . . . . . . . . . . . . . .
3.3.3 Game Asset-Pipelines als Mischform . . . . . . . . . .
21
22
22
23
23
23
24
25
26
26
4 Konzeption
4.1 Wahl von Zwischenformaten . . . . . . . . . . . . . . . . . . .
4.1.1 Verschiedene Medien . . . . . . . . . . . . . . . . . . .
4.1.1.1 Grafik . . . . . . . . . . . . . . . . . . . . . .
4.1.1.2 Sound . . . . . . . . . . . . . . . . . . . . . .
4.1.1.3 Metadaten . . . . . . . . . . . . . . . . . . .
4.1.1.4 3D . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 COLLADA als zentrales Format . . . . . . . . . . . .
4.1.2.1 COLLADA ist standardisiert und Open-Source
4.1.2.2 Geeigneter und vielseitiger Aufbau . . . . . .
4.2 Tools zur Contenterstellung . . . . . . . . . . . . . . . . . . .
4.2.1 3D und Animation . . . . . . . . . . . . . . . . . . . .
4.2.2 2D-Grafik . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Sound . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Game-spezifisches . . . . . . . . . . . . . . . . . . . . .
4.2.4.1 Dedizierte Tools . . . . . . . . . . . . . . . .
4.2.4.2 Integration ins 3D-DCC-Tool . . . . . . . . .
4.3 Versionsverwaltung und Kollaboration . . . . . . . . . . . . .
4.3.1 Aufteilung der Projektstruktur . . . . . . . . . . . . .
4.3.1.1 Code Repositories . . . . . . . . . . . . . . .
4.3.1.2 Artist Workspace . . . . . . . . . . . . . . . .
4.3.1.3 Transferdaten der Pipeline . . . . . . . . . .
4.3.1.4 Runtime Repository . . . . . . . . . . . . . .
4.3.1.5 Dependencies und Tools . . . . . . . . . . . .
4.3.1.6 Projekt Repository . . . . . . . . . . . . . . .
4.4 Weiterverarbeitung der Assets . . . . . . . . . . . . . . . . . .
4.4.1 COLLADA in der Pipeline . . . . . . . . . . . . . . .
4.4.2 Automatisierte und ausgelagerte Verarbeitung . . . . .
4.4.2.1 Continuous Integration . . . . . . . . . . . .
4.4.2.2 Zentrale Buildsysteme . . . . . . . . . . . . .
4.4.3 Konfiguration, Verwaltung und Überwachung . . . . .
4.4.3.1 Buildsystem . . . . . . . . . . . . . . . . . .
4.4.3.2 Steuerung . . . . . . . . . . . . . . . . . . . .
27
27
27
28
29
29
30
31
31
31
33
34
34
35
35
36
38
39
39
40
40
41
41
42
42
43
43
44
45
46
47
47
48
Inhaltsverzeichnis
vi
5 Projektarbeit
5.1 Konzentration auf funktionale Schwerpunkte . .
5.1.1 Contenterstellung und Export . . . . . .
5.1.2 Weiterverarbeitung . . . . . . . . . . . .
5.1.3 Engineanbindung . . . . . . . . . . . . .
5.2 Beschreibung des Projektes . . . . . . . . . . .
5.2.1 Maya Plug-In für Kollisionskörper . . .
5.2.1.1 Maya im Überblick . . . . . . .
5.2.1.2 Implementierung des Plug-Ins
5.2.2 Anpassung des COLLADA-Exporters .
5.2.3 Refinery und Conditioner . . . . . . . .
5.3 Post-Mortem-Analyse des Projektes . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Schlussbetrachtung
A Inhalt der DVD
A.1 Masterarbeit . . . . . . . . . . . .
A.1.1 PDF-Dateien . . . . . . . .
A.1.2 Grafiken . . . . . . . . . . .
A.2 Projekt . . . . . . . . . . . . . . .
A.2.1 Binaries . . . . . . . . . . .
A.2.1.1 Windows . . . . .
A.2.1.2 Mac OS X . . . .
A.2.2 Testdaten . . . . . . . . . .
A.2.3 Quellen . . . . . . . . . . .
A.2.3.1 Visual Studio 2008
A.2.3.2 Xcode Projekte . .
Literaturverzeichnis
50
50
51
51
51
52
52
53
53
54
55
55
58
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Sulutions
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
60
60
60
60
60
60
61
62
62
62
62
63
Vorwort
Als Artist, im tendenziell sehr technischen Fachbereich Game Development,
gestaltete sich die Suche nach einem geeigneten Thema für die Masterarbeit
anfänglich schwierig. Einen hilfreichen Ansatz bot dabei die Frage nach dem
Grund für die allgemeine Unzufriedenheit im Studienalltag. Dabei zeigte sich
schnell, dass in den Projekten immer wieder viel Zeit damit verloren ging,
erstellte Assets an Änderungen der Engine anzupassen. Das Problem lag
darin, dass Cogaen, die an der FH-Hagenberg entwickelte und verwendete
Game-Engine über keinerlei Asset-Pipeline verfügt.
Dieser umfangreiche und interdisziplinäre Themenbereich ließ zwar keine
vollständige Implementierung im begleitenden Semesterprojekt zu, doch an
dieser Stelle fehlte selbst ein grundlegendes Konzept — ein solches Konzept
sollte also Thema der Arbeit werden.
Der Dank für direkte Beiträge zur Arbeit fällt an dieser Stelle kurz aus.
Besonders meine Mutter hat durch ihre Korrekturvorschläge viele grammatikalische Winkelzüge verhindert und so stark zur Lesbarkeit des Textes beigetragen.
Aber, wie so oft, liegen die Wurzeln des Erfolges weit entfernt. Ohne
Rémi Arnauds Vortrag auf der FMX 2008 hätte ein entscheidender Ansatzpunkt für weitere Recherchen gefehlt, ohne meinen Praktikumskollegen
Manuel Scherer hätte ich besagten Vortrag nie besucht; also Dank an beide,
auch wenn sie sich ihres Wirkens in keinster Weise bewusst sind.
Auch die Motivation ist entscheidend; während des Studiums und so letztlich auch für die Masterarbeit. Nicht zuletzt die hervorragende Zusammenarbeit im Game Development Kurs gab immer wieder neuen Antrieb und
Schwung, trotz aller Widrigkeiten nicht aufzugeben. Auch all jenen, die mir
in schweren Momenten beistanden, bin ich zu tiefem Dank verpflichtet: allen
voran Andrzej Kozlowski und Claus Helfenschneider.
An letzter und damit besonders exponierter Stelle, möchte ich schließlich
meinem Betreuer Roman Divotkey und meiner geschätzten Studienkollegin
Martina Karrer danken: Für die vielen Gespräche beim Mittagessen, die
sich mitunter zwar nur am Rande, oder gar weit abseits des Themas AssetPipelines bewegten, dennoch aber stets wichtige Impulse für die Arbeit setzten.
vii
Kurzfassung
Die Komplexität heutiger Computer- und Videospiele erfordert umfangreiche Systeme für die Verwaltung und Integration der benötigten Assets. Im
Gegensatz zur Verwaltung, existieren für die Engine-Anbindung keine umfassenden Standardlösungen, weshalb diese für jede Engine neu entwickelt
werden.
Das Ziel der vorliegenden Arbeit ist die Konzeption eines allgemeinen
Basissystems für Asset-Pipelines, welches sich durch entsprechende Module
leicht für die speziellen Anforderungen der jeweils verwendeten Engine adaptieren lässt. Die Grundidee besteht dabei in der Adaption bereits verfügbarer
Teillösungen.
Neben der naheliegenden Verwendung von COLLADA als zentrales Austauschformat wird dabei vor allem auf verschiedene Konzepte und Technologien aus der Softwareentwicklung zurückgegriffen.
Den konkreten Anwendungsfall des entwickelten Konzeptes bildet der
Aufbau einer Asset-Pipeline für die, an der FH-Hagenberg entwickelte Engine, Cogaen. Dies impliziert weitere Grundsätze in der Konzeption: Wegen des
derzeitigen Fehlens einer Asset-Pipeline, sollten sich, zumindest die Basisfunktionalitäten des Systems, schnell umsetzten lassen. Verbesserungen des
Workflows und der Integration können dagegen, durch den Austausch einzelner Module, in weiteren Entwicklungsschritten folgen. Da sich die Dauer
einzelner Teilprojekte dabei prinzipiell auf jeweils ein Semester beschränkt,
ist es wichtig, eventuelle Probleme mit den verwendeten Technologien im
Vorhinein zu identifizieren, um diese bei der jeweiligen Projektplanung entsprechend berücksichtigen zu können.
Zur Ermittlung entsprechender Erfahrungswerte dient dabei die erfolgte
Testimplementierung. Aus diesem Grunde zielt diese auch nicht auf einen
großen Funktionsaufwand ab, sondern auf den Einsatz möglichst aller unbekannten und damit kritischen Technologien.
viii
Abstract
The complexity of current computer and video games requires extensive systems for the management and integration of the needed assets. In contrast to
the management of content, no complete standard solutions are available for
the engine integration. Therefore, these Systems are developed from scratch
for every single engine.
The goal of the thesis at hand is the design of a generic base for asset
pipelines, which can be easily customized to meet the specific requirements
of the used game engine. One basic idea of this modular approach is to adopt
available partial solutions for the various aspects of the system.
Besides the rather obvious use of COLLADA as a central interchange
format, many concepts and technologies are adopted mainly from classic
software development.
The implementation of an asset pipeline for Cogaen is used as a concrete
use case of the presented concept. This game engine is developed at the
University of Applied Sciences Hagenberg and therefore implies some more
requirements for the concept: due to the lack of any asset pipeline for the
engine, a basic version of the system should be implemented as quick as
possible, while improvements of workflow and integration can be added in
future iterations.
The time frame of such sub-projects is generally limited to only one
semester. Therefore it is vital to know any potential problems that may
occur while using the various technologies and account for them early in the
project scheduling. The test implementation of the system is developed to
acquire the empirical values for such a scheduling. Because of that, it is
not designed for great functionality, but to make use of any unknown and
therefore critical technology that is involved in the system.
ix
Kapitel 1
Einleitung
Asset-Pipelines werden in der Spieleentwicklung allgemein wenig beachtet.
Dies ist schwer nachvollziehbar, denn die Asset-Pipeline stellt den einzigen
Anknüpfungspunkt des Artists an das Spiel dar. Somit ist sie für den Entwicklungsprozess eigentlich von zentraler Bedeutung und steht der Engine
und ihren verschiedenen Systemen — Rendering, Physik, KI, Sound etc. —
in keiner Weise nach.
Dennoch finden sich sehr wenige einschlägige Quellen und meist wird
das Thema nur in anderem Kontext, oft dem Multi-Platform-Development,
angeschnitten. Immerhin besteht dabei aber ein weitgegender Konsens über
den grundsätzlichen Aufbau von Asset-Pipelines: Eingangsdaten werden automatisch verarbeitet und schließlich in, für die Engine geeigneter Form,
wieder ausgegeben.
Die Implementierungen dieses einfachen Grundsatzes fallen dagegen sehr
vielseitig aus, doch abgesehen von den immer wieder gleichen Features, die
für jede Pipeline neu entwickelt werden, scheint ein grundsätzliches Problem in der allgemeinen Wahrnehmung des Themas zu liegen. Anders als
Engines, werden Asset-Pipelines meist monolitisch betrachtet. Hier erfolgt
oft nicht die, bei Engines übliche, Aufspaltung in verschiedene Teilbereiche,
die, von den jeweiligen Fachleuten, einzeln entwickelt werden. Nein, AssetPipelines werden stattdessen als ganzes der Toolentwicklung zugeschrieben,
häufig fehlt wohl auch jede Kommunikation mit der Contenterstellung (Zumindest die Interfaces mancher Tools lassen sich anders kaum erklären).
Dass Asset-Pipelines jedoch mindestens ebenso interdisziplinär, wie Spiele
und Engines sind, wird dabei regelmäßig unterschlagen.
1.1
Hintergrund und Motivation
Die Erfahrung mit verschiedenen Systemen zeigt, dass, wenn auch unterschiedlich implementiert, sich Funktionen und Arbeitsabläufe stets sehr ähneln und sogar die gleichen Probleme auftreten. Diese Feststellung drängt
1
1. Einleitung
2
die Frage auf, ob bestimmte Grundstrukturen von Asset-Pipelines vielleicht
doch vereinheitlicht werden können, um ein modulares Basissystem zu entwickeln. Dies böte den Vorteil, dass lediglich wenige Module für die konkrete Engine Implementierung angepasst werden müssen, während für alle
Standardfunktionen auf ein stabiles Framework zurückgegriffen werden kann.
Diese Überlegungen führen zur Idee einer generischen Asset-Pipeline.
Wie bereits angemerkt, decken Asset-Pipelines das gleiche, weite Feld
an Disziplinen, ab, wie dies auch bei Game-Engines der Fall ist. Dabei beschäftigen sie sich zwar nicht mit den verschiedenen Umsetzungen, wie der
verwendeten Rendering-Technik, der Art der Physiksimulation etc., sind in
ihrer konkreten Implementierung jedoch eng daran gebunden. Die AssetPipeline stellt die von den Systemen benötigten Daten bereit. Dies soll in
möglichst optimaler Form erfolgen, doch um dies zu erreichen, sind zur Umsetzung, in jedem Teilbereich, genaue Kenntnisse der Materie erforderlich.
Dies übersteigt wohl in den meisten Fällen die Fähigkeiten eines einzelnen
Entwicklers, aber auf jeden Fall den Umfang einer einzigen Masterarbeit und
der begleitenden Projektarbeit. Was an dieser Stelle also erfolgen kann, ist
nicht die Implementierung, sondern das Konzept und Design, eines solchen
modularen Frameworks.
Die Konzeption erfolgt dabei in erster Linie aus Sicht des Anwenders
— welche Funktionen sind wichtig, hilfreich oder wurden vielleicht immer
vermisst? Die verschiedenen Anforderungen ergeben sich dabei vorrangig
aus eigenen Erfahrungen und Gesprächen mit anderen Entwicklern. Viele
Feststellungen gründen auf der jahrelangen Beschäftigung mit der Contenterstellung für Spiele und lassen sich, in Ermangelung entsprechender Standardwerke, kaum durch konkrete Quellen belegen. Aus diesen Gründen mag
die Arbeit teilweise essayeske Züge aufweisen, bei einem theoretischen HighLevel-Concept erscheint dies jedoch weniger problematisch, als bei der Auseinandersetzung mit rein eindeutigen Fakten.
Die dabei entwickelten Lösungsvorschläge orientieren sich vor allem an
den, an der FH-Hagenberg, gegebenen Möglichkeiten zur Umsetzung. Dies
bezieht sich einerseits auf die vorhandenen Technologien, folgt darüber hinaus aber einem sehr pragmatischen Ansatz: Da die Game-Engine der FHHagenberg bisher über keine Asset-Pipeline verfügt, muss sich eine, zumindest minimale, Pipeline möglichst schnell umsetzen lassen. Dieses, dann bereits produktiv einsetzbare, System sollte in weiterer Folge erweitert und
verbessert werden können um schließlich die zeitgemäße Entwicklung von
Spielen zu ermöglichen.
1.2
Aufbau der Arbeit
Kapitel 2 dient dazu, ein grundsätzliches Verständnis der Materie aufzubauen
und die derzeitige Situation zu erklären. Eine detailliertere Beschreibung der
1. Einleitung
3
Funktionsweise von Asset-Pipelines folgt in Kapitel 3. Dies bildet die Grundlage für die anschließende Konzeption. Dabei liegt ein Hauptaugenmerk auf
der möglichen Adaption etablierter Systeme aus anderen Bereichen, die zu
diesem Zweck näher beschrieben und analysiert werden. In Kapitel 5 wird
schließlich die Projektarbeit beschrieben. Diese dient als Proof of Concept
der erarbeiteten Konzepte, wobei anschließend sowohl Erfolge als auch die
aufgetretenen Probleme erörtert werden.
Kapitel 2
Vorbetrachtungen zum Thema
Dieses Kapitel dient dem grundlegenden Verständnis von Asset-Pipelines.
Es verdeutlicht ihren grundlegenden Aufbau, die Gründe für die Verwendung
von Pipelines und bietet verschiedene Beispiele für die Integration von Assets
ins Spiel.
2.1
Vorhergehende Entwicklung
Asset-Pipelines sind heute ein zentraler Bestandteil des modernen, sogenannten Tool-Based Development von Computerspielen, welches mit dem wachsenden Umfang von Projekten zunehmend an Bedeutung gewinnt. In der
Pionierzeit wurden Computerspiele dagegen von wenigen, oft einzelnen Entwicklern programmiert, was sogar wörtlich zu nehmen ist. In weiterer Folge
kam zur Programmierung die Erstellung verschiedenster Assets, also vom
Spiel verwendeter Mediendaten hinzu. Dies erforderte, neben der Vergrößerung der Entwicklungsteams, die Notwendigkeit diesen Content in das Spiel
zu integrieren. Die Programme mussten die entsprechenden Daten also lesen und verarbeiten können. Aufgrund etablierter und verbreiteter Formate
für Bild- und Sounddaten, stellte sich dies zu Zeiten von 2D-Grafik noch
wenig problematisch dar, doch änderte sich dies mit dem Aufkommen von
3D-Engines grundsätzlich.
2.1.1
Besondere Anforderungen von Spielen
Die begrenzte Rechenleistung bedingt bei Spielen mitunter Daten, welche
mit den bei Film und Animation eingesetzten Tools schlicht nicht erstellbar
sind. Deshalb ist die Entwicklung spezieller Tools notwendig. Ein Beispiel
4
2. Vorbetrachtungen zum Thema
5
hierfür ist die CSG1 -basierte Levelgeometrie wie sie seit Quake 2 und Unreal 3
eingesetzt wird um verschiedene Formen Szenenmanagements zu ermöglichen
oder zu vereinfachen.
Doch auch generell eignen sich die nativen Datenformate typischer DCC4 Tools wie Maya 5 oder 3ds Max 6 , aufgrund ihres Aufbaus, nicht zur Verwendung in anderen Applikationen und das Fehlen geeigneter Standardformate
führte zu einem anhaltenden Wildwuchs proprietärer Lösungen.
Folglich bringt fast jede 3D-Engine ein Anzahl verschiedener Tools zur
Contenterstellung mit — In einfachsten Fällen beschränken sich diese auf Exporter für 3D-Meshes und Animationen, erstrecken sich jedoch häufig über
Level-Editoren bis hin zu grafischen Tools zur Erstellung von Shadern und
Materialien und vor allem auch einer automatisierten Pipeline zur Verarbeitung des erstellten Contents. Tatsächlich ist der Umfang des bereitgestellten
Toolsets der zentrale Punkt bei der Vermarktung von 3D-Engines.
2.1.2
Die Situation an der FH-Hagenberg
Betrachtet man die derzeitige Situation bei Cogaen 7 , zeigt sich ein zweigeteiltes Bild. Bei der Entwicklung der Engine wird stark auf einen modularen Aufbau gesetzt. Das heißt alle Teilsysteme werden durch allgemeine Interfaces gekapselt, wodurch sich die jeweilige Implementierung leicht
austauschen lässt. Dies bietet auf Seiten der Programmierung eine große
Flexibilität und macht das Projekt sowohl aus akademischer Sicht als auch
im Hinblick auf das, zunehmend an Bedeutung gewinnende, Multi-PlatformDevelopment sehr interessant. Jedoch wurde gleichzeitig die Assetanbindung,
konzeptionell und in ihrer Implementierung, bisher stark vernachlässigt, was
die Engine derzeit praktisch produktionsuntauglich macht.
Im Umgang mit Assets implementiert Cogaen lediglich die Grundfunktionen der verwendeten Middlewares, wie beispielsweise das Laden von 3DMeshes aus dem Dateisystem. Für spielspezifische Daten wie Levels, welche
eine komplexe Ansammlung von Einzelobjekten und Eigenschaften darstellen, bietet die Engine jedoch keine Unterstützung. Stattdessen wurde eine
Notlösung entwickelt. Bei dieser wird vom Level-Editing Tool, im konkreten Fall Maya, Code generiert, welcher die Funktionen zum Erstellen und
Platzieren der entsprechenden Objekte aufruft.
1
Constructive Solid Geometry, Konstruktive Festkörpergeometrie
Quake ist ein Ego-Shooter von id Software aus dem Jahre 1996
(http://www.idsoftware.com/games/quake/quake/)
3
Unreal ist ein Ego-Shooter von Epic Games aus dem Jahre 1998
(http://www.unreal.com)
4
Digital Content Creation, üblicherweise mit Bezug auf 3D-Anwendungen verwendet
5
DCC-Tool der Firma Autodesk (http://www.autodesk.vom/maya)
6
DCC-Tool der Firma Autodesk (http://www.autodesk.com/3dsmax)
7
Component Based Game Engine, eine an der FH-Hagenberg entwickelte Game Engine
(http://gamedev.fh-hagenberg.at/wiki/index.php?title=Cogaen)
2
6
Die hierbei verwendeten Daten, wie zu ladende Meshes oder verwendete
Materialien, sind spezifisch für die jeweilige Implementierung. Somit entsteht
eine starke Abhängigkeit zwischen Assets und Implementierung, welche in
striktem Gegensatz zum modularen Grundgedanken von Cogaen steht. Vielmehr bewirkt dieses Vorgehen, dass bereits fertiger Content immer wieder
überarbeitet werden muss, wenn sich auch nur Details der Implementierung
ändern.
2.2
Aufbau von Asset-Pipelines
Eine Asset-Pipeline bietet die Möglichkeit zur Umgehung der meisten dieser
Probleme. Sie bietet die nötige Abstraktion zwischen Asset-Erstellung und
Engine, gleichzeitig ist dazu die detaillierte Konzeption der entsprechenden
Interfaces erforderlich, welche bei der bisherigen Entwicklung von Cogaen
stark vernachläsigt wurde. Erst dadurch kann sich die Engine jedoch von
einer Programmierer-Sandbox zur produktionstauglichen Game Engine entwickeln.
2.2.1
Vergleich mit der Kompilierung in der Softwareentwicklung
Funktional ist eine Asset-Pipeline vergleichbar mit dem Kompiliervorgang
bei Hochsprachen in der Programmierung. Dabei wird aus mehr oder weniger
stark abstrahiertem Sourcecode, mit Hilfe von Compilern, Maschinencode erzeugt, welcher für die Zielhardware und das verwendete Betriebssystem spezifisch ist. Entscheidend sind dabei zwei Punkte: Erstens kann, entsprechend
sorgfältige Programmierung vorausgesetzt, das gleiche Programm durch Anpassung des Compilers für verschiedene Plattformen übersetzt werden und
zweitens werden die jeweiligen Einstellungen in Projekt- oder Makefiles festgehalten. Dadurch ist der Vorgang jederzeit reproduzierbar und bedarf keiner weiteren Interaktion. Änderungen der Zielplattform erfordern lediglich
die Erstellung neuer Settings und ein Neukompilieren des Quellcodes.
Eine Asset-Pipeline verhält sich hierzu grundsätzlich analog. Der größte Unterschied besteht in der Erstellung der Sourcen. Während dies bei der
Programmierung meist einfache Textdateien sind, welche mit beliebigen Editoren geschrieben werden können, kommen bei der Contenterstellung komplexe Tools zum Einsatz, welche in der Regel proprietäre Formate verwenden.
Zwar wäre es in vielen Fällen auch möglich, diese direkt zu kompilieren, jedoch würde dies eine sehr enge Bindung an die jeweiligen Tools bedeuten.
Bedenkt man, dass häufig verschiedene Werkzeuge für gleiche oder ähnliche Aufgaben zum Einsatz kommen, sei dies bedingt durch Lizenzen, unterschiedliche Eignung für konkrete Problemstellungen oder schlicht persönliche
Präferenzen der jeweiligen Artists, ist eine solche Festlegung auf ein einziges
Tool wenig erstrebenswert.
Intermediate Assets
Source Assets
7
3ds Max
+ Plug-Ins
Photoshop
+ Plug-Ins
Model + Animations
.max
Texture
.psd
Max
Exporter
Photoshop
Exporter
Model
Animation
To the Game
(Fast Path)
Texture
(.tiff + Options)
Final Assets
Conversion Program + DLLs
Platform
A
Assets
Platform
B
Assets
Packager Program
Platform A
Assets
Platform B
Assets
To the Game
(Normal Path)
Abbildung 2.1: Überblick einer Asset-Pipeline
Aus diesem Grunde kommt für die verschiedenen Arten von Content
jeweils ein gemeinsames Zwischenformat zum Einsatz. Dieses kann von jeweils allen verwendeten Tools im- und exportiert werden und dient auch
zur Weiterverarbeitung in der Pipeline. Abb. 2.1 nach Noel Ilopis [7] zeigt
neben dem grundsätzlichen Aufbau noch einen weiteren Unterschied zur
Programm-Kompilierung, welcher besonders bei moderneren Pipelines zum
Tragen kommt.
Dies ist der in der Abbildung angeführte „Fast Path“, welcher eine Umgehung der Pipeline zu Entwicklungszwecken darstellt. Ein solcher ist sinnvoll,
da die in der Pipeline durchgeführten Prozesse teilweise sehr rechenintensiv
und damit zeitaufwändig sind und dem Artist so ein schnelles Feedback über
Änderungen ermöglicht wird. Klassischere Pipelines lösen dieses Problem
durch die weniger komfortable Möglichkeit einer schnellen Kompilierung. Die
8
Daten werden dabei weniger optimiert und aufwändige Berechnungen, wie
zum Beispiel die Erstellung von Lightmaps, entfallen. Dies ist wiederum mit
einem nicht optimierten Debug-Build von Programmen vergleichbar.
2.2.2
Source-Engine als klassisches Beispiel
Ein sehr klassisches Beispiel stellt die Pipeline der Source-Engine 8 von Valve 9
dar. Diese wurde im Jahre 2004 zum ersten Mal für das Spiel Half-Life 2 10
verwendet und verfolgt mit ihrer Pipeline auf Grund ihrer Geschichte einen
klassischeren Ansatz als viele Engines vergleichbaren Alters.
Sie wird hier, vor allem wegen der sehr klaren Analogie zur SoftwareKompilierung, herangezogen und gleichzeitig verdeutlicht ihre Geschichte,
dass dieses Konzept trotz seiner Einfachheit äußerst flexibel ist. Während die
Engine neu entwickelt wurde, weist die Pipeline nur kleine Veränderungen
gegenüber der des Vorgängerspieles aus dem Jahre 1998 auf. Tatsächlich ist
der Content des Vorgängers größtenteils kompatibel mit der neuen Engine,
beziehungsweise ihrer Pipeline. Gerade am Beginn der Entwicklung stellt
dies einen großen Vorteil dar, denn so kann auf einen umfangreichen Pool
an (temporären) Assets zurückgegriffen werden, die sich später schrittweise
ersetzen lassen.
2.2.2.1
Detaillierte Betrachtung der Model Pipeline
Im Detail soll hier beispielhaft die Pipeline für 3D-Modelle betrachtet werden. Als Quelldateien dienen hier SMD 11 -Files, welche einfache ASCII-Dateien darstellen, die aus dem jeweiligen DCC-Tool exportiert werden. SMD ist
ein rudimentäres 3D-Format und zeigt drei Ausprägungen, die sich nicht in
ihrer sehr einfachen Syntax unterscheiden und primär einer besseren Übersicht dienen.
• Reference-Files beinhalten neben dem Skelett-Setup die Meshdaten in
der Bind-Pose.
• Animation-Files beschreiben jeweils einen Animationsclip. Dazu beinhalten sie pro Frame eine Liste der animierten Nodes mit den jeweiligen
Transformationsdaten.
• Vertex-Files, beinhalten sämtliche Blendshapes. Die Dateiendung lautet hierbei VTA, aber Syntaktisch sind diese lediglich eine Abwandlung
der Animation-Files, wobei jeder Frame ein Blendtarget beschreibt.
8
Mehr Informationen unter http://source.valvesoftware.com/
Valve Corporation, ein US-amerikanischer Spieleentwickler
(http://www.valvesoftware.com/)
10
http://half-life2.com/
11
StudioMdl Data, ein Überblick über das Format findet sich unter:
http://developer.valvesoftware.com/wiki/SMD
9
9
model.mdl
model_ref.smd
model.dx80.vtx
model_ani#.smd
model_lod#.smd
studiomdl.exe
model.qc
model.dx90.vtx
model.sw.vtx
model_phy.smd
model.phy
model_blend.vta
model.vvd
Abbildung 2.2: Überblick der Model-Pipeline der Source-Engine. Die
Output-Daten erklären sich folgendermaßen: MDL-Dateien dienen zur Referenz des Modells und enthalten die Animationen, VTX-Dateien enthalten
die optimierten Meshdaten (eine je unterstützter Plattform), PHY-Dateien
enthalten Kollisionsmeshes und VVD-Dateien die Blendshapes.
Hierzu werden, anstatt der Nodes, bei jedem Frame jene Vertices, inklusive ihrer Position aufgelistet, welche im entsprechenden Blendshape
von der Bindpose abweichen.
Die Aufschlüsselung der einzelnen Dateien dient zur Verdeutlichung der
Einfachheit des Systems welches in Abb. 2.2 dargestellt ist. Das äußerst simple Format kann die benötigten Daten exakt abbilden und definiert sich dabei
nur über die unterstützten Features. Dadurch ist es nicht nur von der konkreten Implementierung unabhängig, sondern könnte auch als Quellformat
für jede andere Engine mit ähnlichem Featureset Verwendung finden.
Zur Kompilierung des finalen Models wird neben sämtlichen SMD-Files
noch ein QC 12 -File benötigt. Dieses ist mit einem Makefile vergleichbar und
enthält alle zum Kompilieren notwendigen Informationen, wie Name und
Pfad des finalen Modells, Suchpfade für die verwendeten Materialien, wie
die verschiedenen SMD-Files zu behandeln sind und verschiedene enginespezifische Daten. Soll das Modell schließlich kompiliert werden, muss lediglich
der Compiler mit dem QC-File als Parameter aufgerufen werden, was, zum
Zweck einer Neukompilierung, sehr leicht für alle Models eines Projektes
automatisiert werden kann.
12
Eine Zusammenfassung der Funktionen ist zu finden unter:
http://developer.valvesoftware.com/wiki/Qc
map.bsp
vrad.exe
map.bsp
10
vvis.exe
map.vmf
vbsp.exe
Hammer Editor
map.bsp
Abbildung 2.3: Überblick der Level-Pipeline der Source-Engine. Die
schrittweise verarbeitete BSP-Datei kann in jedem Stadium von der Engine geladen werden.
2.2.2.2
Überblick der sonstigen Assets
Auch andere Assets werden in sehr ähnlicher Weise behandelt. Die Erzeugung von Texturen erfolgt aus TGAs 13 , wobei die benötigten Informationen zu Kompression14 , Filterung15 und dergleichen in entsprechend benannten Textfiles festgehalten werden. Bei Levels kommt dagegen, die bereits
erwähnte Möglichkeit eines verkürzten Kompiliervorganges zu Entwicklungszwecken, zum Tragen. Im Gegensatz zu den anderen Assets, sind Levels in
der Source-Engine weitaus komplexer (Abb. 2.3 zeigt die Level-Pipeline). Sie
bedürfen in ihrer finalen Version aufwändiger Vorberechnungen für das Szenenmanagement16 , sowie das Baking von Lightmaps. Dieses Preprocessing
kann mehrere Stunden in Anspruch nehmen und würde den Entwicklungsprozess stark behindern, wenn es nicht umgangen werden könnte. Deshalb
ist das Map-Compiling in drei Stufen aufgeteilt, welche verschiedene Abhängigkeiten aufweisen.
• Im ersten Schritt wird durch den BSP -Compiler17 die von der Engine
geladene Datei erzeugt, was zum Testen des Layouts oder gescripteter
Ereignisse vollkommen ausreicht.
• Der anschließend ausgeführte VIS -Compiler18 fügt der zuvor erzeugten Datei verschiedene für das Szenenmanagement und die Beleuchtung
verwendete Informationen hinzu. Dieser Schritt kann während der Entwicklung ausgelassen, oder im „Fast“-Modus durchgeführt werden. Das
größte Potential zur Verkürzung dieses Prozesses bieten jedoch vor al13
Truevision Advanced Raster Graphics Array: Ein einfaches Format für 2D Rastergrafik
mit weitreichender Unterstützung
14
Je nach Bildinhalt unkomprimiert oder eine geeignete, von der Hardware unterstützte,
Kompression
15
Die bei der Erstellung von Mip Maps verwendete Filterung
16
Source verwendet BSPs, wobei ein Culling über PVSs (Potentially Visible Set) erfolgt
17
Beschreibung des Tools unter http://developer.valvesoftware.com/wiki/Vbsp
18
Beschreibung des Tools unter http://developer.valvesoftware.com/wiki/Vvis
11
lem spezifische Optimierungen des Levels, welche sich ebenso positiv
auf das Laufzeitverhalten der Map auswirken.
• Der zuletzt ausgeführte Lighting-Compiler19 (VRAD) berechnet die
statische Beleuchtung der Szene. Verfügt die Map über die Daten aus
dem VIS -Prozess, so erfolgt dies mit Hilfe einer Radiosity-Simulation,
ansonsten kann durch Raytracing nur die direkte Beleuchtung berechnet werden, wobei sich beim Lighting, durch verschiedene Qualitätseinstellungen, typischerweise die meisten Möglichkeiten zur Zeitersparnis bieten.
Während also beim Entwicklungsprozess hauptsächlich mit Testversionen der Levels gearbeitet wird, bietet dieses System die Möglichkeit zum
Release, oder als Nightly-Builds, vollständig optimierte und final beleuchtete Versionen der Maps zu erstellen.
2.2.3
Der Entwicklungsprozess bei Cogaen
Betrachtet man derzeit die Produktion eines Spieles mit Cogaen, fällt schnell
auf, dass hier keine der angesprochenen Mechanismen umgesetzt sind. Beispielhaft sei hier das Projekt CaptAncestor 20 aus dem Sommersemester 2008
genannt, bei dem der Content im Wesentlichen in zwei Teilsysteme der Engine eingebunden werden muss — Zur Darstellung wird die Open-Source Engine Ogre3d 21 verwendet, die physikalische Simulation erfolgt mit PhysX 22 .
2.2.3.1
Einbindung von 3D-Daten
Ogre3d verwendet proprietäre Binärformate für Meshes und Animationen,
welche, mit den entsprechenden Exportern, direkt aus dem verwendeten
DCC-Tool (Maya) exportiert werden, wohingegen Materialien von Hand mit
Textdateien definiert werden müssen. Auch für die verwendete PhysX-Engine
stehen, für Erstellung und Export von physikalischen Szenen, zwar Plug-Ins
bereit, jedoch werden diese in der verwendeten Cogaen-Anbindung nicht unterstützt. Um den Aufwand für die Toolentwicklung zu minimieren und die
Definition eines Szenenformates zu umgehen, wurde, wie bereits erwähnt, ein
Maya-Script programmiert, welches den benötigten Code zur Erstellung der
Spielobjekte generiert.
19
Beschreibung des Tools unter http://developer.valvesoftware.com/wiki/Vrad
Mehr Informationen zu CaptAncestor im Game-Development Wiki der FH-Hagenberg
(http://gamedev.fh-hagenberg.at/wiki/index.php?title=CaptAncestor)
21
http://www.ogre3d.org/
22
Hardwarebeschleunigte Echtzeit Physikengine der Firma Nvidia
(http://www.nvidia.com/object/nvidia_physx.html)
20
12
1 Macro("LevelMesh") {
2
setParameter("mesh", "prop_coffin_vault01.mesh");
3
setParameter("prefix", "vault02coffin03");
4
setParameter("translate", -13.578, -2.25, 20.977);
5
setParameter("rotate", 0.0, 96.309, 0.0);
6
}
Programm 2.1: Beispielcode zur Platzierung eines statischen Meshes im
Level
2.2.3.2
Levelerstellung
Das Level besteht hierbei aus verschiedenen Meshes, welche einzeln aus Maya
exportiert werden, um diese beim Rendering instanziieren zu können und so
Ressourcen zu sparen. Das Zusammensetzen des Levels erfolgt wiederum
ebenfalls mit Hilfe von Maya, wobei die verwendeten Meshes hierbei nur als
Proxyobjekte zur Positionierung und Ausrichtung dienen. Die tatsächliche
Verknüpfung mit den bereits exportierten Ogre3d -Meshes erfolgt über „custom Attributes“ 23 in Maya. Bei jedem platzierten Objekt muss von Hand der
Pfad zum verwendeten Mesh angegeben werden, was ebenso für weitere Metadaten, wie beispielsweise die verwendete Lightmap, gilt. Die so markierten
Objekte werden schließlich, auf Basis ihres type-Attributes, in Scriptaufrufe
mit den entsprechenden Parametern übersetzt (Prog. 2.1).
Neben der Platzierung müssen für das Beispielobjekt also 3 zusätzliche
Attribute von Hand erstellt werden:
• type = LevelMesh: Durch die Existenz des Type-Attributes werden
Objekte zum Export markiert, der Wert bestimmt hierbei das zur Erstellung verwendete Makro
• mesh = prop_coffin_vault01.mesh: Hiermit wird das von der Engine
verwendete Ogre3d-Mesh bestimmt
• prefix = vault02coffin03: Dies ist eine eindeutige ID der Instanz
und wird zur Bestimmung der verwendeten Lightmap benötigt. Da
diese wiederum auch in den, von Hand zu erstellenden, Material-Definitionen verwendet wird, sollte sie zur besseren Übersicht und Wartbarkeit einer verständlichen Struktur folgen, und kann somit ebenfalls
nicht automatisch generiert werden.
Die übrigen Parameter, translate und rotate, werden vom Exportscript aus den Transformationsdaten des jeweiligen Objektes ausgelesen.
23
Beliebige Eigenschaften (Integer, Float, Boolean, String, Vector und Enum), die Objekten zugewiesen werden können
13
1 Macro("LevelPhysics") {
2
setParameter("form", "cube");
3
setParameter("debug", 0);
4
setParameter("translate", -3.0, -0.15, -21.0);
5
setParameter("rotate", 0.0, 0.0, 0.0);
6
setParameter("scale", 3.0, 0.3, 3.0);
7
}
Programm 2.2: Scriptaufruf für die Platzierung eines Kollisionsobjektes
Analog dazu erfolgt auch die Positionierung von Kollisionsobjekten. Da
hierbei lediglich Box-Shapes (also Quader) Verwendung finden, ist es möglich, diese mit Hilfe von Würfeln zu platzieren, wobei die Skalierung selbiger
die Größe der Kollisionskörper bestimmt(Prog. 2.2).
Der Beispielcode beinhaltet darüber hinaus noch weitere Parameter, welche jedoch global gesetzt werden:
• form = cube: Das verwendete Makro unterstützt auch die Erstellung
anderer Formen, wie beispielsweise sphere, was jedoch im genannten
Projekt nicht zur Anwendung kommt. Somit kann der Parameter global vom Exporter gesetzt werden und es wird kein weiteres CustomAttribute benötigt
• debug = 0: Der Exporter unterstützt die Erstellung einer Debugversion des Levels. Bei einem Wert von 1 würden vom Makro zusätzlich
grafische Repräsentationen der Kollisionsobjekte erstellt.
Diese Vorgehensweise erfordert zwar tatsächlich nur geringen Aufwand
seitens der Toolprogrammierung, der Aufwand für den Anwender ist jedoch
umso größer. So müssen sämtliche Metadaten von Hand eingetragen werden,
was bei Erstellung und Änderungen sehr umständlich ist. Ein viel größeres
Problem stellt jedoch die Fehleranfälligkeit dar, da beispielsweise auftretende Tippfehler schwer aufzuspüren sind. Besonders bei Änderungen kommt
zudem zum Tragen, dass bei der Vielzahl von bearbeiteten Objekten leicht
das ein oder andere vergessen wird. Beim genannten Projekt wurden beispielsweise die Lightmaps erst später hinzugefügt, weshalb, im bereits fertig
gestellten Level, zu sämtlichen Meshes das erwähnte prefix -Attribut hinzugefügt werden musste.
2.2.3.3
Direkte Folgerungen aus den Problemen
Ein Großteil dieser Arbeiten und Probleme könnten dabei durch eine entsprechende Asset-Pipeline umgangen werden. Betrachtet man die Entwicklung
14
von CaptAncestor für sich, so ließe sich, bereits durch ein besseres Zusammenspiel der verwendeten Tools, eine deutliche Reduzierung des Arbeitsaufwandes erreichen. Könnte beispielsweise der Exporter die referenzierten
Meshes als solche erkennen, würde die Angabe des benötigten Ogre3d -Meshes
entfallen. Diese könnten beim Levelexport sogar automatisch erstellt werden.
Ähnlich verhält es sich mit den, für die Lightmaps benötigten, eindeutigen IDs. Innerhalb einer Maya-Szene ist ohnehin jedes Objekt eindeutig
identifizierbar, die manuell zu erstellenden Ogre3d -Materialien erfordern jedoch die einfache Lesbarkeit dieser IDs. Würden die Materialien stattdessen
automatisch erstellt, entfiele also auch die hier nötige Arbeit.
Gleichzeitig ließe sich der dabei nötige Aufwand zur Toolentwicklung,
für ein einziges Projekt, nicht rechtfertigen. Da sämtliche Tools an die gerade verwendete Implementierung der Engine gebunden wären, müssten diese
aber bei jeder größeren Änderung, wie beispielsweise einem Austausch der
hier verwendeten Ogre3d und PhysX durch die intern entwickelten Systeme
CBero beziehungsweise PhysiKCHs, weitreichend überarbeitet werden, was
die letztlich angestrebte Reduzierung des Arbeitsaufwandes stark relativieren, beziehungsweise diesen nur verlagern würde.
Kapitel 3
Asset-Pipelines
Eine Asset-Pipeline ist die Verbindung zwischen Contenterstellung und der
Game-Engine selbst. Sie dient zur Abstraktion der erstellten Assets von der
konkreten Engine-Implementierung oder Zielplattform und somit primär zur
Umwandlung verschiedener Datenformate und der Auslagerung zeitintensiver Offlineberechnungen.
Betrachtet man den eigentlichen Produktionsvorgang eines Spieles, zeigt
sich aber schnell, dass eine reine Offline-Pipeline, wie sie bereits beschrieben wurde auch Nachteile bringt — alle Änderungen müssen die Pipeline
durchlaufen, was einen erheblichen Zeitaufwand bedeuten kann. Klassischere Engines wie Source bieten deshalb die Möglichkeit zur Abkürzung der
Pipeline, neuere Architekturen verfolgen einen anderen Ansatz: Durch die
Leistungsfähigkeit heutiger Computersysteme entfällt zunehmend die Notwendigkeit aufwändigen Preprocessings, was es ermöglicht, die Engine, während des Entwicklungsprozesses, direkt auf die Source-Assets zugreifen zu
lassen, womit die Pipeline jedoch nicht gänzlich entfällt. Besonders beim
Multi-Platform-Development für Konsolen ist eine Offline-Pipeline kaum zu
umgehen und auch für die Release-Version bietet die Asset-Pipeline, neben
Möglichkeiten zur Optimierung, auch Schutz vor Manipulationen der Daten durch den Endbenutzer. Aus diesem Grunde soll hier der Schwerpunkt
dennoch auf der klassischen Offline-Pipeline liegen, da sich der Aufwand einer direkten Engine-Anbindung, bei entsprechender Konzeption, in einem
überschaubaren Rahmen hält.
3.1
Pipeline Anforderungen
Grundsätzlich bildet die Asset-Pipeline eine Brücke zwischen der Contenterstellung und dem Laden der Assets durch die Engine. Dass der direkte
Export in die benötigten Laufzeitformate kein sinnvoller Weg ist, wurde bereits in Abschnitt 2.2 erläutert. Diese Überbrückung durch die Pipeline dient
jedoch allein der technischen Abstraktion, während sie den Workflow tenden15
3. Asset-Pipelines
16
ziell stört, beziehungsweise verlangsamt. Aus Sicht der Usability besteht die
wichtigste Anforderung an die Pipeline deshalb in ihrer Transparenz. Im
Idealfall wird sie nicht einmal wahrgenommen, sondern erledigt ihre Aufgaben im Verborgenen. Um eine solche Transparenz zu erreichen, sind vor
allem Anfang und Ende der Pipeline von Bedeutung. Der Weg aus der Contenterstellung sollte sich nahtlos in die verwendeten Tools integrieren, die
Integration in die Engine darf keinerlei Nacharbeiten erfordern.
3.1.1
Contenterstellung
Am Beginn der Pipeline steht die Erstellung des benötigten Contents. Bei
Spielen erstreckt sich dies über unterschiedlichste Disziplinen: 3D-Modellierung, 2D-Grafik, Animation, verschiedene Bereiche der Audioproduktion
und Video, welche alle kombiniert und von der Pipeline behandelt werden
müssen. Für alle dieser Medientypen stehen jeweils verschiedene, etablierte
Standardtools zur Verfügung, während es für ihre Zusammenführung, in der
Weise, wie sie für Spiele nötig ist, keine etablierten Lösungen gibt.
So kommen in der Film- und Effektindustrie zwar im Wesentlichen die
gleichen Medien zum Einsatz, doch wird hier in vorgegebenen Shots gearbeitet und so kann in Rendering, Schnitt, Compositing und Audiomastering
alles genau von Hand aufeinander abgestimmt werden. Der große Unterschied
bei Spielen besteht darin, dass sie dynamisch vom Spieler abhängen und so
während der Produktion keine fixe Gesamtkomposition erstellt werden kann.
Vielmehr geschieht das endgültige Zusammenfügen aller Einzelteile während
der Laufzeit durch die Engine, was erst durch eine weitere Komponente möglich wird: Metadaten.
Diese weisen beispielsweise einen Animationsclip als Walkcycle aus oder
kennzeichnen ein 3D-Modell als Türe, welche sich öffnen und schließen lässt
und dabei wiederum bestimmte Geräusche von sich gibt. Für all diese Aufgaben gibt es weder Standardformate noch -tools, vielmehr werden diese
Daten oft, wie dies auch bei der Source-Engine(Abschnitt 2.2.2) teilweise
der Fall ist, in manuell erstellten Textdateien beschrieben, oder verschiedene Namenskonventionen dienen zur logischen Zuordnung einzelner Assets,
was aber unflexibel ist und leicht zu Unübersichtlichkeit führen kann. Beiden dieser Ansätze ist gemeinsam, dass sie anfällig gegen Flüchtigkeitsfehler
sind und sich kaum für komplexe Beschreibungen eignen. Abhilfe schaffen
hier enginespezifische Spezialanwendungen, wobei diese, normalerweise grafischen, Tools, sehr vielseitig ausfallen und hier nur einige Beispiele genannt
werden sollen:
• Material-Editoren dienen neben der Erstellung von Shadern auch der
Festlegung physikalischer Materialeigenschaften wie Reibung, Aufprallgeräuschen oder dem Schadensverhalten wie der Darstellung von Oberflächenschäden, Partikeleffekten oder sogar dynamischem Bruchverhal-
3. Asset-Pipelines
17
ten.
• Mit Animationseditoren werden zuvor erstellte Animationsclips inhaltlich beschrieben, damit sie von der Engine, zur Laufzeit, im richtigen
Kontext verwendet werden können (Idle, Walk, Run, Attack etc.), aber
auch die Festlegung möglicher Übergänge und Überlagerungen zwischen den einzelnen Clips erfolgt hier.
• Leveleditoren stellen einen Grenzfall dar. Zwar dienen diese oft der
Erzeugung von Levelgeometrie, der Generierung von Navigationsdaten
für die KI oder ähnlichem. Eine zentrale Aufgabe ist jedoch die logische
und inhaltliche Verknüpfung zuvor erstellter Assets.
Ein genereller Trend besteht darin, all diese Funktionen in ein einziges
Tool, zu integrieren. Bei aktuellen Engines (und ihren Toolsets) zeichnen sich
dazu zwei unterschiedliche Richtungen ab. Entweder werden immer mehr
Funktionen in den Leveleditor integriert, wie dies bei der aktuellen UnrealEngine 1 der Fall ist oder die Engine selbst wird um einen Tool-Modus erweitert. Beispiele hierfür sind der Particleeditor der Source-Engine oder id
Tech4 2 , bei der sämtliche Tools, einschließlich des Leveleditors in die Engine
integriert sind.
Handelt es sich bei dieser Integration um eine Weiterentwicklung bestehender Systeme und waren die verschiedenen Funktionalitäten vorher bereits
in Einzelanwendungen umgesetzt, tritt mitunter ein Problem zu Tage: Oft
werden die von solchen Tools verwendeten Datenstrukturen ad-hoc auf das
konkrete Problem zugeschnitten und sind, obwohl sehr ähnlich, untereinander nicht kompatibel, womit, bei einer Zusammenführung der Programme,
lediglich das Frontend vereinheitlicht werden kann, während die verschiedenen Backends erhalten bleiben und somit auch weiterhin gewartet werden
müssen. Bei einer Neukonzeption bietet sich dagegen die Gelegenheit, alle
benötigten Arten von Metadaten einheitlich zu strukturieren und damit ein
Basissystem zu entwickeln, welches modular um die jeweils benötigten Funktionen zur Bearbeitung und Interpretation der verschiedenen Daten erweitert
werden kann.
3.1.2
Anbindung des Contents
Bei der Engineanbindung der Assets können, je nach Anwendungsfall, verschiedene Aspekte im Vordergrund stehen: Ladezeiten, Dateigrößen, Streaming, Veränderbarkeit des Contents3 etc.
1
aktuell in Version 3 verfügbar, mehr Informationen unter
http://www.unrealtechnology.com/
2
Aktuelle Engine von id Software, mehr Informationen unter
http://www.idsoftware.com/business/idtech4/
3
Soll custom Content unterstützt werden, muss sich dieser leicht einbinden lassen; zur
Erschwerung von Cheats, sollten die Assets geschützt, oder verschlüsselt sein
3. Asset-Pipelines
18
Die Bedeutung dieser Punkte wechselt von Projekt zu Projekt, unterscheidet sich je nach Zielplattform und ändert sich auch während des Entwicklungsprozesses eines Spieles. Deshalb ist es wichtig, die Schnittstelle zwischen Pipeline und Engine möglichst klein und modular zu halten. Die Pipeline selbst, mit allen ihren Verarbeitungsprozessen, arbeitet dabei unabhängig vom letztlich verwendeten Output-Modul und lässt sich auch unter
veränderten Anforderungen weiterverwenden. Gleichzeitig erfordern die, zur
Enginanbindung benötigten, Module nur einen minimalen Entwicklungsaufwand und lassen sich durch Konfigurationsänderungen austauschen.
Die letztliche Implementierung der Engineanbindung ist dabei weitestgehend freigestellt und auch die Unterschiede zwischen Offline- und OnlinePipeline fallen an dieser Stelle nur minimal ins Gewicht. Vielmehr stellt
auch eine Echtzeitanbindung lediglich ein, zur Offline-Version alternatives,
Output-Modul dar.
3.2
Asset Workflow
Ein zentraler Punkt bei der Pipeline-Entwicklung ist die Optimierung des
Workflows und dabei vor allem die Vermeidung von Routinearbeiten, welche
den kreativen Prozess stören. Dies bezieht sich nicht ausschließlich auf die
eigentliche Erstellung von Assets und die Integration selbiger in die Engine, sondern auf die gesamte Strukturierung und Verwaltung des Projektes.
Wichtige Aspekte sind dabei der Datenabgleich zwischen den verschiedenen
Entwicklern, die Verwaltung des bestehenden Asset-Pools und ein möglichst
transparentes Funktionieren der Pipeline.
3.2.1
Kollaboration
Bei der Erstellung des Contents ist wichtig, dass möglichst barrierefrei auf
bereits vorhandene Ressourcen zugegriffen werden kann und Änderungen
möglichst schnell propagiert werden. Voraussetzung hierfür ist zunächst ein
problemloser und verlustfreier Datenaustausch zwischen den verwendeten
Programmen, was bei sehr kleinen Teams bereits ausreichen kann.
Mit zunehmender Komplexität von Projekten, wird jedoch vielfach parallel an verschiedenen, voneinander abhängigen Assets gearbeitet, was einen
gewissen Organisationsaufwand und diszipliniertes Einhalten entsprechender
Richtlinien zur Vermeidung von Konflikten mit sich bringt, denn anders als
bei der Programmierung gibt es in der Asset-Erstellung kaum Möglichkeiten
zum Merging von Daten. Die meist einzige Lösung, um ein paralleles Arbeiten dennoch zu ermöglichen ist eine sehr feine Unterteilung der Assets in einzelne Dateien, welche lediglich referenziert werden. Die Möglichkeiten hierzu
unterscheiden sich bei verschiedenen Medien, aber auch Tools, wesentlich: So
ist eine solche Referenzierung bei der Verarbeitung großer Datenmengen, wie
3. Asset-Pipelines
19
in der Audio- und Videobearbeitung, ohnehin üblich; bei der Bildbearbeitung dagegen kaum möglich. 3D-Anwendungen erfordern hierbei wiederum
primär Disziplin, so bieten diese zwar grundsätzlich die Möglichkeit zur Referenzierung externer Daten, wie beispielsweise einzelner Animationsclips,
jedoch müssen diese dazu ausdrücklich exportiert werden.
Darüber hinaus ist bei der Entwicklung von 3D-Tools derzeit ein genereller Trend zur Verbesserung der Kollaborationsmöglichkeiten zu beobachten. So bietet beispielsweise Maya, seit der aktuellen Version 2009, die
Möglichkeit zur Definition von Schnittstellen für komplexe Szenenelemente,
sogenannter Asset-Container, deren Inhalt sich dadurch leicht austauschen
lässt. Ein interessantes Forschungsprojekt zum Thema stellt COLLADA Collaboration 4 dar, welches die gleichzeitige Bearbeitung einer Maya-Szene von
unterschiedlichen Arbeitsplätzen aus ermöglicht, wobei die Synchronisation
über einen zentralen Server erfolgt.
3.2.2
Versionsmanagement
Das Versionsmanagement ist ein wichtiger Bestandteil des Entwicklungsprozesses und vereinfacht unter anderem auch die Kollaboration. Versionsverwaltungssysteme protokollieren die Fortschritte des Projektes und halten so
den jeweiligen Entwicklungsstand und die entsprechende Version jeder einzelnen benötigten Datei fest. Sie bieten die Möglichkeit, jederzeit, zum Beispiel
bei Fehlern, einen vorangegangenen Status wiederherzustellen, und vereinfachen, durch die Protokollierung der an Änderungen beteiligten Benutzer und
Kommentare, die Nachverfolgung von Änderungen. So vereinfachen sie die
parallele Entwicklung an abhängigen Projektteilen, da die Gründe für möglicherweise entstehende Inkompatibilitäten leichter aufgespürt werden können, als dies sonst der Fall wäre. Auch der gleichzeitige und problematische
Zugriff auf die Daten, wie beispielsweise bei einem gemeinsamen NetzwerkShare, wird vermieden, stattdessen arbeitet jeder Benutzer mit einer eigenen,
sogenannten Arbeitskopie der Projektdaten, welche in geeigneten Intervallen
mit dem allgemeinen Projektstatus synchronisiert wird.
Ein weiterer Vorteil hiervon ist, dass während der Asset-Produktion, häufig zu Testzwecken, erstellte Dateien (zum Beispiel beim Testen verschiedener Rigging-Setups) nicht den gemeinsamen Asset-Pool aufblähen. Vielmehr
lassen sich diese lokal erstellen und von der Versionsverwaltung ausnehmen,
während sie dennoch beliebige Projektdaten referenzieren können und diese
Referenzen keiner weiteren Anpassung bedürfen, falls die Daten doch zum
Projekt hinzugefügt werden. Dadurch, dass so nur tatsächlich benötigte As4
COLLADA Collaboration ist ein Projekt von Offset Software
(http://www.projectoffset.com) und wurde unter anderem auf der FMX 2009
(http://www.fmx.de) präsentiert. Abgesehen von einen Video
(http://www.youtube.com/watch?v=83ajcAEs30s) sind derzeit jedoch keine öffentlichen
Referenzen zu finden.
3. Asset-Pipelines
20
sets zum Projekt hinzugefügt werden, wird zudem die automatische Verarbeitung durch die Asset-Pipeline vereinfacht: Alle im Versionsmanagement
vorhandenen Quelldaten werden kompiliert, womit eine weitere Unterscheidung zwischen, für das Spiel benötigten und lediglich temporären, Daten
entfällt.
3.2.3
Automatisierung und Pipeline Management
Die Automatisierung der Pipeline dient in erster Linie dazu, die Verarbeitungsprozesse für den Entwickler transparenter erscheinen zu lassen. Wird
also Content zum Projekt hinzugefügt oder geändert, so erfolgt die Kompilierung in die finalen, von der Engine verwendeten Assets ohne weitere
Interaktion des Entwicklers. Dieses Konzept ist an das, aus der Softwareentwicklung bekannte, Prinzip der Continuous Integration (siehe auch Abschnitt 3.3.2.3) angelehnt und bringt, gegenüber der manuellen Steuerung
der Asset-Pipeline, verschiedene Vorteile.
Primär wird sichergestellt, dass die für die Engine aufbereiteten Assets
stets ein exaktes Abbild der Quellassets darstellen, also vollständig und aktuell sind, wobei sich gleichzeitig Inkonsistenzen im Projekt frühzeitig erkennen
lassen, da die Build-Fähigkeit des gesamten Projektes in kurzen und regelmäßigen Abständen überprüft wird. Doch auch der Arbeitsablauf wird von den
Verarbeitungsprozessen der Pipeline weniger beeinflusst: Wenn Quellassets
einzeln und manuell verarbeitet werden, um die Kompilate anschließend in
das Projekt einzupflegen, entstehen mitunter erhebliche Wartezeiten, welche
jedoch kaum sinnvoll genutzt werden können, da die Pipeline-Prozesse auf
der Workstation des Entwicklers ablaufen und diese auslasten. Werden diese Aufgaben hingegen durch die Automatik an ein dezidiertes Build-System
ausgelagert, steht der Arbeitsplatz weiter für produktive Zwecke zur Verfügung.
Diese Auslagerung und Automatisierung erfordert, gegenüber einer manuellen Bedienung der Asset-Pipeline, allerdings auch ein komplexeres System zum Management verschiedener Konfigurationen. Diese können, bei einer manuell angestoßenen Pipeline, für jedes Asset individuell und den Erfordernissen der aktuellen Entwicklungsphase entsprechend angepasst oder
ausgewählt werden, was schnell deutlich wird wenn man die sehr unterschiedlichen Stadien betrachtet, welche beispielsweise ein Level während seiner
Entwicklung durchläuft.
In der Layout-Phase wird die Grundstruktur festgelegt und alle für das
Game-Play relevanten Elemente platziert, später erfolgt die Einbindung der
letztlich verwendeten Assets, wie 3D-Meshes und Texturen, dann die Beleuchtung und schließlich noch finale Anpassungen und Optimierungen. Während all dieser Phasen müssen unterschiedliche Aspekte getestet werden,
während andere vollkommen nebensächlich sind und beim Kompilieren nur
unnötig Rechenzeit in Anspruch nehmen würden.
3. Asset-Pipelines
21
• Während der Layout-Phase müssen von der Pipeline nur rein funktionale Daten, wie beispielsweise Navigationsmeshes für NPCs5 generiert werden, eine Optimierung der hierbei ohnehin nur temporären
3D-Meshes oder die Vorberechnung von Beleuchtungsdaten wäre dagegen ein unnötiger Aufwand an Rechenzeit.
• In den folgenden Design-Phasen ist die spielerische Funktionalität des
Levels wiederum nebensächlich, vielmehr werden hier die gestalterisch
relevanten Daten benötigt. 3D-Meshes müssen in ihrer endgültigen
Form vorliegen (inklusive eventuell vorberechneter LOD6 -Stufen oder
ähnlichem), um diese unter gestalterischen Aspekten beurteilen zu können. Lightmaps müssen in finaler Qualität und Auflösung berechnet
werden und auch vom Sound-System benötigte Daten sind hier erforderlich.
• Die Optimierungsphase bietet die wenigsten Möglichkeiten zur Einsparung von Vorberechnungen, da hier alle Daten, zumindest aus technischer Sicht, final sein müssen, das heißt: vollständiges Gameplay, finale 3D-Daten und so weiter. Doch bei genauer Betrachtung finden
sich auch hier kleine Einsparungsmöglichkeiten. Texturen müssen zwar
grundsätzlich in ihrer endgültigen Auflösung und Kompression vorliegen, beziehungsweise werden diese im Zuge der Optimierungen noch
angepasst. Generierte Texturen wie Normal- oder Lightmaps können
jedoch in schlechterer Qualität berechnet7 werden, als dies für das fertige Produkt vorgesehen ist.
Leider lassen sich diese verschiedenen Konfigurationen nicht in eine einfache Hierarchie von Qualitätsstufen einordnen. Das macht ein entsprechendes
System zur Verwaltung und vor allem Anwendung selbiger, ungleich komplizierter, als dies bei der Softwareentwicklung ist, wo es außer Release- und
Debug-Build selten weitere Konfigurationen gibt.
3.3
Analogien zu klassischen Pipelines
Es wurden bereits verschiedene Vergleiche zwischen Asset-Pipelines und anderen Disziplinen angestellt, welche nun, besonders im Hinblick auf die mögliche Adaption bestehender und erprobter Konzepte, genauer ausgeführt und
ergänzt werden sollen.
5
Non-Player Character, KI-gesteuerte Spielfiguren
Level Of Detail, Objekte werden in mit zunehmender Entfernung zur Kamera durch
vereinfachte Versionen ersetzt (geringerer Poly-Count, weniger Joints, einfachere Shader
etc.)
7
Raytracing-Einstellungen, Anti-Aliasing und ähnliches
6
3. Asset-Pipelines
3.3.1
22
3D-Animation
Die vordergründigsten Ähnlichkeiten der Asset-Produktion und -Verarbeitung finden sich zunächst mit der klassischen 3D-Animation aus den Bereichen Film uns Visual-Effects. Hier besteht eine große Schnittmenge zwischen
den verwendeten Daten und Tools, wodurch sich die Arbeitsabläufe zumindest bei der Erstellung des Contents sehr ähneln und sich im Wesentlichen
nur durch verschiedene Texturauflösungen, Polygonzahlen von 3D-Modellen
und dergleichen unterscheiden.
3.3.1.1
Kollaboration
Im Animationsbereich bieten sich wenige Standardlösungen zur einfacheren
Zusammenarbeit in größeren Teams und abgesehen von proprietären Eigenentwicklungen großer Studios, werden entsprechende Features erst in jüngster Zeit verstärkt von den üblichen DCC-Tools unterstützt. Dabei fallen die
meisten Ansätze zur Kollaboration ohnehin eher in den Bereich von Best
Practices und lassen sich nur durch die disziplinierte Einhaltung entsprechender Konventionen durchsetzen.
Diese beginnen bei der normierten Benennung von Dateien, Nodes und
Attributen, bedeuten aber in erster Linie eine möglichst atomare Aufteilung
von Assets und die Referenzierung dieser, an Stelle des Importes in große
Masterfiles. Diese, von den meisten etablierten DCC-Tools gebotenen Möglichkeiten der Szenenaufteilung, bedeuten jedoch einen zusätzlichen Aufwand
und sind meist schlecht in den eigentlichen Workflow integriert, was wenig
zu ihrer Anwendung motiviert. Zudem waren diese Funktionen, zumindest
im Fall von Autodesk Maya (für andere Packages wie Softimage 8 oder 3ds
Max kann hier nicht auf Erfahrungswerte zurückgegriffen werden), in der
Vergangenheit sehr fehleranfällig und führten immer wieder zu Problemen
mit kaum identifizierbaren Ursachen.
Seit Kurzem rückt die Kollaboration jedoch verstärkt in den Mittelpunkt
der Entwicklung von DCC-Tools und im Falle von Maya zeigt sich dies, neben
der stabileren Szenenreferenzierung, besonders im Asset-System von Maya
2009, welches eine logische Zusammenfassung von Teilen einer Szene zu sogenannten Asset-Containern ermöglicht. Diese sammeln, darüber hinaus, alle
außerhalb des Containers relevanten Attribute in einer festen Schnittstelle, wodurch sich der Inhalt leicht austauschen und somit parallel entwickeln
lässt. Gleichzeitig lassen sich diese Schnittstellen als Templates abspeichern
und erleichtern so die Umsetzung verschiedener Variationen, technisch praktisch gleicher Objekte, wie diese in Spielen sehr häufig vorkommen, beispielsweise Türen oder Kisten, die sich öffnen und schließen lassen oder komplette
Character-Setups.
8
http://www.autodesk.com/softimage
3. Asset-Pipelines
3.3.1.2
23
Renderfarmen
Eine, auf die Verarbeitung in der Asset-Pipeline selbst bezogene Analogie aus
dem Animationsbereich, stellen Renderfarmen dar. Diese dienen der Auslagerung der aufwändigen Berechnungen von Animationssequenzen, wobei fertig
animierte 3D-Szenen an einen zentralen Server übergeben werden, welcher
diese sogenannten Renderjobs zur Abarbeitung kontinuierlich an eine Vielzahl von Rendernodes weiterleitet.
Dabei gibt es zwei Methoden zur Aufteilung der einzelnen Renderjobs.
Entweder jeder Renderknoten berechnet jeweils ein Einzelbild einer Sequenz,
oder mehrere Knoten rechnen parallel am gleichen Bild. Die erste Alternative ist sehr viel einfacher umzusetzen und benötigt keine spezielle Unterstützung durch den verwendeten Renderer. Zudem ist der Ausfall einzelner
Rendernodes weniger problematisch, da im Fehlerfall nur die wenigen, vom
entsprechenden Knoten verarbeiteten Einzelbilder, erneut berechnet werden
müssen, anstatt aller Frames, bei denen der betroffene Node nur zu einem
kleinen Teil beteiligt war.
Trotz dieser Vorteile ist diese Methode jedoch nur zur Berechnung von
Sequenzen geeignet. Beim Rendering von Einzelbildern, wie dies auch in der
Spieleentwicklung mit Light-, Occlusion- oder Normalmaps der Fall ist, muss
also auf die letztere der beiden Möglichkeiten zurückgegriffen werden. Damit ist impliziert, dass sich bereits Standardlösungen für Renderfarmen, wie
diese zu den meisten 3D-Grafikprogrammen angeboten werden, direkt in die
Game-Asset-Pipeline integrieren lassen. Darüber hinaus sind vergleichbare
Techniken, zur parallelen Verarbeitung auf vernetzten Rechenknoten, jedoch
auch für Pipeline-Tools zur Abarbeitung anderer rechenintensiver Prozesse,
einzuplanen.
3.3.2
Verwendbare Technologien aus der Softwareentwicklung
Im Gegensatz zur Animation, erscheinen Vergleiche zwischen der reinen Softwareentwicklung und Asset-Pipelines für Spiele weniger offensichtlich und
naheliegend. Tatsächlich lassen sich jedoch viele Konzepte direkt oder nur
leicht modifiziert übertragen.
3.3.2.1
Cross-Platform Development
Die wichtigsten Gemeinsamkeiten und gleichzeitig einer der Hauptgründe
für eine umfangreiche Asset-Pipeline finden sich im Cross-Platform-Development oder allgemeiner in verschiedenen und wechselnden Zielplattformen.
Dies schließt auch Änderungen und Weiterentwicklungen an der Engine
selbst ein. Assets werden zwar durch die zunehmende Rechenleistung auch
bei Echtzeitanwendungen immer unabhängiger von der verwendeten Architektur und Engine. Assets, die in einem höher abstrahierten Format vorlie-
3. Asset-Pipelines
1
2
3
4
5
24
#ifdef WIN32
# include <windows.h>
#else
# include <unistd.h>
#endif
Programm 3.1: Typische Präprozessoranweisungen zur Sicherstellung der
Kompatibilität mit verschiedenen Plattformen
gen, werden während des Ladeprozesses in die entsprechenden Laufzeitformate umgesetzt. Zum einen zeigt sich dieser Fortschritt bei Consolen jedoch
in weit geringerem Maße als beim PC, zum anderen beschränken sich plattformspezifische Anpassungen nicht allein auf die hardwarenahe Strukturierung der Daten sondern auch auf Aspekte wie beispielsweise die unterschiedliche Interpretation von Gamma-Kurven [9].
Solche notwendigen und nicht von der Performance abhängigen Plattformanpassungen bieten auch in Zeiten des Next-Gen-Development noch ein
schlagendes Argument für, ansonsten oftmals als altmodisch oder umständlich betrachtete, Offline-Pipelines. Die Analogie zum Softwaredevelopment
besteht in der Kompilierung der immer gleichen Quelldaten mit verschiedenen, festgelegten Einstellungen. Durch bedingte Übersetzungsanweisungen
lassen sich zudem gezielte Anpassungen vornehmen.
Analog zu einer Präprozessoranweisung, wie Prog. 3.1, kann es beispielsweise aufgrund von Speicherbeschränkungen sinnvoll sein, einzelne Texturen
für bestimmte Plattformen, wie Consolen, in geringerer Auflösung zu exportieren, dies jedoch nicht als globale Regel, also für alle Texturen festzulegen.
3.3.2.2
Versionsmanagement
Versionsmanagement ist in der Software- und auch Spieleentwicklung gang
und gäbe. Es bietet sich, über Game-Asset-Pipelines hinaus, aber für jede
Form der Contentproduktion an, wo es jedoch nur selten zur Anwendung
kommt. Während sich verbreitete Tools wie Subversion 9 , Perforce 10 oder
Alienbrain 11 , entgegen der weit verbreiteten Meinung, grundsätzlich durchaus gut zur Verwaltung von Content eignen, muss beim Umgang mit Assets
jedoch auf verschiedene Unterschiede zu Quelltext-Dateien geachtet werden.
Da die Daten meist binär, oder zumindest nicht in menschenlesbarer
Form vorliegen, ist ein Merging verschiedener Versionen, wie dies bei Sour9
Subversion ist eine verbreitete Versionsverwaltungssoftware unter Open-Source Lizenz
(http://subversion.tigris.org)
10
Perforce ist ein kommerzielles System zur Versionsverwaltung
(http://www.perforce.com)
11
Alienbrain ist eine kommerzielle Versionsverwaltungssoftware, welche spezielle Features für den Umgang mit Assets bereitstellt (http://www.alienbrain.com)
3. Asset-Pipelines
25
cecode relativ einfach ist, praktisch unmöglich. Stattdessen sollten Versionskonflikte durch die sorgfältige Anwendungen der entsprechenden Sperrmechanismen, wie zum Beispiel svn lock, strikt vermieden werden. Die oft
als problematisch betrachteten, großen Datenmengen bei Assets, lassen sich
dagegen sinnvoll auf verschiedene Repositories aufteilen. Diese Daten sind
meist das Ergebnis von Rendering-, Export- oder Kompilationsprozessen.
Sie sollten, wegen des zur Erstellung notwendigen Aufwandes an Rechenleistung, zwar zentral vorgehalten werden. Da sie leicht wiederhergestellt werden
können, bedürfen sie jedoch nur einer relativ geringen Datensicherheit und
können in ein verhältnismäßig schwach gesichertes Output-Repository ausgelagert werden, um das gut abgesicherte Projekt-Repository nicht unnötig
aufzublähen.
Die Daten aus dem Output-Repository lassen sich dabei leicht, durch
Funktionen wie svn:externals, in die Verzeichnisstruktur des Projekt-Repositories eingliedern. Dieses Vorgehen bietet sich darüber hinaus auch sehr
in der Softwareentwicklung an, zur konfigurationsfreien Einbindung von Abhängigkeiten und auch Binaries, wie dies Julien Koenen in seinem Vortrag
auf der GDC Europe 2009 überzeugend dargelegt hat [8].
3.3.2.3
Continuous Integration
Continuous Integration ist eine Form der Softwareentwicklung, bei der durch
fortwährendes, automatisches Kompilieren und Testen zu jedem Zeitpunkt
eine weitgehende Fehlerfreiheit des Projektes sichergestellt werden soll. Im
Bezug auf die Asset-Pipeline, sind hierbei vor allem die hierzu verwendeten Buildsysteme von Bedeutung, welche, bei Änderungen im Repository,
automatisch verschiedene Prozesse starten können. Im Normalfall ist dies
das Kompilieren des Sourcecodes und die Abarbeitung verschiedener Tests.
Prinzipiell lassen sich aber beliebige Anwendungen ausführen, also auch die
Pipeline-Verarbeitung von Assets.
Auch, wenn solche Systeme, wie zum Beispiel CruiseControl 12 oder Apache Continuum 13 , nicht bei der Codeentwicklung angewandt werden, bietet
ihre Adaption für die Asset-Pipeline den Vorteil, dass, für die Automatisierung und Auslagerung der Pipeline-Prozesse, auf fertige und stabile Systeme
zurückgegriffen werden kann. Diese Systeme erfüllen alle nötigen Anforderungen, wie die Überwachung des Repositories auf Änderungen, Remotekonfiguration und Benachrichtigungen im Fehler- wie auch Erfolgsfall etc.
12
CruiseControl ist ein freies System zur Umsetzung kontinuierlicher Entwicklungsprozesse (http://cruisecontrol.sourceforge.net)
13
Continuous Integration Server unter der Apache License 2.0
(http://continuum.apache.org)
3. Asset-Pipelines
3.3.2.4
26
Release Packaging
Während sich das Release Packaging, im Softwarebereich, primär auf die Erstellung von Installern zum Deployment beschränkt und somit während des
Entwicklungsprozesses bestenfalls zu Testzwecken durchgeführt wird, hat es
bei der Verarbeitung von Assets, auch während der Entwicklung, eine wichtige Bedeutung, welche sich in erster Linie auf die Erstellung von Ressourcenpaketen bezieht.
Selbst wenn sich die Iterationszeiten dadurch verlängern, ist es, besonders im Hinblick auf Ladezeiten und das Sreaming von Daten, wichtig, auch
während der Entwicklung Laufzeitbedingungen zu schaffen, welche denen der
finalen Anwendung möglichst nahe kommen. Die verwendeten Mechanismen
entsprechen dabei jenen der Softwareentwicklung und lassen sich problemlos in automatische Build-Systeme, wie sie zur Continuous Integration angewandt werden, integrieren. Abweichend ist dabei lediglich die Regelmäßigkeit
des Packens. Beim Streaming sind, besonders bei Consolenentwicklungen,
oft umfangreiche und langwierige Optimierungen, zur Anordnung der Daten innerhalb des Paketes, erforderlich, was ein Packaging auf Grund kleiner
Änderungen impraktikabel macht. Hier sollte auf regelmäßige, zum Beispiel
nächtliche, Rebuilds zurückgegriffen werden, wobei sich Änderungen schnell,
durch das Überschreiben der jeweiligen Daten innerhalb des Ressourcenpaketes, durch externe Dateien testen lassen.
3.3.3
Game Asset-Pipelines als Mischform
Zusammenfassend, lässt sich festhalten, dass Asset-Pipelines für Spiele eine
komplexe Verknüpfung von Konzepten aus Contenterstellung und Softwareentwicklung sind. Bei ihrer Entwicklung und Umsetzung, sollte vor allem
einem Punkt, Rechnung getragen werden. Sie werden in erster Linie von Artists verwendet und somit muss das wichtigste Ziel darin bestehen, benötigte
Tools und Pipeline-Abläufe möglichst nahtlos in bekannte und etablierte Arbeitsweisen und -abläufe zu integrieren. Dies wird besonders im Umfeld von
FH-Projekten, aber auch im professionellen Bereich, allzu gerne unterschlagen, sollte jedoch bereits in die grundlegende Konzeption von Tools als, auch
der Engine selbst, einfließen. Anleihen aus dem, für Toolprogrammierer oftmals wenig bekannten, Gebiet der Content-Erstellung liegen also größtenteils
in den Bereichen der Bedienung, Verständlichkeit und allgemeinen Usability.
Viele Möglichkeiten der Implementierung lassen sich dagegen direkt, oder
mit geringeren Anpassungen, aus etablierten Systemen der Softwareentwicklung übernehmen.
Kapitel 4
Konzeption
Nach der Darlegung der verschiedenen Grundlagen und der Beschreibung
der Funktionsweisen einer Asset-Pipeline für Spiele, stellt sich nun die Aufgabe ihrer Konzeption. Wie bereits festgestellt, bietet sich durch die heute
vorhandene Rechenleistung, neben der klassischen Offline-Pipeline mit aufwändigem Preprocessing, auch die Möglichkeit zu einer Online-Pipeline mit
direktem Bridging zwischen Editoren und Engine. Die Grundlagen sind dabei
jedoch in beiden Fällen gleich oder sehr ähnlich, wodurch sich eine OfflinePipeline bei entsprechender Konzeption problemlos um eine Echtzeitanbindung erweitern lässt. Da dies jedoch einen weitaus größeren Entwicklungsaufwand und tiefgreifende Integration mit verwendeter Drittsoftware erfordert,
soll hier in erster Linie auf die klassische Offline-Pipeline eingegangen werden, zumal, besonders im Hinblick auf die Verwendbarkeit von Cogaen, die
schnelle Umsetzbarkeit der grundlegenden Pipeline-Funktionen im Vordergrund steht.
4.1
Wahl von Zwischenformaten
Bei beiden Formen der Pipeline kommen verschiedene Arten von Zwischenformaten zum Einsatz. Für viele Bereiche stehen etablierte (Industrie-)Standards zur Verfügung, welche jeweils verschiedene Vor- und Nachteile bieten. Einige dieser Nachteile, wie die Verlustbehaftung vieler Kompressionen,
sind offensichtlich, während andere sich erst in der praktischen Anwendung,
durch nicht einheitliches Verhalten von Im- und Exportern, zeigen, einem
Hauptgrund für die etwas detailliertere Betrachtung und Gegenüberstellung
verschiedener Formate an dieser Stelle.
4.1.1
Verschiedene Medien
Da die Spieleentwicklung praktisch alle Disziplinen der digitalen ContentErstellung abdeckt, soll hier keine vollständige Gegenüberstellung, aller in
27
4. Konzeption
28
Betracht kommenden Datenformate, sämtlicher Teilbereiche, erfolgen. Vielmehr sollen die bekanntesten Möglichkeiten verglichen und, besonders die
Probleme mit teilweise oft eingesetzten Formaten, angesprochen werden.
Darüber hinaus bezieht sich die folgende Gegenüberstellung in erster Linie auf die praktische Anwendbarkeit der unterschiedlichen Lösungen und
begründet sich in erster Linie auf Erfahrungen in verschiedenen Projekten.
Für weiterführende Informationen, sei an dieser Stelle jedoch Ben Carters
The Game Asset Pipeline [3] erwähnt.
4.1.1.1
Grafik
Grafik stellt einen grundsätzlich weiten Begriff dar, soll an dieser Stelle jedoch auf 2D-Rastergrafiken beschränkt werden. Diese finden in der Spieleentwicklung verschiedene Anwendungsbereiche: zum Beispiel als Texturen
auf 3D-Objekten, Sprites von Partikelsystemen, im User-Interface oder als
direkte Szenenelemente in 2D-Spielen.
Da es sich hierbei um ein sehr weit verbreitetes und in verschiedensten Formen verwendetes Medium handelt, existiert eine Vielzahl mehr oder
weniger bekannter Formate, von denen sich jedoch nur wenige zur Anwendung in Asset-Pipelines eignen. Viele, wie zum Beispiel JPEG, scheiden wegen ihrer verlustbehafteten Kompression grundsätzlich aus. Auch verlustfreie
Kompressionen, wie bei PNG, erweisen sich jedoch für ein Transfer-Format
in Pipelines wenig geeignet. Sie sind schlecht mit der Funktionsweise der
meisten Versionskontrollsysteme (der Protokollierung von Änderungen) zu
vereinbaren und der geringere Speicherverbrauch wird durch die Größe der
Changesets stark relativiert. Andere, bei Animation und Compositing eingesetzte Formate, wie das von Maya bevorzugte IFF, SGI oder ähnliche,
eignen sich, auf Grund ihres geringen Verbreitungsgrades und der damit eingeschränkten Unterstützung durch verschiedene Tools, nur bedingt.
Eine sehr gute Lösung scheint, zunächst, der TIFF -Container darzustellen. Das Format bietet, mit praktisch beliebigen Bittiefen, von 8 Bit Paletten
bis hin zu 32 Bit Float für HDR-Texturen, Alphakanälen etc., alle erdenklichen Optionen. Zudem bietet es die Möglichkeit zur Einbettung beliebiger
Metataten: beispielsweise die gewünschte Kompressionsart der finalen Texturen, benötigte Mipmaps, die Art des Filterings und so weiter. Gerade in
diesen, fast unbegrenzten Möglichkeiten, steckt jedoch auch die Problematik
dieses Formates: Die Exportoptionen verschiedener Tools lassen sich selten
eindeutig auf konkrete Formateigenschaften übertragen, wodurch es in der
Praxis, bei der Verwendung verschiedener Programme, insbesondere unterschiedlicher Hersteller, immer wieder zu Inkompatibilitäten kommt.
Crytek 1 umgeht dieses Problem, indem eigene Im- und Exporter für das
TIFF -Format verwendet werden, eine Lösung die zwar sehr komfortabel
1
Deutscher Spieleentwickler (http://www.crytek.com/)
4. Konzeption
29
ist, zumal beispielsweise der verwendete Photoshop-Exporter verschiedene
Vorschaufunktionen für die Kompression und ähnliches bietet, andererseits,
durch die nötige Eigenentwicklung der Exporter, einen nicht unerheblichen
Mehraufwand mit sich bringt.
Die krasse Alternative dazu wird mit Valves Source-Engine (siehe Abschnitt 2.2.2) verfolgt. Sie besteht in der Verwendung verschiedener, möglichst einfacher und damit durchwegs eindeutig behandelter Formate wie
TGA. Dieses bietet zwar nur RGB oder RGBA mit 8 Bit pro Kanal, deckt
damit aber die allermeisten Anwendungsfälle in der heutigen Spieleentwicklung ab. Lediglich für HDR-Skyboxes benötigt Valve, mit PFM 2 , ein weiteres
Bildformat in seiner Pipeline, während die zugehörigen Metainformationen
in, der jeweiligen Textur entsprechend benannten, Textdateien festgehalten
werden.
Eine solche, minimalistische Herangehensweise, erscheint für die erste Implementierung sehr geeignet. Sie bedarf nur eines sehr geringen Aufwandes
und bringt für den Workflow nur geringe Nachteile. Auch bei einer Umstellung auf ein beispielsweise TIFF -basiertes System, wie bei der CryEngine 3 ,
müsste nur sehr wenig Arbeit verworfen werden.
4.1.1.2
Sound
Im Soundbereich stellen sich sehr wenige Optionen für Transferformate. Da
Kompressionsverluste an dieser Stelle strikt zu vermeiden sind und auch
verlustfreie Kompressionen, wie beispielsweise FLAC 4 , wegen der relativ geringen Datenmengen bei Spielen, durch den zur Kodierung nötigen Zeitaufwand, mehr Nach- als Vorteile bringen, beschränkt sich die Auswahl im
Wesentlichen auf Container für unkomprimierte PCM-Daten.
Als bekannteste und am weitesten verbreitete Formate sind hier WAV
und AIFF zu nennen, welche sich, in ihrer Eignung und der Unterstützung
durch gängige Tools, kaum unterscheiden. Von diesen beiden hat WAV, auf
den in der Spieleentwicklung hauptsächlich eingesetzten Windows-Systemen,
eine sehr viel höhere Verbreitung und genießt im Spielebereich deshalb meist
den Vorzug. Auch bei der Neukonzeption einer Pipeline spricht nichts gegen
WAV, da sich AIFF kaum davon unterscheidet und keinerlei Vorteile bietet.
4.1.1.3
Metadaten
Die bereits mehrfach angesprochenen und in der Spieleentwicklung extrem
wichtigen Metadaten, werden in verschiedensten Formen festgehalten. Mitunter werden diese, wie bei der genannten TIFF -Implementierung von Cry2
Portable FloatMap, eine kurze Übersicht des Formates findet sich unter
http://projects.ict.usc.edu/graphics/HDRShop/PFM/PFM_Image_File_Format.html
3
Von Crytek entwickelte Game Engine
(http://www.crytek.com/technology/cryengine-3/specifications/)
4
Free Lossless Audio Codec (http://flac.sourceforge.net/)
4. Konzeption
30
tek, direkt in die jeweiligen Dateien integriert. Da dies bei den meisten Standardformaten jedoch nur in sehr geringem Umfang möglich ist, kommt eine
Vielzahl von zusätzlichen Dateien zum Einsatz, von denen INI -Files, Excel Sheets und XML nur eine kleine Auswahl darstellen. Das Hauptproblem bei
diesen zusätzlichen Metadateien stellt die nicht immer gewährleistete Synchronität mit den Daten dar, da sie bei Änderungen manuell aktualisiert
oder durch speziell angepasste Exporter parallel angepasst werden müssten.
Deshalb sind eingebettete Metadaten grundsätzlich vorzuziehen.
4.1.1.4
3D
Einen vergleichsweise problematischen Bereich stellen 3D-Daten dar, da hier
kaum geeignete Formate zur Auswahl stehen. Die meisten sind proprietäre Formate und wurden zudem nie zum Austausch zwischen verschiedenen
Programmen entwickelt, sondern sind, wie zum Beispiel 3DS 5 oder OBJ 6 ,
sehr alte, native Formate früherer DCC-Tools. Diese wurden im Laufe der
Zeit öffentlich spezifiziert oder von verschiedenen anderen Tools nachimplementiert, um zumindest einen grundlegenden Datenaustausch zu ermöglichen. Eine wirklich weitgehende Unterstützung hat sich dabei jedoch nur für
OBJ entwickelt. 3DS lässt sich dagegen, beispielsweise mit Maya, auch mit
Zusatztools, nur importieren. Viele andere Implementierungen unterstützen
darüber hinaus nur triangulierte 3DS -Daten.
Im Gegensatz zu diesen Formaten, für rein statische Objekte, stellt
FBX 7 , welches ursprünglich für die Motion-Capture- und Animationssoftware FiLMBOX (heute MotionBuilder 8 ) entwickelt wurde, eine Ausnahme
dar. Es unterstützt neben Geometrie- vor allem auch Animationsdaten. Zudem wurde es von Autodesk kontinuierlich zum Austauschformat zwischen
verschiedenen Programmen weiterentwickelt und wird heute von vielen Tools
unterstützt. Der Hauptnachteil von FBX besteht darin, dass das proprietäre
Format selbst undokumentiert ist und nur über das von Autodesk angebotene C++ SDK angebunden werden kann, womit eine FBX -basierte Pipeline
von Autodesks Updatezyklen abhängig ist.
Dieses Fehlen von wirklich universellen Austauschformaten für 3D-Daten
führte zur Entwicklung von COLLADA9 , welches von der Khronos Group 10 ,
im Januar 2006, als offizieller Standard übernommen wurde (nach [1, S.IX]).
Dieses offene, XML-basierte Format, wurde von Beginn an, als Austauschund besonders als Pipelineformat für Spiele, konzipiert und bietet umfangreiche Unterstützung für Polygonbasierte Szenen, Animationen, Shader und
5
3D Studio File Format, Meshformat von 3ds Max
3D Objekt-Format, ursprünglich von Wavefront Technologies entwickelt
7
http://www.autodesk.com/fbx
8
Motion-Capture und Animationssoftware der Firma Autodesk
(http://www.autodesk.vom/motionbuilder)
9
Mehr Informationen unter https://collada.org
10
http://www.khronos.org/
6
4. Konzeption
31
Physiksimulation. Ein weiterer Vorteil ist die Möglichkeit, das Format um beliebige Features, wie applikationsspezifische Zusatzinformationen oder Metadaten, zu erweitern. Diese können, ohne großen Aufwand, in die verfügbaren
Open-Source Im- und Exporter integriert werden.
4.1.2
COLLADA als zentrales Format
Insgesamt stellt COLLADA nicht nur für 3D-Daten eine sehr gute Lösung
dar, sondern kann durch seine Erweiterbarkeit auch zur Verknüpfung sämtlicher Asses dienen und beispielsweise als Levelformat verwendet werden.
4.1.2.1
COLLADA ist standardisiert und Open-Source
Eine wichtige Grundlage für solche Erweiterungen ist, neben der expliziten
Unterstützung durch das Format, dass COLLADA eine frei zugängliche und
standardisierte Spezifikation zu Grunde liegt. Anders als zum Beispiel bei
FBX, unterliegen Eigenentwicklungen somit nicht der Gefahr, durch unvorhergesehene Änderungen inkompatibel zu werden, sondern sie lassen sich
auf Basis einer konkreten Version umsetzen und im Bedarfsfall auf neuere
Revisionen portieren.
Ein Hauptvorteil besteht darin, dass sich COLLADA DOM 11 , die zentrale Library zum Umgang mit dem Format, durch einen frei zugänglichen
Code-Generator aus dem COLLADA Schema 12 erzeugen lässt. Dies ermöglicht es, Erweiterungen und Anpassungen einfach auf Basis des Schemas vorzunehmen, wodurch sich diese, praktisch nahtlos, in das Format integrieren.
Durch Merging des Schemas lassen sich Änderungen zudem sehr einfach auf
neue Versionen portieren.
Auch die sonstigen, relevanten Tools, wie die Pipeline Anwendung
COLLADA Refinery 13 und Translator-Plug-Ins, sind im Sourcecode erhältlich, was insbesondere bei den Exportern wichtig ist. Durch deren Quellenverfügbarkeit wird einerseits ermöglicht, die benötigten Anpassungen des
Formates vorzunehmen, ohne die Exporter vollständig neu zu schreiben, andererseits können auch Daten aus anderen Plug-Ins, welche vom verwendeten
DCC-Tool nicht nativ unterstützt werden, berücksichtigt werden.
4.1.2.2
Geeigneter und vielseitiger Aufbau
Die Eignung von COLLADA zur zentralen Verknüpfung sämtlicher AssetDaten, lässt sich jedoch vor allem auf den Aufbau des Formates zurückführen, welches vielseitige Möglichkeiten zur Referenzierung und Instanzi11
https://collada.org/mediawiki/index.php/Portal:COLLADA_DOM
Erhältlich unter http://www.khronos.org/files/collada_schema_1_4 beziehungsweise
http://www.khronos.org/files/collada_schema_1_5
13
Eine kurze Übersicht über COLLADA Refinery findet sich unter
http://collada.org/mediawiki/index.php/COLLADA_Refinery
12
4. Konzeption
1
2
3
4
5
6
7
8
9
10
11
32
...
<library_visual_scenes>
<visual_scene id="VisualSceneNode" name="example">
...
</visual_scene>
</library_visual_scenes>
...
<scene>
<instance_visual_scene url="#VisualSceneNode"/>
</scene>
...
Programm 4.1: Beispiel für die Unterscheidung zwischen Libraries und
Szene im COLLADA-Format
ierung von Daten ermöglicht. Das einzige notwendige Element unterhalb
von <COLLADA> ist dabei <asset>, welches Informationen über die Datei
selbst, also Autor, Quelldatei, Änderungszeit etc. enthält. Das zur Darstellung erforderliche <scene>-Element ist dagegen optional, was Dateien
ermöglicht, welche lediglich verschiedene, dann meist mehrfach genutzte,
Daten bereitstellen ohne, diese selbst in einer Szene zu platzieren. Diese
Daten werden in einer Vielzahl von <library_*>-Elementen, beispielsweise
<library_visual_scenes>, verwaltet und wie im Beispiel (Prog. 4.1) über
URIs referenziert.
Durch die Verwendung von URIs muss sich die verwendete Ressource
dabei jedoch nicht in der gleichen Datei befinden. Sie kann von praktisch
beliebigen Datenquellen bereitgestellt werden. Während beispielsweise Texturen wie bei praktisch jedem 3D-Format aus externen Dateien referenziert
werden, können so, auch die in COLLADA selbst enthaltenen Daten, wie
Geometrie, Animationen oder Materialien, aus verschiedenen Dateien referenziert werden. So lässt sich leicht eine Library von wiederverwendbaren
Assets, wie Materialien, Objekten, Characters oder ganzen Teilszenen, aufbauen. Die einzelnen Assets lassen sich dabei zudem unabhängig voneinander, also auch parallel, erstellen.
Dieser Punkt ist bei der Entwicklung in Teams wichtig. Die Referenzierung bietet in Verbindung mit der Anpassbarkeit des Formates jedoch auch
viele weitere Möglichkeiten, insbesondere im Hinblick auf die Verwendung als
Pipelineformat. Da Veränderungen am Format durch beliebige eigene Profile
umgesetzt werden, welche lediglich alternativ zur Default-Implementierung
angeboten werden, kann COLLADA durch die Pipeline nahtlos vom Transferformat in ein optimiertes Laufzeitformat umgesetzt werden, wobei die Verarbeitung sowohl zur Laufzeit als auch im Preprocessing geschehen kann.
Dies lässt sich anhand des einfachen Beispiels von Polygonmeshes verdeutlichen: Die hierfür benötigten Arrays von Vertexpositionen, Faces, Texturko-
4. Konzeption
33
ordinaten etc. werden normalerweise in COLLADAs XML-Struktur, also als
Klartext, gespeichert. Durch den damit verbundenen Overhead zum Parsen
und die Größe der Dateien, eignet sich COLLADA als solches, relativ schlecht
als Laufzeitformat, jedoch lässt sich dies durch die Implementierung eigener
Profile leicht umgehen. Diese können die benötigten Daten aus optimierten
Binärdateien referenzieren und bei der Entwicklung für mehrere Plattformen
lassen sich zudem alle in der gleichen Datei angeben, da nur das beste von
der jeweiligen Plattform unterstützte Profil zur Anwendung kommt. Dies ist
im schlechtesten Fall die Standartimplementierung und somit lässt sich auch
leicht eine On-Demand Optimierung implementieren, indem die Engine beim
ersten Laden der Daten auf das Standardprofil zurückgreift und die erstellten
Laufzeitdaten in ein entsprechendes Profil überträgt, ein Konzept, welches
in gleicher Weise auch im Preprocessing umgesetzt werden kann.
Wenn beim finalen Packaging sämtliche für die Zielplattform irrelevanten
Profile und somit auch die Daten der Standardimplementierung entfernt werden, lässt sich COLLADA, trotz des durch XML entstehenden Overheads,
auch als relativ gut optimiertes Laufzeitformat für Characters, Levels und
Ähnliches verwenden, welches lediglich die nötigen Informationen über den
Szenenaufbau, wie Positionen oder Hierarchien von Objekten, und verschiedene benötigte Metadaten enthält, während alle sonstigen Daten aus entsprechend angepassten Binärdaten referenziert werden.
4.2
Tools zur Contenterstellung
Neben den verwendeten Formaten sind beim Aufbau einer Pipeline natürlich
die verwendeten Tools von entscheidender Bedeutung. Für viele der verwendeten Assets können hierbei Standardtools zum Einsatz kommen, nach denen sich zum Teil auch die Auswahl der in der Pipeline verwendeten Formate
richtet. Andere Daten sind dagegen sehr spezifisch für die Spieleentwicklung
oder gar die konkrete Engine, weshalb für diese spezielle Tools, oder zumindest entsprechende Plug-Ins, benötigt werden. In beiden Fällen ist eine möglichst nahtlose Integration in die etablierten Abläufe der Contentproduktion
von großer Bedeutung. So sollte bei der Toolentwicklung, neben der reinen
Funktionalität, auch auf die Usability Wert gelegt werden. Diese kommt bei
verschiedenen Exportern, Editoren und Preview-Applikationen im Spielebereich leider immer wieder zu kurz; die Asset-Tools der Gamebryo-Engine 14
(Version 2.3) stellen dabei nur ein Beispiel unter vielen dar.
14
Mehr Informationen zur Engine auf der Produktseite unter
http://emergent.net/en/Products/Gamebryo/
4. Konzeption
4.2.1
34
3D und Animation
Anders als bei den Formaten gestaltet sich die Auswahl an Tools zur Erstellung von 3D-Assets sehr vielseitig. Die Toolchain kann sich dabei, wie
im reinen Animationsbereich, zum größten Teil an persönlichen Vorlieben,
bereits vorhandenen Lizenzen oder speziellen Features orientieren und auch
der Einsatz verschiedener Tools ist dabei möglich. Der Vielfalt sind dabei
kaum Grenzen gesetzt und während manche Tools bei Modellierung oder
Animation vielleicht gewisse Vorteile und Arbeitserleichterungen bringen,
sind beispielsweise zum Sculpting ohnehin zusätzliche Programme notwendig.
Lediglich die Zusammenführung und der Export aller Daten sollte in
einem oder wenigen Tools erfolgen, um den Entwicklungsaufwand für die
Pipelineanbindung in Grenzen zu halten. In Ermangelung ausreichend vielseitiger, verbreiteter oder bedienbarer Alternativen, wird die Entscheidung
in den meisten Fällen auf einen der großen Drei von Autodesk fallen:
3ds Max erfreut sich trotz seiner Unübersichtlichkeit speziell beim Nachwuchs großer Bekanntheit und findet besonders in der Spielebranche weite
Verbreitung.
Maya war lange Zeit mit Abstand am teuersten und gründet seine Mächtigkeit vor allem auf die umfangreiche aber auch notwendige Erweiterbarkeit.
Softimage führt dagegen zwar ein relatives Nischendasein, dürfte aber das
innovationsfreudigste der genannten Tools sein und steht Maya zumindest
durch die jüngeren Neuerungen an Vielseitigkeit kaum nach.
Was die Anforderungen der Spieleentwicklung betrifft, lässt sich tatsächlich kaum eine rationale Entscheidung zwischen diesen genannten Tools treffen und das praktisch einzige objektive Auswahlkriterium wären wohl die
Lizenzkosten, weshalb der Schwerpunkt dieser Arbeit auf dem, an der FHHagenberg ohnehin verwendeten, Maya liegt.
4.2.2
2D-Grafik
Der 2D-Grafikbereich bei Spielen unterscheidet sich wenig von anderen Branchen und verbindet vielmehr sehr verschiedene Disziplinen. Neben der Texturierung von Objekten, spielt auch das Design beziehungsweise Skinning von
Interfaces eine wichtige Rolle. Dieser Vielfalt entsprechend können auch diverse Tools zum Einsatz kommen: Eine klassische Bildbearbeitungssoftware,
wie Photoshop 15 , bildet für die meisten Anwendungen und zum Export eine wichtige Grundlage, doch verschiedene Spezialtools können den Workflow
entscheidend vereinfachen oder beschleunigen. Beim realistischen texturieren, besonders von organischen Objekten, können die 3D-Painting Funktio15
Verbreitete Bildbearbeitungssoftware der Firma Adobe
(http://www.adobe.com/photoshop)
4. Konzeption
35
nen von Programmen, wie ZBrush 16 oder Mudbox 17 , große Arbeitserleichterungen bringen, aber auch Programme zur Erstellung von Vektorgrafiken
eignen sich, je nach gewünschtem Stil, zur Texturierung, aber besonders zur
Gestaltung von Interfaceelementen für Menüs und HUDs.
Wichtig ist dabei, wie auch im 3D-Bereich, lediglich die Anbindung an die
verwendeten Pipelineformate, was bei der Verwendung von einfachen Standartformaten, wie TGA, in den seltensten Fällen problematisch ist. Lediglich
wenn, wie für die CryEngine, spezielle Exporter benötigt werden, wird sich
die Pipelineanbindung wohl auf nur ein einziges oder wenige Programme beschränken können, welches dann, ähnlich wie bei den 3D-Daten, als zentrales
Tool zur Zusammenführung der Daten dient.
4.2.3
Sound
Auch im Soundbereich lässt sich, zumindest zur Erstellung und Bearbeitung,
praktisch jede verfügbare Standardsoftware verwenden, da wohl jede zumindest WAV unterstützt. Zudem sind hier, im Gegensatz zu Bildformaten, auch
keine Metadaten erforderlich, welche sich abseits der Standardimplementierungen bewegen. Mitunter benötigte Cue- und Looppoints gehören ebenso
zum Format, wie ein entsprechendes Labeling dieser Punkte. Neben der Markierung von Loops oder beliebigen Events, lassen sich diese beispielsweise
ebenso leicht für Lipsync-Daten verwenden. Zur Erstellung solcher Daten
sind zwar spezielle Tools notwendig, der Vorteil liegt aber darin, dass normale Features des Formates verwendet werden können. Dadurch gehen die
Daten bei Änderungen, wie einem Umschnitt, nicht verloren, sondern werden
sogar an die Änderungen angepasst.
4.2.4
Game-spezifisches
Neben Assets, für die Standardtools zur Verfügung stehen und dementsprechend auch verwendet werden sollten, erfordern Spiele verschiedene, spezielle
Daten, die sich je nach Genre und verwendeter Technologie stark unterscheiden und somit keinen Markt für Drittanbieter darstellen. Die angesprochenen
Lipsync-Daten für Audiofiles sind dabei ein sehr spezielles Beispiel und die
standardkonforme Einbettung in die jeweiligen WAV -Dateien, nur eine von
vielen möglichen Lösungen, welche beispielsweise bei der Source-Engine zum
Einsatz kommt. Der wichtigste Aspekt dieses Bereiches besteht jedoch in der
Definition von Objekten, welche mit der Programmlogik verknüpft werden.
Dies umfasst alles, womit der Spieler interagiert: Bewegliche und zerstörbare
Objekte, spielbare und nicht spielbare Charaktere und komplette Levels.
16
17
Sculpting Programm (2.5D) der Firma Pixologic (http://www.pixologic.com)
3D-Sculpting Anwendung der Firma Autodesk (http://www.autodesk.com/mudbox)
4. Konzeption
4.2.4.1
36
Dedizierte Tools
Die meisten Toolchains für Spiele beinhalten, zur Erstellung solcher spieloder enginespezifischen Daten, verschiedene proprietäre Anwendungen, welche in ihrer Komplexität durchaus mit professionellen 3D-Anwendungen vergleichbar sind. Das wichtigste Tool ist hierbei der klassische Leveleditor,
der je nach Enginearchitektur verschiedene Aufgaben erfüllt und bei weitem
nicht (mehr) nur der Erstellung oder Platzierung von Umgebungsgeometrie
dient.
In jedem Fall ist eine Platzierung und logische Verknüpfung von Spielrelevanten Objekten und die Einstellung globaler Mapeigenschaften nötig.
Praktisch immer erforderliche Beispiele sind dabei Startpunkte für Spieler
und die Festlegung von Siegbedingungen beziehungsweise Ladepunkte für
angrenzende Levels, andere sind dagegen sehr vom jeweiligen Spiel abhängig
und variieren stark in ihrer Komplexität. Während bei Multiplayerspielen in
erster Linie eine faire Verteilung von Items, Waffen oder Ressourcen wichtig
ist, werden im Singleplayer viele weitere Daten benötigt.
KI-Charaktere müssen platziert werden und brauchen eine Vielzahl von
Informationen über ihre Umgebung (das Level): Zu einfachen Navigationsmeshes, welche nach einer meist automatischen Generierung oft angepasst
werden müssen, kommen verschiedene spezielle Punkte oder Objekte. Dies
sind beispielsweise Deckungsmöglichkeiten, Angriffsziele oder Objekte auf
welche der Spieler aufmerksam gemacht wird, um seinen Spielfluss und die
Story voran zu bringen. Andere dienen schlicht dazu, KI-Charaktere lebendiger wirken zu lassen, indem sie auf Auffälligkeiten in ihrer Umgebung reagieren können („Igitt, überall Blut!“ oder ähnliche, eigentlich sinnlose, Aussagen
am Rande des Spielgeschehens).
Neben Quests und Dialogoptionen in RPGs18 oder Adventure-Games,
sind sehr komplexe Setups, beispielsweise auch für in-Game Cinematics, wie
in Half-Life 2, nötig, bei denen der Spieler die Kontrolle über die Spielfigur
behält. Anders als klassische Cutscenes, welche als einfache Animation abgespielt werden können, erfordern diese eine Vielzahl von Markierungen und
entsprechende KI-Scripts, was durch ein Beispiel schnell deutlich wird:
Angenommen, der Spieler erreicht zusammen mit einem NPC eine Türe mit Codeschloss, welche nur vom NPC geöffnet werden kann. Nachdem
die Türe geöffnet wurde, gehen beide hindurch, sie schließt sich wieder und
das normale Spielgeschehen wird fortgesetzt. Bei einer Cutscene folgt nach
dem Betreten eines Triggers19 eine feste Animation beider Charaktere und
der Spieler erhält die Kontrolle jenseits der Türe zurück. Eventuell plötzliche Positionswechsel lassen sich dabei durch geschickte Kameraeinstellungen
18
Role Playing Games
Trigger bezeichnet im Leveldesign ein unsichtbares Volume, das, durch verschiedene
Kontanktzustände von Objekten (on enter, on leave, while touching, while inside etc.),
Ereignisse auslösen kann
19
4. Konzeption
37
verbergen. Behält der Spieler jedoch die Kontrolle, ergibt sich folgendes Setup:
• Der Spieler betritt Trigger A und löst so die Szene aus.
• Der NPC läuft zu Punkt B vor dem Codeschloss. Steht der Spieler
dabei im Weg, muss er gebeten werden, zur Seite zu treten. Entfernt
er sich zu weit vom NPC, folgt ihm der NPC und fordert ihn auf, ihm
zu folgen, während er sich zu Punkt B zurück bewegt.
• Hat der NPC Punkt B erreicht, betätigt er das Codeschloss. Dabei
wird seine Hand, mittels IK20 , exakt über dem Eingabepanel platziert,
wofür eine weitere Markierung C notwendig ist.
• Anschließend tritt der NPC durch die Türe, zum Punkt D und fordert
den Spieler auf, ihm zu folgen. Entfernt sich der Spieler währenddessen
zu weit vom NPC, folgt dieser dem Spieler, und fordert ihn auf, ihm
zu folgen, während er sich wieder zu Punkt D bewegt.
• Befinden dich beide innerhalb von Trigger E, jenseits der Türe, schließt
sich diese und die KI des NPC kehrt in ihren normalen Status zurück.
Insgesamt werden für diese einfache Szene also fünf Markierungen, zwei
KI-Scripts („Erreiche Punkt X und halte den Spieler dabei innerhalb von Radius Z“, „Berühre Punkt X mit der Schreibhand“) und diverse Sprachszenen
benötigt. Diese müssen innerhalb des Leveleditors platziert und verknüpft
werden. Zu diesem Zweck dienen entweder schriftliche Scripts oder grafische
Systeme, wobei beide Vor- und Nachteile haben: Grafische Editoren sind für
Artists meist intuitiver zu bedienen und führen bei einfachen Aufgaben oft
schneller zu Ergebnissen. Schriftliches Scripting bietet dagegen vielseitigere Möglichkeiten und erfordert weniger Vorausplanung eventuell benötigter
Funktionen.
Über die reine Levelerstellung hinaus werden die entsprechenden Editoren jedoch zunehmend um weitere Funktionen erweitert, beispielsweise
zur Erstellung von Partikelsystemen, Shadern beziehungsweise Materialien und Charactersetups, was besonders durch moderne Animationssysteme
zunehmend an Bedeutung gewinnt. Während früher einfache Modelviewer
zur schnellen Kontrolle der Exportierten Modelle und Animationen ausreichend waren, benötigen heutige Systeme aufwändige Setups von Ragdolls,
IK-Chains, Animationsüberblendungen, Gesichtsanimationen oder gar zur
Integration prozeduraler Systeme, wie Morpheme 21 . Der Umfang und die
Vielseitigkeit all dieser Funktionen trägt enorm zur Komplexität moderner Level- oder besser Game-Editoren bei, was zu verschiedenen Problemen
20
Inverse Kinematik
Prozedurales Echtzeit Animationssystem der Firma NaturalMotion
(http://www.naturalmotion.com/morpheme)
21
4. Konzeption
38
führt. So ist der allgemeine Entwicklungsaufwand, im Vergleich zu den früher oft sehr einfachen Leveleditoren, stark gestiegen und besonders Engines
mit weit zurückliegenden Wurzeln stehen vor dem Problem, dass die stetig
weiterentwickelten Tools an ihre architekturbedingten Grenzen stoßen und
mit der Integration immer weiterer Features zunehmend instabiler werden.
4.2.4.2
Integration ins 3D-DCC-Tool
Eine Möglichkeit zur Reduzierung dieses großen Entwicklungsaufwandes ist
die Integration der benötigten Features in ein bestehendes DCC-Tool wie
Maya. Dieser Ansatz ist vor allem bei kleinen Engines verbreitet und dort
leider selten wirklich gut und oft wenig robust umgesetzt, weshalb dem Konzept tendenziell der Ruf einer billigen Notlösung anhaftet. Betrachtet man
aber ähnliche Integrationen beispielsweise im Bereich von Renderern, so sind
Vue xStream 22 oder RenderMan for Maya 23 ausgezeichnete Beispiele für eine
praktisch nahtlose und stabile Einbindung von Third-Party-Features in verschiedene DCC-Tools. Tatsächlich ist im Fall von Maya gerade der modulare
Aufbau und die besonders gute Erweiterbarkeit einer der Hauptgründe für
seine weite Verbreitung im Filmbereich, da hier häufig Eigenentwicklungen
neuer Technologien zum Einsatz kommen, die dementsprechend (noch) nicht
von Standardtools angeboten werden, während, das Programm für sich genommen, anderen Lösungen in manchen Bereichen durchaus unterlegen ist.
Bei dieser Integration von Features mittels Plug-Ins, ist der genannte,
geringere Entwicklungsaufwand jedoch auf keinen Fall mit einem Minimalaufwand zu verwechseln, wie er häufig von preisgünstigeren Engines betrieben wird. Es genügt in aller Regel nicht, den gegebenen Funktionsumfang
durch einen Exporter und verschiedene Scripts zu ergänzen, sondern vielmehr
muss das verwendete System in der konzeptionellen Betrachtung auf seine relevanten Basisfunktionalitäten reduziert werden: Ein erprobtes und stabiles
GUI-System mit 3D-Interaktion24 und Szenenverwaltung. Dazu kommt der,
weniger technische, Aspekt, der etablierten und langjährig bewährten Bedienungskonzepte, welche von Eigenentwicklungen, obwohl problemlos nachimplementierbar, oft genug ignoriert werden. Davon ausgehend lassen sich die
gleichen Features implementieren, wie dies auch bei Stand-Alone Editoren
der Fall ist: Beliebige Tools, eigene Geometriearten wie CSG, Terrains, Echtzeitshader, die Einbindung des eigenen Renderers oder der Physikengine,
Echtzeitanbindung an die Engine und vieles mehr.
Zudem bietet die Verbindung von Modeler und Leveleditor sogar Vorteile
22
Landschafts-Renderer der Firma e-on Software
(http://www.e-onsoftware.com/xstream)
23
Maya-Integration von Pixars Renderer RenderMan
(http://renderman.pixar.com/products/tools/rfm.html)
24
Wichtig sind hierbei vor allem die Funktionen zur Selektion und Manipulation im
3D-Raum
4. Konzeption
39
im Workflow: Heutige Engines, deren Levels meist meshbasiert sind, haben
gegenüber älteren Ansätzen, bei denen die Levelgeometrie im Level-Editor
erstellt wird, den Nachteil, dass Änderungen und Anpassungen von Objekten
stets in einem externen Modeler erfolgen müssen. Es ist also notwendig, die
Quelldatei, des entsprechenden Teilstücks des Levels, gesondert zu öffnen,
die Änderungen durchzuführen und es anschließend neu zu exportieren, was
im seltenen Idealfall über ein automatisches Bridging in Echtzeit geschieht.
Ist der Leveleditor dagegen in das DCC-Tool integriert, stehen sämtliche
Modellierungswerkzeuge jederzeit zur Verfügung und die Objekte können direkt im Level angepasst werden, was den zusätzlichen Vorteil bringt, dass
auch die umgebenden Objekte vorhanden sind und so als Referenz dienen
können. Dies stellt bei entsprechender Implementierung auch kein Problem
für mehrfach genutzte, referenzierte Objekte dar. Diese können auf Nachfrage überschrieben, oder als neue Variante gespeichert werden, wobei die
Referenzen automatisch aktualisiert werden.
Den einzigen Nachteil einer solchen integrierten Lösung stellt, vor allem
im Bereich der Versionskompatibilität, die Abhängigkeit von entsprechenden
Drittanbieter dar. Da aber auch die Filmbranche seit Jahren große Investitionen in vergleichbare Lösungen tätigt, ist hier, zumindest in der praktischen
Umsetzung, kaum mit Problemen zu rechnen. Generelle Bedenken gegenüber
eines möglichen Vendor Lock-Ins lassen sich dagegen selbstverständlich nicht
ausräumen.
4.3
Versionsverwaltung und Kollaboration
Ein einheitlicher Versionsstand ist Grundvoraussetzung für die effektive Zusammenarbeit. Dies gilt in der Spieleentwicklung nicht nur für die Quelldateien selbst, sondern besonders auch für die verschiedenen Produkte. Da hier,
mit Asseterstellung und Programmierung, zwei sehr unterschiedliche Bereiche zusammenarbeiten, ist es nicht, wie in der reinen Softwareentwicklung,
möglich, dass jeder Entwickler seine Binaries selbst kompiliert, und somit
nur die Quellen synchronisiert werden müssen. Vielmehr benötigen beide
Seiten Zugriff auf die Produkte der jeweils anderen, die Programmierer auf
die Assets im Laufzeitformat und die Artists auf aktuelle Programmdateien.
Ein Builden des gesamten Projektes am jeweiligen Arbeitsplatz ist dagegen,
aus Zeitgründen, fehlendem Know-how und der dann lediglich zum Builden
benötigten Lizenzen, nicht praktikabel.
4.3.1
Aufteilung der Projektstruktur
Da also Binaries benötigt werden, ist der sonst durchaus sinnvolle Grundsatz, diese nicht ins Repository einzupflegen hinfällig. Grundsätzlich sinnvoll
ist dieser jedoch, da er einem allzu schnellen Verbrauch, des, gut abgesicherten und damit teuren, Speicherplatzes im Versionsverwaltungssystem,
4. Konzeption
40
entgegenwirkt. Ein Problem, welches sich aber lösen, oder zumindest abschwächen lässt. Nicht für alle Projektdaten, insbesondere die Binaries und
Runtime-Assets, ist eine besondere Datensicherheit erforderlich und somit
stellt die einfachste Lösung die Aufteilung auf verschiedene Repositories und
Speichersysteme dar.
4.3.1.1
Code Repositories
Die Code Repositories enthalten, wie auch in der normalen Softwareentwicklung, sämtliche für das Projekt benötigten Sourcecodes. Da auch hier in sehr
verschiedenen Bereichen, wie Engine, Tools und Spiellogik, gearbeitet wird,
kann aber eine weitere Aufteilung auch an dieser Stelle sinnvoll sein. Dies
gewährleistet eine klare Trennung zwischen verschiedenen Projektteilen und
vermeidet damit Abhängigkeiten zwischen verschiedenen Projekten. Gleichzeitig wird so auch die Weitergabe abgeschlossener Teile an Lizenznehmer
vereinfacht.
Wie auch immer sich die genaue Ausprägung des oder der Code Repositories gestaltet, hat die Datensicherheit unbedingte Priorität, womit die
Kosten für den hier verwendeten Speicherplatz entsprechend hoch sind. Der
Grund für die Trennung von nicht weniger wichtigen Asset Repositories liegt
dabei vielmehr in der Langen Lebensdauer der Codebasis. Diese wird, im Gegensatz zu Assets, oft über lange Zeit und mehrere Projekte weiterentwickelt
und lässt sich somit nicht einfach nach Projektabschluss archivieren.
4.3.1.2
Artist Workspace
Der Artist Workspace beinhaltet sämtliche Assets in den nativen Formaten
der zur Erstellung verwendeten Programme, also Maya-Files (.mb), Photoshop-Dateien (.psd) und dergleichen. Auch dieses Repository erfordert eine
ähnliche Datensicherheit wie die Codebasis, jedoch kann das große Datenvolumen an dieser Stelle durchaus ein Problem darstellen.
Nicht nur sind die verwendeten Binärdaten grundsätzlich schlecht für die,
meist auf Changesets basierende, Versionierung geeignet, sondern zur Verarbeitung ist zudem die bestmögliche Qualität der Daten empfehlenswert.
Bilder sollten mit 16 Bit pro Kanal verarbeitet werden anstatt der später
üblichen 8 Bit, um Qualitätseinbußen bei Überblendungen und Filtern zu
vermeiden. Gleiches gilt für Audiodaten, die üblicherweise, mit einer Quantisierung von mindestens 24 Bit, verarbeitet werden, während im Endprodukt
16 Bit meist ausreichen. Gegenüber High-Poly Modellen, zur Generierung
von Normalmaps, die nicht selten jeweils mehrere Hundert Megabytes in
Anspruch nehmen, sind dies jedoch relativ kleine Posten der Gesamtbilanz.
Neben diesen, bereits problematischen Grundvoraussetzungen, ist aber
auch die im Artist Workspace erforderliche Arbeitsweise einem sparsamen
Umgang mit Speicherplatz wenig zuträglich. Es werden an dieser Stelle nicht
4. Konzeption
41
nur Daten benötigt, die tatsächlich ihren Weg in das finale Produkt finden,
sondern es sind immer wieder gestalterische Alternativen und Testszenarien
für verschiedene Lösungsansätze erforderlich, welche parallel abrufbar sein
müssen, um einen direkten Vergleich zu ermöglichen.
Ein Vorteil bietet sich lediglich dadurch, dass Assets im Gegensatz zu
Programmcode normalerweise nur für ein konkretes Projekt benötigt werden. Eine Weiterverwendung in anderen Projekten scheitert meist am Design, beziehungsweise der weiterentwickelten Technologie (Polygonanzahl,
Texturauflösung). Somit lassen sich die Daten nach Projektabschluss, spätestens aber nach der Supportphase, archivieren und benötigen keinen weiteren
Zugriff über das Repository, weshalb diese von Beginn an in einem vom
Sourcecode unabhängigen System verwaltet werden sollten.
4.3.1.3
Transferdaten der Pipeline
Die Eingangsdaten der Pipeline, also die in das Zwischenformat exportierten
Daten sind von zentraler Bedeutung für die Verknüpfung der Assets und
die gemeinsame Arbeit an verschiedenen Teilen des Projektes. Diese lassen
sich zwar jederzeit neu aus ihren nativen Quellen exportieren, bilden aber
den verfügbaren Pool von Assets, aus dem die benötigten Daten referenziert
werden, und müssen daher ebenfalls zentral zur Verfügung gestellt werden.
Zudem sollte dieser Datenbestand genau die vom Projekt benötigten Assets umfassen, wodurch sein Versionsstand die Grundlage für die Buildversion der Laufzeitdaten bilden kann. Dadurch dient er gleichzeitig als Basis
für die automatisierte Pipelineverarbeitung, indem Änderungen an diesem
Repository das Buildsystem starten und eine Synchronisierung der Laufzeitdaten bewirken.
4.3.1.4
Runtime Repository
Wie bereits eingangs erwähnt, erfordert die Spieleentwicklung auch die zentrale Verwaltung der ausführbaren Programmdateien und der Laufzeitassets,
beziehungsweise wird sie dadurch deutlich vereinfacht. Allein schon wegen
des teilweise großen Zeitaufwandes für die Verarbeitung von Assets in der
Pipeline ist eine Auslagerung dieser Prozesse vom Arbeitsplatzrechner auf eine dedizierte Infrastruktur erstrebenswert, was im direkten Widerspruch zur
sonst oft gebräuchlichen Praktik des Source-Check-out mit anschließendem
Kompilieren ist.
Doch dies ist nicht der einzige Grund für die zentrale Bereitstellung der
Lauftzeitdaten, welche am komfortabelsten ebenfalls über das Versionsverwaltungssystem erfolgt. Da mit Programmierern und Artists zwei Fachbereiche mit sehr unterschiedlichem Hintergrund beteiligt sind, ist nicht das nötige
Know-how in der jeweils fremden Domäne vorauszusetzten. So bestünde ein
Rebuild der Programmdateien beziehungsweise der Assets im Idealfall zwar
4. Konzeption
42
im einfachen Ausführen eines entsprechenden Setup-Scriptes, jedoch ist in
der Praxis damit zu rechnen, dass abweichende Systemkonfigurationen und
ähnliches immer wieder zu Fehlern führen.
Einfache Beispiele hierfür wären Library Dependencies, welche selbst bei
reinen Softwareprojekten, zumindest im Open-Source Bereich, oft mangelhaft dokumentiert sind, aber auch Asset-Tools deren Einstellungen vom
Standard abweichen. Während sich solche Probleme durch eine lückenlose
Dokumentation vielleicht lösen ließen, stellen die Kosten für lediglich zum
Builden benötigte Lizenzen jedoch ein klares Argument für die Versionierung
der Laufzeitdaten, sowie der Programmdateien dar.
4.3.1.5
Dependencies und Tools
Mit der Einbindung von Dependencies hat Julien Koenen [8] auf der GDC
Europe 09 einen weiteren wichtigen Aspekt angesprochen. Dies geschah zwar
vor allem im Hinblick auf die gleichzeitige Entwicklung mehrerer Projekte und die damit verbundene Verwendung unterschiedlicher Versionen von
SDKs und Tools. Die zugrunde liegende Problematik lässt sich aber auch in
anderen Fällen nachvollziehen. Häufig werden Dependencies über entsprechende Umgebungsvariablen referenziert, was auch beim Cogaen-Projekt der
Fall ist.
Dies erfordert ein aufwändiges Setup der jeweiligen Workstations, was
bei Projektbeginn und auch beim Ersatz von Ausfällen unnötig lange Verzögerungen bewirkt. Das Hauptproblem liegt jedoch in der Umgebungsabhängigkeit des Buildpozesses, wodurch das Endprodukt nicht eindeutig reproduzierbar ist. Die einfache Lösung besteht auch bei diesem Problem darin,
sämtliche Dependencies, als auch die verwendeten Pipelinetools in Repositories zu verwalten, die sich so leicht in die jeweilige Projektstruktur integrieren
und von dort über relative Pfade referenzieren lassen.
4.3.1.6
Projekt Repository
Anders als die restlichen Repositories enthält das Projekt Repository selbst
praktisch keine Daten, sondern dient in erster Linie der Strukturierung.
Dabei werden externe Inhalte in die entsprechenden Verzeichnisse referenziert, wodurch, trotz der Verwendung verschiedener Quellen, nur ein einziger
Check-Out ohne weitere Konfiguration nötig ist. Dies lässt sich, durch Mechanismen wie svn:externals oder Multi-Line-Views von Perforce, leicht
umsetzen und ermöglicht eine eindeutige Projektumgebung mit minimalem
Konfigurationsaufwand der einzelnen Clients.
4. Konzeption
4.4
43
Weiterverarbeitung der Assets
Die Weiterverarbeitung des Contents ins jeweilige Laufzeitformat ist die eigentliche Aufgabe der Asset-Pipeline und stellt dennoch nur einen kleinen
Aspekt der Gesamtkonzeption dar, wobei sich verschiedene Möglichkeiten
zur Umsetzung anbieten.
Heutige Systeme erlauben in vielen Fällen eine On-Demand Konvertierung, entweder im Editor, oder während des Ladevorgangs durch die Engine,
aber auch klassische Offline-Pipelines haben längst nicht ausgedient, sondern sind noch immer die einzige Möglichkeit zur Umsetzung realistischer,
statischer Beleuchtungslösungen wie Radiosity oder Global Illumination. Zudem erleben sie, durch den wachsenden Markt für Mobile Games, eine Renaissance: die Leistungsfähigkeit entsprechender Geräte ähnelt der von PCs
Ende der 90er und so finden die damaligen Technologien wieder Anwendung.
Insgesamt orientiert sich die Ausprägung der Pipeline also in erster Linie an den entsprechenden Umgebungsvoraussetzungen und lässt sich bei
entsprechender Konzeption, wie sie hier das Ziel darstellt, flexibel an die
jeweiligen Möglichkeiten und Erfordernisse anpassen. Die Offline Pipeline
kann dabei eine relativ leicht implementierbare Grundlage darstellen, deren
Verarbeitungsfunktionen, bei Bedarf, problemlos in die jeweiligen Systeme,
wie den Leveleditor oder das Ressourcenmanagement der Engine, umlagern
lassen.
Gerade eine Integration in die Engine kann aber ohnehin nur als alternatives Modul während der Entwicklung implementiert werden, da sowohl ein
Release der entsprechenden Funktionen als auch der editierbaren Quelldaten
zu Problemen führt. Diese sind einerseits lizenzrechtlicher Natur, da bei der
Verarbeitung möglicherweise Technologien von Drittanbietern zum Einsatz
kommen, welche nicht zur Weiterverbreitung freigegeben sind. Gleichzeitig
schreiben Konsolenanbieter mitunter vor, die Veränderung von Assets zu
unterbinden. Andererseits eröffnet Editierbarkeit der Assets weitreichende
Möglichkeiten zur Manipulation, was besonders bei Multiplayer-Spielen zu
verhindern ist.
4.4.1
COLLADA in der Pipeline
Das in dieser Konzeption verwendete COLLADA-Format wurde nicht nur
zum Datenaustausch, sondern insbesondere zur Weiterverarbeitung in Pipelines entwickelt. Dies zeigt sich nicht nur in der bereits dargestellten Austauschbarkeit der eigentlichen Datenressourcen, sondern auch in den Angebotenen Tools zur Verarbeitung des Formates. Allen voran steht das Conditioner-System:
Conditioner sind kleine Funktionsblöcke, die jeweils einzelne, sehr kleine
Verarbeitungsschritte vornehmen und in vielfältiger Weise miteinander verknüpft werden können. Mit COLLADA DOM basiert das System auf der
4. Konzeption
44
Standardlibrary zum Umgang mit COLLADA und lässt sich durch die einfache Funktionsweise sehr leicht in verschiedene Systeme integrieren:
Jeder Conditioner hat ein DOM25 als Eingangsparameter und führt in
dieser Datenstruktur die entsprechenden Änderungen durch. Im Normalfall
wird dieses veränderte DOM wieder ausgegeben und kann so vom nächsten Conditioner weiterverarbeitet werden. Einen Sonderfall stellen OutputConditioner dar, welche am Ende einer solchen Verarbeitungskette (sog. Pipeline) stehen. Diese dienen entweder dazu, das entgegengenommene DOM
als COLLADA-File auszugeben, oder es in andere Formate zu konvertieren.
Dabei spielt es selbstverständlich keine Rolle, ob die Daten ins Storagesystem geschrieben oder direkt weiterverwendet werden, womit sowohl
Offline- als auch Onlineverarbeitung auf das gleiche System zurückgreifen
können. Zur einfachen Konfiguration solcher Conditioner-Pipelines (zur Unterscheidung von der Asset Pipeline als Ganzes) steht mit COLLADA Refinery ein einfaches GUI-System zur Verfügung, welches für einfache OfflinePipelines durchaus ausreicht. Wie in Abbildung 4.1 zu sehen, bietet das auf
JAVA basierende Programm einen Node-Editor an, der einen schnellen und
intuitiven Aufbau von Conditioner-Pipelines beliebiger Komplexität erlaubt.
Der Workflow ähnelt dabei dem verschiedener grafischer Programmierumgebungen oder nodebasierter Compositing-Programme und stellt sowohl
für Programmierer als auch Artists keine größere Herausforderung dar. Zur
besseren Übersicht beziehungsweise Wiederverwendbarkeit lassen sich Teilpipelines zudem als Makros zusammenfassen und abspeichern, wobei das
Format der gleichen XML-Struktur folgt, die auch im, für komplette Conditioner-Pipelines verwendeten, pip-Format zum Einsatz kommt. Darüber
hinaus ist auch eine Integration in Build-Systeme problemlos möglich, da
COLLADA Refinery im Kommandozeilenmodus ausgeführt werden kann.
Zum Aufbau einer, zumindest rudimentären, Asset-Pipline ist kein weiterer Entwicklungsaufwand nötig, abgesehen von den entsprechenden Conditionern. Die Flexibbilität des Systems ermöglicht darüber hinaus eine schrittweise Weiterentwicklung bis zu einer integrierten Lösung mit Echtzeitanbindung an das Spiel, egal ob über den Leveleditor oder direkt im Ressourcenmanagement der Engine.
4.4.2
Automatisierte und ausgelagerte Verarbeitung
Bei einer Online-Pipeline, welche sämtliche Änderungen in Echtzeit in die
Engine überträgt, erfolgt die Konvertierung, zumindest für die Entwicklungsplattform, ohnehin automatisch, sogar eine parallele Anbindung an mehrere
Zielplattformen ist dabei möglich. Ein solches, beispielsweise in der CryEngine 3 umgesetztes System, kann jedoch niemals die einzige Lösung zur Integration von Assets darstellen, allein da Entwicklungsversionen von Consolen
25
Document Object Model
4. Konzeption
45
Abbildung 4.1: Der Node-Editor von COLLADA Refinery. Auch Verzweigungen von Pipelines sind möglich; im Beispiel werden sämtliche Meshes mit
Hilfe eines Makros trianguliert und parallel die statischen Kollisionsobjekte
als CSL-Script ausgegeben.
zu teuer sind, um diese für jeden Entwicklerarbeitsplatz zur Verfügung zu
stellen.
Eine parallel, oder auch ausschließlich betriebene Offline-Pipeline, birgt
jedoch grundsätzlich das Risiko, dass Änderungen an den Quelldaten vergessen werden und eine Übersetzung ins Laufzeitformat nicht, oder erst verspätet, stattfindet. Aus diesem Grunde ist es sinnvoll, die Laufzeitdaten automatisiert mit der aktuellen Version der Intermediate Assets zu synchronisieren,
wobei die hierzu geschaffene Infrastruktur gleichzeitig dazu genutzt werden
kann, diese teilweise aufwändigen Berechnungen von den Workstations der
Entwickler auszulagern.
4.4.2.1
Continuous Integration
Das im Extreme Programming angewandte Konzept der Continuous Integration kann eben diesem Zweck dienen. Entsprechende Systeme, wie beispielsweise die Open-Source-Lösung CruiseControl, reagieren auf Änderun-
4. Konzeption
46
gen in einem Source-Repository und kompilieren das Projekt automatisch
neu. Anschließende, automatische Tests dienen in der Softwareentwicklung
der ständigen Überprüfung der Programmqualität und das Konzept geht normalerweise mit verschiedenen weiteren Techniken und Richtlinien zur Verbesserung der Codequalität einher.
Die dabei zugrunde liegenden Systeme lassen sich jedoch leicht für die
automatische Synchronisierung zwischen Intermediate Assets und Laufzeitdaten adaptieren. Der Vorteil solcher fertigen Lösungen liegt dabei nicht nur
im verringerten Entwicklungsaufwand und der erprobten Stabilität sondern
auch im Angebot verschiedener praktischer Tools.
So bietet CruiseControl, neben einem ohnehin notwendigen Frontend zur
Remoteadministration, beispielsweise eine Hintergrundapplikation für Clients an, welche zur Anzeige von Statusnachrichten dient, also des erfolgreichen Builds oder entsprechender Fehlermeldungen. Gerade solche „Komfortfunktionen“ können sehr praktisch sein. Sie finden sich bei Eigenentwicklungen aber typischerweise ganz am Ende der Prioritätenlisten und werden
somit nur in seltenen Fällen wirklich umgesetzt.
4.4.2.2
Zentrale Buildsysteme
Nicht nur die zentrale Automatisierung der Pipelineprozesse erfordert die
Einrichtung von dedizierten Buildsystemen, sondern auch für lokale Tests
kann die entsprechende Infrastruktur sinnvoll genutzt werden. Vergleichbar
mit einer Renderfarm lassen sich aufwändige Berechnungen vom Arbeitsplatz auslagern, was es ermöglicht, während der entstehenden Wartezeiten
weitere Aufgaben zu erledigen. Mitunter können die Prozesse auch auf mehrere Rechner aufgeteilt werden. Dies ist bei der Vorberechnung von Beleuchtungsdaten praktisch immer der Fall, aber auch Preprocessing-Schritte der
statischen Szenenverwalung oder die Generierung von Navigationsmeshes für
die KI erscheinen hierzu geeignet. Die Iterationszeiten lassen sich durch eine
solche Aufteilung in jedem Fall, teils drastisch, verkürzen.
Das Hauptproblem stellt dabei die Remotesteuerung des Systems und
der manuelle Job-Submit dar. Systeme zur Verwaltung von Renderfarmen
sind üblicherweise speziell auf bestimmte Renderer zugeschnitten und lassen
sich nicht auf beliebige Build-Tools adaptieren. Besonders die Bereitstellung
der Quelldaten gestaltet sich jedoch schwierig. Da es sich, zumindest im Falle
von lokalen Tests, um Änderungen in der jeweils persönlichen Working-Copy
des Projektes handelt, können die Quelldaten nicht dem Repository entnommen werden. Gleichzeitig ist wegen der Vielzahl von verknüpften Dateien ein
Upload kaum praktikabel. Der Buildserver benötigt also entweder Zugriff auf
den Workspace des Clients, oder dieser muss gespiegelt werden.
Da verschiedene Tools, speziell manche Renderer, beim Netzwerkzugriff
auf Ressourcen jedoch Probleme verursachen, ist weder die Auslagerung des
Workspaces auf eine Netzwerkressource, noch der Zugriff des Buildservers auf
4. Konzeption
47
die lokalen Daten des Clients eine ideale Lösung. Darüber hinaus bietet eine
Spiegelung zwei praktische Vorteile: Sie dient einerseits als leichtes Backup,
auch der nicht im Repository verwalteten Daten, und andererseits sind beide
Systeme unabhängig. Der Arbeitsplatz kann während des Buildprozesses also
auch gewartet oder abgeschaltet werden.
Die benötigte Eigenentwicklung des Buildservers selbst, lässt sich auf
Grund der erforderlichen Remotesteuerung wohl am einfachsten als Webanwendung realisieren. Ob andere, in der Bedienung vielleicht komfortablere,
Lösungen deutlich mehr Aufwand erfordern, lässt sich hier, auf Grund der
fehlenden Expertise im entsprechenden Fachbereich, jedoch nicht abschätzen
und wäre eher in der konkreten Projektplanung zu erörtern.
4.4.3
Konfiguration, Verwaltung und Überwachung
Gerade ein möglichst generisches System, wie das hier angestrebte, erfordert
umfangreiche und einfache Möglichkeiten zur Konfiguration. Die Pipelineprozesse selbst stellen dabei, wie bereits erörtert, durch COLLADA Refinery
beziehungsweise eine vergleichbare, integrierte Lösung, kein Problem dar und
auch beim manuellen Build einzelner Assets lassen sich die erforderlichen
Konfigurationen relativ problemlos individuell festlegen.
Für den projektweiten beziehungsweise automatischen Build sind hingegen detaillierte Konfigurationen notwendig. Es muss neben der Definition von
globalen Einstellungen für Development- und Releaseversionen möglich sein,
einzelne Projektteile, Verzeichnisse oder Dateien, ihrem aktuellen Entwicklungsstatus entsprechend, gesondert zu behandeln. Solche Overrides dürfen
lediglich bei finalen Builds außer Kraft gesetzt werden, aber auch dann nur,
wenn sie zu Entwicklungszwecken dienen und nicht aus gestalterischen Gründen eingesetzt werden.
4.4.3.1
Buildsystem
Der Markt bietet zwar eine unüberschaubare Anzahl von Build Systemen,
bekanntere wie Make, SCons, Ant, Jam etc. stellen jedoch keine einfache
Lösung für die im Assetbereich nötige Art der Konfiguration bereit. Zwar
lassen sich entsprechende Ergebnisse über die Definition unterschiedlicher
Targets erreichen, doch ist dies umständlich und kompliziert, weshalb sich
dieses Konzept kaum für Artists ohne Programmier- oder Scriptingkenntnisse
eignet.
Aus diesem Grunde hat beispielsweise Keengames 26 , mit Lace 27 , ein eigenes Buildsystem entwickelt, welches Gruppierung und Tagging einzelner
Assets zur gesonderten Verarbeitung erlaubt. Dieses Projekt befindet sich
jedoch erst im Alphastatus und ist bisher kaum dokumentiert, weshalb an
26
27
Deutscher Spieleentwickler (http://www.keengames.com)
Erhältlich unter http://sourceforge.net/projects/lace-build
4. Konzeption
48
dieser Stelle auf eine weitere Evaluierung verzichtet wurde, lediglich die Erwähnung als möglicher Lösungsansatz erscheint dennoch angebracht.
Um dagegen auf klassische Buildsysteme zurückgreifen zu können, erscheint es als gangbarer Weg, die benötigten Overrides in den Quelldaten
der Assets selbst zu definieren. Auf diese Weise lassen sich die benötigten
Features in die Asset Compiler, bei der Verwendung von COLLADA also
entsprechende Conditioner, verlagern. Diese müssen ohnehin selbst entwickelt werden und somit stellt ein Auslesen der Konfiguration während des
Builds sicher weniger Aufwand dar, als die Entwicklung eines eigenen Buildsystems. Ausgehend von diesem leicht umsetzbaren Konzept gestaltet sich
die Auswahl eines geeigneten Standardsystems wieder sehr viel freier, wobei
ein wichtiges Kriterium sicherlich die Verfügbarkeit grafischer Konfigurationstools darstellt.
4.4.3.2
Steuerung
Wird für die Automatisierung auf ein bestehendes System zur Continuous
Integration zurückgegriffen, gestaltet sich die Steuerung zumindest hier unproblematisch. Diese bieten üblicherweise umfangreiche Möglichkeiten des
Remotezugriffs und Builds können verschiedene Setups verwalten.
Während der Entwicklung kommt am besten eine schnelle Konfiguration mit standardmäßig reduzierten Optimierungs- und Qualitätseinstellungen
zum Einsatz, welche durch Commits im Sourcerepository ausgelöst wird. Auf
diese Weise können Änderungen und vor allem neue Assets schnell im Laufzeitformat bereitgestellt werden.
Eine zweite Stufe sollten scheduled Builds darstellen, die je nach erforderlichem Zeitaufwand, jede Nacht oder wöchentlich durchgeführt werden
können. Wenn dabei Optimierungen in normalem Maße durchgeführt werden
und auch Content-Packages erstellt werden, lässt sich anhand dieser Builds
das finale Laufzeitverhalten abschätzen und mögliche Performanceprobleme
frühzeitig aufdecken. Auch wenn nicht zwingend notwendig, bietet es sich
an, die Qualitätseinstellungen, beispielsweise von Lightmaps, den finalen anzunähern. Dadurch wird, über einzeln, zu Testzwecken kompilierten Levels
hinaus, ein Bild vom finalen Look des Projektes ermöglicht, was zumindest
der Motivation des Teams zuträglich ist.
Ebenso wie die finalen, sollten auch diese regelmäßigen Builds vollständige Rebuilds darstellen. Auf diese Weise lassen sich die, bei ansonsten ausreichenden, inkrementellen Builds, mitunter auftretenden, Inkonsistenzen vermeiden und es wird ein hundertprozentiges Abbild des aktuellen Versionsstandes durch die Laufzeitdaten sichergestellt.
Finale Builds werden, im Gegensatz zu den beiden vorangegangen, stets
manuell ausgelöst und erzeugen im Idealfall ein vollständiges Installationsmedium. Dabei sollten alle zur Entwicklung eingesetzten Overrides von Konfigurationen (und nur diese) durch finale Einstellungen ersetzt werden, also
4. Konzeption
49
vollständige Optimierung, finale Rendering- und Kompressionsqualität und
so weiter.
Andere Erfordernisse ergeben sich beim manuellen Build einzelner Assets
zu Testzwecken. Die Quellen hierfür finden sich nicht zwingend im Repository
wieder, beziehungsweise müssen die entsprechenden Einstellungen vor einem
Commit erst ermittelt werden. Geht man davon aus, dass, von Defaultwerten abweichende, Konfigurationen in den Assets selbst festgehalten werden,
vereinfacht dies jedoch auch die hier benötigten Tools zur Konfiguration.
Grundsätzlich lassen sich so die gleichen Einstellungen wie beim automatischen Buildsystem verwenden, lediglich eine Auswahl der benötigten Assets
ist zusätzlich erforderlich.
In diesem Zusammenhang lässt sich zudem das Konzept der assetgebundenen Overrides weiterführen. Die Flexibilität lässt sich deutlich erhöhen,
indem Overrides an die verwendeten Defaulteinstellungen und die Art des
Builds geknüpft werden, also in Abhängigkeit von Development-, Release-,
automatischem oder manuellem Build, unterschiedliche Einzelkonfigurationen greifen können.
Kapitel 5
Projektarbeit
Die Masterarbeit sieht ein begleitendes, praktisches Projekt vor, welches dazu dient, die Anwendbarkeit der entwickelten Konzepte zu überprüfen. Das
sehr weitreichende Gebiet der Asset-Pipelines für 3D-Spiele ermöglicht dabei
in der vorgesehenen Projektdauer nicht die Implementierung eines vollständigen Systems. Eine Beschränkung auf bestimmte Teilbereiche gestaltet sich
darüber hinaus ebenfalls sehr schwierig. Der konkrete Fall von Cogaen bietet praktisch keinerlei Rahmenbedingungen oder grundlegende Ansätze einer
Pipeline, welche sich ausbauen ließen, sondern erfordert eine komplette Neukonzeption. In Anbetracht dieser Situation kann die Projektarbeit lediglich
einen Proof of Concept mit minimaler Funktionalität darstellen, bei dem ein
Hauptaugenmerk auf der Identifikation eventueller Schwierigkeiten bei der
Umsetzung liegt.
5.1
Konzentration auf funktionale Schwerpunkte
Die Bestandteile der hier vorgestellten Konzeption einer Asset-Pipeline lassen sich im Wesentlichen in zwei Teilbereiche unterteilen: Die zur Funktion
unbedingt notwendigen, und jene, die primär zur Vereinfachung oder Beschleunigung des Workflows dienen. Zu den wirklich benötigten Bereichen
zählen lediglich die Tools für Erstellung und Export der Assets, die Weiterverarbeitung und die Anbindung an die Engine, alle weiteren werden bei der
hier beschriebenen Umsetzung ausgespart, denn nicht allein der reine Entwicklungsaufwand lässt keine vollständige Implementierung in der gegebenen
Zeit zu, auch die Interdisziplinarität stellt, zumindest für ein Einzelprojekt,
ein großes Problem dar.
Unter diesen Voraussetzungen muss also eine Problemstellung gefunden werden, welche die Implementierung einer, zwar funktional sehr eingeschränkten, aber in ihren Grundzügen dennoch funktionierenden Pipeline
ermöglicht.
50
5. Projektarbeit
5.1.1
51
Contenterstellung und Export
Das Konzept sieht grundsätzlich vor, die zentralen Funktionen zur Bearbeitung von Assets und der Levelerstellung in das verwendete DCC-Tool zu
integrieren, anstatt diese in einem dedizierten Leveleditor umzusetzen. An
der FH-Hagenberg kommt hierzu nur Maya in Frage, das aber auch generell
eine gute Wahl für ein solches Vorhaben darstellt. Um die Anforderungen
einer Machbarkeitsstudie für weitreichende Erweiterungen zu erfüllen, reicht
dabei nicht die Entwicklung einfacher MEL- oder Pythonscripts aus, sondern es sollte auf die zur Plug-In-Entwicklung bereitgestellte C++ API zurückgegriffen werden, was unter entsprechenden Voraussetzungen auch eine
Anpassung des erhältlichen COLLADA-Exporters erfordert. Neben der Entwicklung eigener Szenennodes, Shader oder Geometrietypen, für deren Behandlung der verwendete Exporter erweitert werden muss, bietet die Maya
API auch die Möglichkeit zur Implementierung von Tools, welche lediglich
der Bearbeitung von Szenenelementen dienen, jedoch nicht exportiert werden
und somit kein gutes Beispiel darstellen würden.
5.1.2
Weiterverarbeitung
Die Weiterverarbeitung erfolgt mit Hilfe von COLLADA Refinery durch entsprechende Conditioner. Dabei stehen Beispiele für verschiedene Standardanwendungen wie die Triangulierung von Meshes oder auch das Packen aller
benötigten Daten zur Verfügung, welche dementsprechend nicht nachimplementiert werden sollten.
In jedem Fall wird jedoch ein Conditioner zum Export für die Engine benötigt, wobei dieser schnell eine unerwünschte Komplexität erreichen kann,
sofern er Unterstützung für Meshdaten oder Animationen bietet. Da hierbei
ein Großteil des Entwicklungsaufwandes in die fehlerfreie und vollständige
Unterstützung des entsprechenden Formates fließen müsste, erscheint beispielsweise der Export einer reinen Leveldefinition, welche lediglich die Positionen der platzierten Objekte umfasst weitaus zielführender: Hierbei müssen
lediglich die Transformationsdaten bestimmter Objekte innerhalb des DOM
ermittelt und exportiert werden, was für eine grundlegende Einschätzung der
verwendeten APIs ausreichen sollte.
5.1.3
Engineanbindung
Der Entwicklungsstand von Cogaen während des Projektzeitraumes lässt größere Investitionen in die Engineanbindung wenig sinnvoll erscheinen: Beim
Ressourcenmanagement stehen weitreichende Neustrukturierungen an, wichtige Systeme, wie Ogre3d oder PhysX, waren ohnehin eher als Übergangslösungen konzipiert und sollen in absehbarer Zeit, durch die in Entwicklung
befindlichen Module CBero beziehungsweise PhysiKCHs, ersetzt werden. Ein
5. Projektarbeit
52
datenbasiertes System zur Definition komplexerer Assets, wie beispielsweise Levels, existiert nicht und müsste komplett neu entwickelt werden, um
die anfangs (in Abschnitt 2.2.3.2) beschriebene, scriptbasierte Notlösung zu
ersetzen. Dieses Unterfangen hätte jedoch für sich alleine genommen den
Umfang eines Semesterprojektes und setzt zudem vertiefte Kenntnisse in
der Planung von Softwarearchitekturen voraus. Aus diese Gründen erscheint
es hier als pragmatischste und sicherste Lösung, auf das beschriebene System
aus den Sommersemester 2008 zurückzugreifen und sich auf die Generierung
von CSL-Scrips zu beschränken.
5.2
Beschreibung des Projektes
Auf Basis der zuvor beschriebenen Anforderungen, erscheint die Implementierung einer Pipeline zur Erstellung und Verarbeitung von analytischen Kollisionskörpern am sinnvollsten. Im Gegensatz zu Meshes werden solche parametrisch beschriebenen Körper, wie Quader, Kugeln, Zylinder von Maya
und anderen DCC-Tools typischerweise nicht unterstützt. Sie kommen jedoch
häufig bei Echtzeit Physiksimulationen und damit in Spielen zum Einsatz,
da sie gegenüber Kollisionsmeshes deutliche Preformancevorteile bieten.
Das anfangs beschriebene Vorgehen, solche Quader durch die entsprechende Skalierung von Polygonwürfeln zu platzieren, erweist sich in der Anwendung als sehr umständlich und ungenau, weshalb sich eine Unterstützung
entsprechender Körper und geeignete Tools zur Platzierung in jedem Fall
als praktisch erweisen sollten. Die dazu implementierten Szenenelemente erfordern gleichzeitig eine Anpassung des verwendeten COLLADA-Exporters,
wohingegen eine Erweiterung des Formates selbst nicht notwendig ist, da die
entsprechenden Elemente durch das Physik-Profil von COLLADA abgedeckt
sind. In der anschließenden Weiterverarbeitung durch Conditiner müssen,
wie gefordert, keine Geometrie- oder Animationsdaten konvertiert werden.
Es genügt stattdessen das Auslesen von Position, Ausrichtung und Dimensionen der Kollisionskörper, welche schließlich als CSL-Script exportiert und
von der Engine eingelesen werden können.
5.2.1
Maya Plug-In für Kollisionskörper
Die Integration der analytischen Kollisionskörper erfolgt mittels der Maya
API in C++. Zwar stellt das, relativ neue, Python-Binding praktisch den
gleichen Funktionsumfang bereit, jedoch bietet C++ wegen des Geschwindigkeitsvorteils, zumindest im Hinblick auf komplexere Integrationen, das
realistischere Anwendungsbeispiel.
5. Projektarbeit
5.2.1.1
53
Maya im Überblick
Die Beschreibung des implementierten Plug-Ins erfordert zunächst einige
Grundlagen über die Architektur von Maya: Der Dependency Graph (DG)
stellt die zentrale Datenstruktur von Maya dar. Alle Daten werden dabei als
Attribute der verschiedenen Nodes dieses Graphen verwaltet, und lassen sich,
ihres Typs entsprechend, in praktisch beliebiger Weise verknüpfen, wobei
die Nodes entweder als reine Container für Daten (beispielsweise verschiedene Einstellungen) dienen, oder entsprechende Eingangsattribute verarbeiten
und die Ergebnisse als Ausgangsattribute zur Verfügung stellen. Dieses Prinzip gilt dabei nicht nur für Basisdatentypen, sondern auch Meshdaten und
ähnliches werden als Attribute verwaltet und lassen sich entsprechend verknüpfen.
Neben dem DG verwaltet Maya zudem den hierarchischen DAG (Directed Acyclic Graph), welcher die Elemente der 3D-Szene enthält. Die hier
enthaltenen DAG-Nodes sind zwar ebenfalls Teil des DG und lassen sich mit
dessen Elementen verknüpfen, befinden sich aber zudem in der hierarchischen
Baumstruktur der Szene und unterliegen so der Vererbung von Transformationen. Dabei besitzen die tatsächlich sichtbaren Shape-Nodes (Meshes,
NURBS, Lichter etc.) keine eigenen Transformationsattribute, sondern haben stets mindestens ein Transform-Node als Parent (im Falle von mehreren
Parents entspricht dies einer mehrfachen Instanziierung in der Szene).
5.2.1.2
Implementierung des Plug-Ins
Das Plug-In basiert im Wesentlichen auf dem DAG-Node gapPhysicsShape,
welcher, wie der Name andeutet, ein Shape-Node darstellt. Dieser Node stellt
über ein Enum-Attribut (welches wie in C++ eine Zuordnung zwischen Namen und Ganzzahlen erlaubt) eine Auswahl von verschiedenen analytischen
Grundkörpern und auch Kollisionsmeshes dar, wobei derzeit nur Boxen hinreichend implementiert sind. Daneben enthält der Node sämtliche, zur Beschreibung der Körper, notwendigen Attribute, wie die lokalen Koordinaten
des Mittelpunktes, Rotation, Größe, Radius (bei Kugeln), etc.
Da allein hiermit jedoch kaum ein Vorteil gegenüber der erwähnten Platzierung durch entsprechende Polygonobjekte gegeben wäre, wurde zudem ein
entsprechender Manipulator zur Platzierung und Ausrichtung implementiert.
Manipulators sind in Maya Helferobjekte, die temporär in der 3D-Szene angezeigt werden, um Attribute mit Hilfe von graphischen Anfassern zu verändern. Einfache Beispiele sind die in Abbildung 5.1 sichtbaren Move-, Rotateund Scalewerkzeuge, jedoch lassen sich auch nodespezifische Manipulators
umsetzen.
Solche speziellen Manipulators lassen sich in beide Richtungen mit beliebigen Attributen des entsprechenden Nodes verknüpfen. Auf diese Weise
lassen sich nicht nur Eigenschaften des aktiven Objektes verändern, sondern
5. Projektarbeit
54
Abbildung 5.1: Move-, Rotate- und Scalewerkzeuge in Maya. Diese sind
konzeptionell als Manipulators für Transform-Nodes (im Object-Mode) beziehungsweise Tweak-Nodes (im Component-Mode) zu betrachten.
es ist auch möglich, die Manipulators an die Position oder andere Zustände
des verbundenen Nodes anzupassen.
Die Umsetzung des Box-Manipulators orientiert sich dabei am Box-Tool
von ImageModeler 1 , bei welchem Quader über ihre Eckpunkte positioniert
werden: Die einzelnen Eckpunkte der Box werden nacheinander positioniert
und fixiert, wobei die noch freien Punkte stets so ausgerichtet werden, dass
die Quaderform erhalten bleibt. Durch die Sperrung der bereits positionierten Punkte, schränken sich dabei die Freiheitsgrade des gerade bearbeiteten Punktes zunehmend ein, bis Größe, Position und Ausrichtung der Box
schließlich eindeutig definiert sind und sich somit auch nicht-fixierte Punkte
nicht mehr bewegen lassen.
In Verbindung mit den entsprechenden Snapping-Funktionen (snap to
Vertex) erlaubt dies eine intuitive und schnelle Ausrichtung der Kollisionsobjekte an die sichtbare Levelgeometrie.
5.2.2
Anpassung des COLLADA-Exporters
Da der verwendete OpenCOLLADA2 -Exporter als Open-Source Projekt vorliegt, gestaltet sich die Anpassung relativ einfach. Beim parsen der MayaSzene müssen lediglich die richtigen Nodes herausgefiltert und entsprechend
weiterverarbeitet werden, wobei sich die verwendeten Klassen und Datenstrukturen an den bereits vorhandenen orientieren können.
Als gute Referenz haben sich hierbei Light-Nodes erwiesen, welche ebenfalls geometrielose Shapes darstellen, und auch im COLLADA-Format sehr
ähnlich wie Physic-Shapes abgebildet werden. Die einzige, vor allem zeitliche Herausforderung, stellte dabei, die, generell noch fehlende, COLLADA
Physics Unterstützung von OpenCOLLADA dar, welche, zumindest in rudimentärem Umfang, implementiert werden musste. Somit war es an dieser
Stelle zwar nicht notwendig, eigene Daten ins Format zu integrieren, doch
1
Bild-Basiertes Modeling-Tool von Autodesk
(http://www.autodesk.com/imagemodeler)
2
Mehr Informationen unter http://www.opencollada.org
5. Projektarbeit
55
zumindest die generelle Implementierung von Features erwies sich als sehr
einfach.
5.2.3
Refinery und Conditioner
Der entwickelte Conditioner exportiert die im COLLADA-File enthaltenen
Kollisionsobjekte in ein CSL-Script, welches der Implementierung im anfänglichen CaptAncestor -Beispiel (Abschnitt 2.2.3) entspricht. Zu diesen Zweck
wird das DOM aus dem Eingangsparameter des Conditioners nach
<physics_scene>-Elementen durchsucht, welche zunächst nach ihrem Name-Attribut gefiltert werden; weiterbehandelt werden nur solche mit dem
Namen „GapPhysicsScene“. Da das Name-Attribut nicht eindeutig sein muss,
lassen sich auf diese Weise beliebig viele, unterstützte Physikszenen in einer
Datei unterbringen, während Szenen anderer Systeme, beispielsweise native
Maya Physikszenen, ignoriert werden können.
Anschließend werden die enthaltenen Elemente <physics_model>,
<rigid_body> und <technique_common> rekursiv geparst, um schließlich die
enthaltenen <box>-Elemente samt ihrer Transformationsdaten und Größe zu
exportieren. Der Pfad der Zieldatei lässt sich dabei im COLLADA Refinery
Interface bestimmen (zu sehen in Abb. 4.1), beim Fehlen der entsprechenden Angabe wird der Pfad der Quelldatei verwendet, wobei die Dateiendung
durch „csl“ ersetzt wird.
5.3
Post-Mortem-Analyse des Projektes
In der abschließenden Betrachtung lässt sich feststellen, dass sich zumindest
die COLLADA-basierten Teile des Projektes, also Exporter und Conditioner
sehr problemlos umsetzen ließen. Die hierbei verwendeten Projekte und APIs
sind, wenn auch teilweise kaum dokumentiert, sehr übersichtlich strukturiert
und auch für wenig erfahrene Entwickler leicht zugänglich. Ähnliches gilt für
das COLLADA-Format selbst. Das Standardwerk COLLADA: Sailing the
Gulf of 3d Digital Content Creation [1] schafft es, die grundlegenden Konzepte des Formates leicht verständlich zu vermitteln, während die COLLADA
Spezifikation 3 eine eindeutige und übersichtliche Referenz für den Umgang
mit dem Format darstellt.
Ein anderes Bild zeigt sich leider bei der Entwicklung für Maya. Die
Einarbeitung in die API ist äußerst mühsam und die Arbeit damit zumindest
umständlich. Zur Erklärung dieser Aussage ist an dieser Stelle, nach dem
kurzen Überblick über DG, DAG, Nodes und Attribute (Abschnitt 5.2.1.1),
eine Zusammenfassung der programmatischen Umsetzung dieses Konzeptes
nötig.
3
Erhältlich unter http://www.khronos.org/files/collada_spec_1_4.pdf beziehungsweise
http://www.khronos.org/files/collada_spec_1_5.pdf
5. Projektarbeit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
56
//////////////////////////////////////////////////////////////////////
//
// Error checking
//
// MCHECKERROR - check the status and print the given error message
// MCHECKERRORNORET - same as above but does not return
//
//////////////////////////////////////////////////////////////////////
#define MCHECKERROR(STAT,MSG)
if ( MS::kSuccess != STAT ) {
cerr << MSG << endl;
return MS::kFailure;
}
\
\
\
\
#define MCHECKERRORNORET(STAT,MSG)
if ( MS::kSuccess != STAT ) {
cerr << MSG << endl;
}
\
\
\
Programm 5.1: Im Maya Development Kit bereitgestellte Makros zur Verkürzung der Fehlerüberprüfung
Alle dabei verwalteten Objekte, also Nodes und Attribute, leiten sich von
der gemeinsamen Basisklasse MObject ab, wobei der Zugriff auf jeweiligen
Klassenfunktionen nicht direkt, sondern über entsprechende Functor -Klassen
(welche kaum mehr als den Namen mit dem bekannten Design-Pattern teilen) erfolgt, deren Vererbungshierarchie die der tatsächlichen Objekte spiegelt. Diesen Functors (erkennbar am Prefix MFn) wird jeweils ein passendes
MObjekt zugewiesen, um auf diesem die gewünschten Funktionen auszuführen.
Der eindeutige Vorteil dieses Konzeptes besteht darin, dass die konkrete Implementierung der Objekte, sowie die tatsächlichen Daten, vom User
gekapselt werden. Als Nebeneffekt wird allerdings jegliche Typprüfung während der Kompilierung unmöglich. Für den Compiler existieren schließlich
nur MObjects, und diese unterscheiden sich erst zur Laufzeit.
Aus diesem Grunde bietet Maya eine Laufzeitprüfung mittels einer Statusklasse MStatus an, welche von fast jeder Funktion zurückgegeben wird.
Bei konsequenter Anwendung bedeutet dies jedoch, dass, nach praktisch jedem Aufruf einer API-Funktion, eines der beiden Makros aus Prog. 5.1
ausgeführt werden sollte. Dies erhöht jedoch nicht nur den Schreibaufwand,
sondern schränkt die Übersichtlichkeit des Codes und seine Lesbarkeit deutlich ein.
Nicht nur Vermeidung und Suche von Fehlern gestaltet sich durch Mayas
Functor -Konzept schwierig. Der Rückgabetyp MObjekt lässt generell nicht
darauf schließen, welche Functors angewandt werden können und auch die
5. Projektarbeit
57
Bezeichnung der jeweiligen Funktion erlaubt nicht immer eindeutige Schlüsse. Deshalb ist die Dokumetation als ständige Referenz unverzichtbar und
wichtiger als bei manchen anderen APIs.
Im Hinblick auf die Klassenübersicht leistet die Dokumentation dabei
gute Dienste und auch verständliche Beispiele für den Einstieg stehen zur
Verfügung. Wie allerdings auch die Beispiele in David Goulds Standardwerken zur Programmierung von Maya [5] [6], behandeln diese jeweils sehr
einfache und vor allem isolierte Funktionalitäten. Die Integration mit den
bestehenden Standardtools ist dagegen kaum dokumentiert. Ein Beispiel dafür stellt der oft verwendete Befehl Freeze Transformations 4 dar. Die einzige
Dokumentation darüber, welche Funktion zur Unterstützung dieses Befehles
implementiert werden muss, findet sich im Kommentar zur entsprechenden
Funktion eines Beispiel-Plug-Ins: „This method is used by the freezeTransforms command“ [2], Z. 690.
Dieses Beispiel war bei der Projektarbeit zwar das einzige, bei der das
Problem, in dieser Form, aufgetreten ist, jedoch fehlt eine solche Dokumentation generell. Somit ist bei anderen Problemstellungen mit ähnlichen Herausforderungen zu rechnen.
4
Freeze Transformations überträgt alle Transformationen einer Node-Hierarchie in den
lokalen Raum der einzelnen Shapes. Die Matritzen der Transform-Nodes werden dabei auf
Einheitsmatritzen zurückgesetzt.
Kapitel 6
Schlussbetrachtung
Das Ziel dieser Konzeption war es, eine Grundlage für die künftige Entwicklung einer Asset-Pipeline zu Cogaen zu schaffen. Dabei war wichtig, dass
eine erste Implementierung mit möglichst geringem Aufwand erfolgen kann,
um die Arbeit an Spieleprojekten schnell zu erleichtern. Dies lässt sich durch
die Verwendung und Anpassung verschiedener, bestehender Systeme relativ
leicht erreichen, was auch die Projektarbeit gezeigt hat.
Darüber hinaus ermöglicht es die modulare Konzeption, eine solche Basisimplementierung schrittweise zu erweitern, und einzelne Komponenten besser in den Workflow und die Engine zu integrieren. Dies ist wichtig, da die
Entwicklung praktisch nur in Form von Semesterprojekten erfolgen kann und
diese in Umfang und Dauer beschränkt sind.
Das Projekt hat dabei gezeigt, dass die, für weite Teile der Implementierung verwendeten, Technologien leicht zugänglich sind und sich die Herausforderungen bei der Umsetzung durch die entsprechende Problemstellung
ergeben. In diesen Bereichen lässt sich ein weites Spektrum an relativ gut
abschätzbaren Projekten definieren.
Problematisch stellt sich in erster Linie die Maya-Integration dar. Bei
der Projektarbeit erforderten die Konzepte der API eine sehr lange Einarbeitungszeit, während die eigentliche Implementierung letztlich ohne weitere
Probleme möglich war. Die Probleme beim Verständnis der API lassen sich
dabei zwar sicherlich auf persönliche Defizite im Bereich der Softwarearchitektur zurückführen, doch diese wird im Bacherlor-Studiengang Medientechnik und -Design der FH-Hagenberg praktisch nicht behandelt1 .
Aber auch mit vorangegangener Informatik-Ausbildung gestaltet sich die
Maya-Entwicklung wohl kaum einfacher. Die Einarbeitungszeit entfällt in
diesem Fall vermutlich weniger auf die API, doch die Entwicklung von Tools
erfordert ebenso eine genaue Kenntnis der Bedienungskonzepte und Use Cases.
1
Dies gilt für den Studienplan 2004. Entsprechende Änderungen sind an dieser Stelle
jedoch nicht bekannt.
58
6. Schlussbetrachtung
59
In beiden Fällen lässt die nötige Einarbeitungszeit die Umsetzung komplexerer Features, innerhalb eines Semesterprojektes, wenig praktikabel erscheinen. Dies stellt sicherlich einen Schwachpunkt der Konzeption dar; die
Tatsache, dass entsprechendes Know-How sehr gefragt ist, sollte aber möglicherweise zur Lösung dieses Problems, an anderer Stelle, auffordern.
Abschließend lässt sich nurmehr folgendes [4] festhalten:
Now these points of data make a beautiful line
And we’re out of beta we’re releasing on time.
[. . . ]
I’ve experiments to run there is [still] research to be done
On the people who are still alive
Anhang A
Inhalt der DVD
Format: DVD-R, Single Layer, ISO9660-Format
A.1
Masterarbeit
A.1.1
PDF-Dateien
Pfad: /
dm07026_wall_jan-felix_da.pdf Masterarbeit
Pfad: /Internetquellen
GDC2008_PostProcessingInTheOrangeBox.pdf Quelle [9]
gdmag_content_pipeline.pdf Quelle [7]
J_Koenen_Programming_Code_Asset_Management.pdf Quelle [8]
A.1.2
Grafiken
Pfad: /Grafiken
*.pdf . . . . . . . . . .
*.png . . . . . . . . . .
A.2
Projekt
A.2.1
Binaries
A.2.1.1
Vektorgrafiken
Rastergrafiken
Windows
Pfad: /Projektdaten/GapMaya/VS/Output
readme.txt . . . . . . .
Anweisungen zur Windowsversion des
Maya-Plug-Ins
60
A. Inhalt der DVD
61
Pfad: /Projektdaten/GapMaya/VS/Output/ReleaseMaya*
gapMain.mll . . . . . . .
Windowsversion des Maya-Plug-Ins
Pfad: /Projektdaten/opencollada/COLLADAMaya/bin/win
readme.txt . . . . . . .
Anweisungen zur Windowsversion des
Export-Plug-Ins für Maya
Pfad: /Projektdaten/opencollada/COLLADAMaya/bin/win/*/*
COLLADAMaya.mll . .
Windowsversion des Export-Plug-Ins für
Maya
Pfad: /Projektdaten/COLLADA_Refinery/bin/vc9/Release
refinery.bat . . . . . . .
A.2.1.2
Script zum starten der Windowsversion von
COLLADA Refinery
Mac OS X
Pfad: /Projektdaten/GapMaya/xcode/build
readme.txt . . . . . . .
Anweisungen zur Macversion des
Maya-Plug-Ins
Pfad: /Projektdaten/GapMaya/xcode/build/Release2009
gapMain.bundle . . . . .
Macversion des Maya-Plug-Ins
Pfad: /Projektdaten/opencollada/COLLADAMaya/bin/osx
readme.txt . . . . . . .
Anweisungen zur Macsversion des
Pfad: /Projektdaten/opencollada/COLLADAMaya/bin/osx/Release 2009
COLLADAMaya.bundle
Macversion des Export-Plug-Ins für Maya
Pfad: /Projektdaten/COLLADA_Refinery/bin/osx/Release
Collada Refinery.dmg . .
enthält das App-Bundle der Macversion von
COLLADA Refinery
A. Inhalt der DVD
A.2.2
62
Testdaten
Pfad: /Projektdaten/GapTest/scenes
testscene.mb . . . . . .
Maya-File der Testszene (vor dem öffnen
gapMain.mll laden)
Pfad: /Projektdaten/GapTest/data
testscene.dae . . . . . .
testscene.csl . . . . . . .
A.2.3
A.2.3.1
COLLADA-File der Testszene (Exporter
Output)
CLS-File der Testszene (COLLADA Refinery
Output)
Quellen
Visual Studio 2008 Sulutions
Pfad: /Projektdaten/GapMaya/VS
Gap.sln . . . . . . . . .
Solution zur Windowsversion des
Maya-Plug-Ins
Pfad: /Projektdaten/opencollada/COLLADAMaya
COLLADAMaya.sln . .
Solution zur Windowsversion des
Pfad: /Projektdaten/COLLADA_Refinery/projects/vc9
COLLADAMaya.sln . .
A.2.3.2
Solution zur Windowsversion von COLLADA
Refinery
Xcode Projekte
Pfad: /Projektdaten/GapMaya/xcode
Gap.xcodeproj . . . . .
Xcode-Projekt zur Macversion des
Maya-Plug-Ins
Pfad: /Projektdaten/opencollada/COLLADAMaya
COLLADAMaya.xcodeproj Xcode-Projekt zur Macversion des
Pfad: /Projektdaten/COLLADA_Refinery/projects/Xcode
COLLADA_REFINERY.xcodeproj Xcode-Projekt zur Macversion von
COLLADA Refinery
Literaturverzeichnis
[1] Arnaud, R. und M. C. Barnes: Collada: Sailing the Gulf of 3d Digital
Content Creation. A K Peters, Ltd., Wellesley, Massachusetts, 2006.
[2] Autodesk: apimeshshape.cpp. Part of the Maya Development Kit, 2008.
[3] Carter, B.: The Game Asset Pipeline. Charles River Media, 2004.
[4] Coulton, J.: Still alive, the orange box (original soundtrack). Written
by Jonathan Coulton, vocals by Ellen McLain, 2007. CD, published by
Valve Corporation.
[5] Gould, D.: Complete Maya Programming: An Extensive Guide to MEL
and C++ API. The Morgan Kaufmann Series in Computer Graphics,
2003.
[6] Gould, D.: Complete Maya Programming Volume II: An In-depth Guide
to 3D Fundamentals, Geometry, and Modeling. The Morgan Kaufmann
Series in Computer Graphics, 2005.
[7] Ilopis, N.: Optimizing the content pipeline. Game Developer, S. 36–44,
Apr. 2004. http://www.convexhull.com/articles/gdmag_content_pipeline.
pdf.
[8] Koenen, J.: Practical techniques for managing code and assets for multiple
cross platform titles. Lecture on Game Developer’s Conference Europe,
August 2009, Cologne, 2009. http://mygdc.gdconf.com/vault/play/10099.
[9] Vlachos, A.: Post processing in the orange box.
Lecture on
Game Developer’s Conference, Februrary 18, 2008, San Francisco, 2008. http://www.valvesoftware.com/publications/2008/GDC2008_
PostProcessingInTheOrangeBox.pdf.
63
Messbox zur Druckkontrolle
— Druckgröße kontrollieren! —
Breite = 100 mm
Höhe = 50 mm
— Diese Seite nach dem Druck entfernen! —
64

Konzept und Design einer generischen Asset-Pipeline für 3D

Transcrição

Documentos relacionados

Vocabulary Accounts receivable

3D Junior Artist - Promotion Software GmbH

Maple Match Dating - nextMedia.Hamburg

online versteigerung - Troostwijk Auctions

3D Game Engine for Multiplayer Online Games

Agenda - CAI Systeme GmbH

m/w - N3 Engine Overhaul Services

Autodesk Maya 2015 - mitp

Apogenix präsentiert auf der JP Morgan Healthcare Conference

Immer wieder aufstehen