Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...

Die Seite wird erstellt Melanie Wegner
 
WEITER LESEN
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Deckblatt

Umsetzung der Fakultät M+I als interaktive
                                             Jonas Schönauer
Echtzeit-3D-Virtual-Reality-Umgebung
                                             Fabian D'Abundo
mit skalierbarem Multiplattform-Ansatz
                                             Dimitrij Schmunk
                                                 Alisia Schäfer
Projektarbeit WS 201 2/1 3
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Inhalt
1 . Einleitung                 02
        1 .1 Das Projekt       03
        1 .2 Unity             06

2. Workflow für Inhalte        10
     2.1 Models                11
     2.2 Texturen              22
     2.3 UV-Maps               27
     2.4 Sound                 30

3. Umsetzung mit Unity         33
     3.1 Struktur              34
     3.2 Objekte & Prefabs     38
     3.3 Materials             47
     3.5 Sound                 52
     3.6 Licht                 57
     3.7 Effekte               61
     3.8 Interaktion           63
     3.9 Systemtechnisches     68

4. Anhang                       71
      4.1 Technische Abwägungen 72
      4.2 Skriptreferenz        81
      4.3 Bug-Reports           90
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
1.
Einleitung
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Das Projekt
Die Grundidee
Ziel unseres Projektes ist die Erstellung eines interaktiven, virtuellen Modells des M+I-
Fakultätsgebäudes der Hochschule Offenburg. Dabei liegt der Fokus vor allem auf der
Verwendung moderner Techniken, um die digitale Umgebung so nah wie möglich an
ihr reales Vorbild anzugleichen. Die Betrachtung des virtuellen Modells erfolgt in
diesem Sinne auch durch einen Avatar, der aus der Ego-Perspektive gesteuert werden
kann.
Um den Kriterien der Realitätsnähe gerecht zu werden, besteht das virtuelle Modell aus
realen Fotografien des Originals sowie einer Vertonung mit echten Tonaufnahmen des
Vorbildes. Des Weiteren kann an bestimmten Stellen mit der Virtual Reality interagiert
werden, wobei die Interaktionen wiederum so nah an den realen Tätigkeiten liegen,
wie im Rahmen der vorhandenen Technik und des Zeitbudgets möglich.
Die Einsatzzwecke eines fertigen Modells sind vielfältig: Bereits mit der vorliegenden
Version ist es möglich, einen strukturellen Eindruck über das Gebäude und die
Studieneinrichtungen zu bekommen. Dies kann zum Beispiel Studieninteressierten zu
einem Ersteindruck verhelfen, oder neuen Studierenden eine Möglichkeit bieten, sich
die neue Umgebung auf spielerische Art einzuprägen. Im Falle der Fortführung des
Projekts ist aber auch eine Ausweitung der Möglichkeiten hin zu mehr Produktivität
oder mehr Informationsvermittlung denkbar. Stichworte wären hier zum Beispiel E-
Learning, Fernunterricht oder auch Kommunikation unter Studierenden durch die
virtuelle Welt (Multiplayer).
Das Projekt ist modular angelegt, sodass es später durch weitere Inhaltselemente
ergänzt werden kann. Von neuen Gegenständen in der virtuellen Welt, Informationen
und Daten, welche über Schnittstellen abgerufen werden können, neue Interaktionen
und Arten von Interaktionen oder weiteren Gebäuden ist alles denkbar. Auch in
technischer Hinsicht kann das Projekt weiterentwickelt werden, beispielsweise durch
neue Berechnungstechniken wie Shader, neue Schnittstellen wie bspw. eine
Anbindung an das Internet oder neue Ausgabeplattformen wie mobile Geräte.

                                                                                3
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Was ist eine Game-Engine?
Die Entwicklung eines komplexen interaktiven Projektes ist ein umfangreiches
Unterfangen. Unser Projekt hat in dieser Hinsicht äußerst ähnliche Anforderungen wie
ein markttypisches Videospiel mittleren Budgets. Neben der Ausarbeitung eines
Konzepts, also der vorkommenden Elemente, Regeln, Möglichkeiten etc., müssen eine
Vielzahl an Inhalten verschiedener Medienkanäle produziert werden. Dies umfasst 3D-
Modelle, Texturen / 2D-Grafiken, Animationen, Videos, Sounds, Musik, Text und mehr.
Anschließend muss eine Anwendung programmiert werden, die diese verschiedenen
Inhalte gemäß des Konzeptes zur Darstellung bringt, wobei gerade bei Live-3D-
Anwendungen das Thema Effizienz eine tragende Rolle spielt. Doch die Spieleindustrie
hat für diese bei jedem Spieleprojekt erneut auftretenden Anforderungen eine Lösung
entwickelt:
Ein Spielkonzept ist (im Idealfall) von Spiel zu Spiel unterschiedlich und kann damit
schlecht verallgemeinert oder abstrahiert werden. Mediale Inhalte dagegen sind in
jedem Computerspiel vorhanden und müssen nahezu immer auf dieselbe Weise
präsentiert werden: Bilder werden sichtbar gemacht, Sounds werden hörbar gemacht,
Videos werden abgespielt, 3D-Modelle werden gerendert. Des Weiteren verfügt jedes
interaktive Spiel über Steuerungs- / Eingabemöglichkeiten, typischerweise Tastatur
und Maus oder Gamepad, je nach Plattform auch Touchscreen, Bewegungserkennung,
Beschleunigungssensoren etc.
Diese fundamentalen Aufgaben zur Steuerungseingabe und Medienausgabe müssen
bei jedem interaktiven Spiel implementiert werden und bereiten dabei leider einen
nicht unerheblichen Aufwand. Man nennt diesen Teil des Programms wegen seines
technischen Charakters die „Game-Engine“ (wörtlich übersetzt den „Spiel-Motor“).
Da sich dieser zwingend nötige Teil der Spieleprogrammierung bei vielen Projekten
ähnelt und trotzdem hohe Anforderungen an einen effizienten Programmierstil stellt,
kann sich das Produktionsteam eine Menge Arbeit ersparen, indem sie eine
vorgefertigte Game-Engine verwenden, anstatt selbst eine zu implementieren und
damit das Rad neu zu erfinden. Verfügbare Game-Engines gibt es in allen
Größenordnungen und Preisklassen. Von auf Programmierer zugeschnittenen, frei
verfügbaren Code-Bibliotheken für bestimmte Aufgaben und nur eine feste Plattform,
bis hin zu genreübergreifenden, grafischen Spiele-Entwicklungsumgebungen mit
Export-Funktion für mehrere Plattformen.

                                                                            4
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Warum Unity?
Unity ist sowohl eine umfangreiche 3D-Game-Engine, als auch eine integrierte Spiele-
Entwicklungsumgebung (im folgenden „Editor“ genannt). Eine Beschränkung auf ein
bestimmtes Genre besteht nicht. Mit Unity entwickelte Spiele können als Standalone-
Anwendung für Mac und PC, als universelle Plugin-basierte Browseranwendung, für
iOS- und Android-Geräte, sowie für alle gängigen Spiele-Konsolen exportiert werden.
Unity geht dabei einen guten Kompromiss zwischen Performance, Flexibilität und
Zugänglichkeit ein. Programmierer können direkt auf eine umfangreiche,
dokumentierte API (Code-Bibliothek) zugreifen. Nicht-Programmierern bietet der
grafische Editor dagegen einfache Werkzeuge, um mittels vorgefertigter Skripte und
Drag-And-Drop-Mechanik auch komplexere Szenen zu bauen und mit Leben zu füllen.
Unity wird laufend weiterentwickelt und kann durch Plugins selbsttätig erweitert
werden.

                                                                            5
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Unity
Der Editor
Die zentrale Verknüpfung aller Elemente unserer Projektarbeit findet in der Spiele-
Engine Unity statt. Schaltzentrale und alltägliches Werkzeug ist dabei der Editor, also
die integrierte Entwicklungsumgebung. Für ein besseres Verständnis wird im
Folgenden der Aufbau und die Handhabung des Editors grob beschrieben.

Der Unity-Editor

Die jeweils bearbeitete Spielszene wird im "Scene"-Fenster in der Mitte angezeigt, in
dem man sich ähnlich wie in einem 3D-Modellierungs-Programm frei bewegen kann.
Hier können auch direkt die einzelnen Spielobjekte positioniert und ausgerichtet
werden. In der "Hierarchy" werden alle Objekte in der Szene noch einmal in einer
Baumstruktur aufgeführt. Die Eigenschaften eines Objekts werden im sogenannten
"Inspector" angezeigt und bearbeitet. Im nach einem Druck auf den "Play"-Button

                                                                              6
erscheinenden "Game"-Fenster kann die Szene direkt angespielt werden.
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Die Projektstruktur
Anstatt von Projektdateien gibt es in Unity Projektordner. Diese enthalten neben Unity-
internen Daten alle im Projekt vorhandenen Szenen/Level (eine Datei pro Szene), sowie
sämtliche für das Projekt benötigten Ressourcen und Medieninhalte (Grafiken, 3D-
Modelle, Sounds, Texte, etc.). Dabei lässt sich über Unterordner eine eigene
Organisationsstruktur anlegen. Dies gibt dem Anwender zwar einerseits größere
Flexibilität, auf der anderen Seite kann der Projektordner bei mangelnder Organisation
schnell chaotische Zustände annehmen.
Ein positiver Faktor für einen reibungslosen Workflow ist die Tatsache, dass Unity
einerseits eine große Palette an Dateiformaten für den Import unterstützt und
andererseits, dass diese Dateien direkt von außen geändert werden können, ohne
einen Umweg über Unity zu gehen. Dies bedeutet Grafiker könnten beispielsweise
auch nachträglich an Photoshop-Dateien Änderungen vornehmen und diese
Änderungen könnten alleine durch Ersetzung der psd-Dateien im Unity-Projektordner
direkt in das Spiel übernommen werden, ohne dass ein Programmierer dafür tätig
werden muss.

GameObjects, Komponenten und Prefabs
Beim Aufbau der einzelnen Objekte verfolgt Unity ein modulares System. Alle Objekte
in einer Szene sind "GameObjects", die sich nur durch eine unterschiedliche
Kombination von "Komponenten" sowie ihren Namen unterscheiden. Komponenten
geben den Objekten ihre eigentliche Funktion. Jede Komponente steht für ein oder
mehrere Eigenschaften oder Fähigkeiten, wobei eine Komponente selbst meist auch
noch genauer konfiguriert werden kann. Komponenten lassen sich dabei nahezu
beliebig kombinieren. So erhält man bspw. durch Hinzufügen einer "AudioSource"-
Komponente und einer "Light"-Komponente zu einem GameObject ein unsichtbares
Objekt, welches leuchtet und Geräusche von sich gibt.
Zusammengehörige GameObjects (z.B. Teile eines Stuhls) lassen sich mit einem
gemeinsamen Eltern-GameObject verknüpfen und bleiben dadurch räumlich
miteinander verbunden.
GameObjects werden normalerweise mit der Szene gespeichert, zu welcher sie
gehören, können jedoch auch als sogenanntes "Prefab" hinterlegt werden. Prefabs
dienen als eine Art zentrale Vorlage, von der beliebig viele Abbilder/Kopien, genannt

                                                                              7
"Instanzen", erstellt werden können. Änderungen, die am Prefab vorgenommen
werden, übertragen sich dann automatisch auf alle Instanzen.
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Skripte
Um komplexere Verhaltensweisen und eigene Spiellogik zu realisieren kann man sich
eigene Komponenten erstellen. Diese werden über eine mitgelieferte IDE (oder
wahlweise Visual Studio) geskriptet. Wobei man eher schon von "programmieren"
sprechen kann, da der Skript-Code von Unity noch während der Entwicklungszeit
kompiliert wird. Als Sprache kann wahlweise UnityScript (sehr stark an JavaScript
angelehnt), C# oder Boo (ein Python-Dialekt) verwendet werden. C# war in unserer
Projektarbeit das Mittel der Wahl. Die Vorteile waren unter anderem sauberer Code
durch die statische Typisierung, generische Funktionen sowie problemloser Zugriff auf
die umfangreiche .Net/Mono-Klassenbibliothek.

Der mitgelieferte Standard-Skripteditor MonoDevelop

                                                                            8
Deckblatt - Umsetzung der Fakultät M+I als interaktive Echtzeit-3D-Virtual-Reality-Umgebung mit skalierbarem Multiplattform-Ansatz Jonas Schönauer ...
Dokumentation und Ressourcen
Für Informationszwecke stellt Unity auf der offiziellen Homepage bereits ausreichend
Material zur Verfügung. Neben einer Anleitung (User Manual) inkl. Schnelleinstig (User
Basics), findet man dort eine Komponenten-Referenz, in der die Fülle der
verschiedenen vorgefertigten Komponenten und Einstellmöglichkeiten beschrieben
werden, sowie eine Skripting-Referenz, die eine Dokumentation zur Unity-API darstellt.
Desweiteren werden Beispielprojekte und Tutorials bereitgestellt.
Die außerdem angebotenen Mitschnitte der jährlich stattfindenden Unite-Konferenz
bieten Nischenwissen über spezielle Themengebiete. Als Einstieg für Teammitglieder,
die mit Unity arbeiten mussten, diente in unserem Fall auch eine von der Tutorial-
Website "3DBuzz" kostenlos zur Verfügung gestellte, ausführliche Video-Tutorial-Reihe.
Bei Problemen bietet die Homepage mit "Answers" und dem Forum eine Plattform für
den gegenseitigen Austausch unter den Benutzern.

                                                                             9
2.
 Workflow
für Inhalte
Models
Computergenerierte Objekte bilden das Fundament für digitale Spielewelten. Um eine
„echte“ Welt zu schaffen, sind sie der realen Welt nachempfunden, in der auch die
einfachsten Gegenstände sehr komplexe Gebilde sind. Diese Komplexität kann
natürlich nur schwer in Echtzeit am PC berechnet werden. Daher werden für Spiele
stark vereinfachte Modelle erstellt, bei denen sich meistens nur erahnen lässt, was sie
darstellen sollen. Über Texturen werden ihnen dann die fehlenden Details verliehen
und damit Leben eingehaucht.
Die Modelle bestehen aus Polygonen. Das sind Vielecke, die im 3-dimensionalen Raum
angeordnet werden. Da Objekte für Spiele aus möglichst wenig Polygonen aufgebaut
sein sollten, werden sie „Low-Poly-Objekte“ oder „Low-Poly-Modelle“ genannt. Das
Modellieren von Low-Poly-Objekten bringt einige Herausforderungen mit sich und
erfordert in der Regel Planung im Voraus.

Vor dem Modellieren
Systemgröße festlegen
Noch bevor man mit irgendwas loslegt, muss die richtige Systemgröße im benutzten
3D-Grafikprogramm festgelegt werden. Das ist notwendig, damit die erstellten
Modelle gut zwischen den unterschiedlichen Programmen hin- und hergeschoben
werden können und am Ende in der richtigen Größe in der Spiele-Engine landen. Wie
das geht und welche Systemgröße für welches Programm eingestellt werden sollte,
wird im Folgenden beschrieben:

Blender: Metric
Eine Blenderunit entspricht einem Meter in Unity. Das heißt, dass grundsätzlich nichts
umgestellt werden muss in Blender. Dennoch empfiehlt es sich unter „Properties ->
Scene -> Units“ die Units auf „Metric“ umzustellen. Dadurch werden Meter als Meter
angezeigt und beim Modellieren lässt sich mit metrischen Angaben bis auf Mikrometer
genau arbeiten.

                                                                            11
3ds Max: 1 Einheit = 1 Meter
Unter "Anpassen -> Einheiten einrichten -> System-Einheit einrichten"
unter "System-Einheitenskala" muss man für 1 Einheit = 1 ,0 Meter
(1 Unit = 1 ,0 Meters) einstellen, damit 1 Meter auch ein Meter lang ist.
Vorsicht:
       Die Anzeige der Units und die eigentliche Größe der Units sind
       in 3ds Max getrennte Optionen. Standardmäßig ist 1 Einheit = 1 Zoll.
       Unter "Anpassen -> Einheiten einrichten..." lässt sich zwar einstellen,
       dass die Einheitenskala als Metrisches System angezeigt wird, doch
       verändert das nicht die eigentliche Größe einer Einheit. Das hat zur
       Folge, dass zwar 1 Meter im Viewport angezeigt wird, dieser aber
       tatsächlich 1 Zoll lang ist.

Fragen klären:
1 . Wie häufig wird das Objekt vorkommen? (bestimmt: Anzahl der Polygone)
Umso öfter ein Objekt vorkommt, umso weniger Polygone sollte es besitzen. Trotz
weniger Polygone sollte es aber nicht schlechter aussehen, weil der Spieler es ja öfter
zu Gesicht bekommt. Hier gilt es eine gute Balance zu finden. In den „Modelling
Richtlinien“ gibt es eine Tabelle, die grob die „optimale“ Polygonanzahl für Objekte
vorgibt.

2. Wird das Objekt animiert? Was wird an dem Objekt animiert? Wie wird es
animiert? (bestimmt: Position von Pivot-Punkten; Parenting; Aufteilung von Objekten)
Diese Fragen sollen zum Einen klären, wie Pivot-Punkte gesetzt werden müssen, damit
ein Objekt später korrekt animiert werden kann. Zum Anderen soll die Frage klären, ob
Objekte einem anderen Objekt untergeordnet werden müssen, das animiert wird
(Stichwort „Parenting“).

Als Beispiel eignet sich hier eine Tür:
Eine Tür dreht sich um Türachsen. Daher sollte also der Pivot-Punkt an den Türachsen
platziert werden. An der Tür jedoch befinden sich noch weitere Objekte, wie ein Türgriff
und ein Türschloss. Diese sind an der Tür befestigt und bewegen sich mit, wenn die Tür
geöffnet wird. Um sie nicht extra animieren zu müssen, kann man sie einfach der Tür
unterordnen, die Tür zum „Parent“ machen. Darüber hinaus soll auch noch der Türgriff
animierbar sein. Also setzt man den Pivot-Punkt des Türgriffs so, dass er später
heruntergedrückt werden kann.

3. Wird das Objekt später physikalisch berechnet? (bestimmt: Detailgrad)
Das heißt so viel wie: „Kann man das Objekt später durch die Gegend werfen /

                                                                        12
schubsen / treten?“. Ist das für ein Objekt der Fall, so muss es von allen Seiten gut
aussehen. So kann man z.B. bei einem Mülleimer dann nicht den
Boden weglassen um Polygone zu sparen.
4. Was wird modelliert, was kommt in die Textur, was bekommt eine Textur, was
nicht?
Viele Details eines Objekts müssen nicht modelliert werden, sondern können über die
Textur hinzugefügt werden, oder sind nicht wichtig und können ganz weggelassen
werden. Meistens ist es sinnvoll ein Objekt in kleinere Unterobjekte zu unterteilen.
Kriterien für die Unterteilung können sein:
Wie kann man durch die Aufteilung des Objekts das UV-Unwrapping erleichtern?
Bekommen Teile des Objekts überhaupt eine Textur? Oder nur einen Shader (Metall)?

Modellieren allgemein
Polygone
Als Faustregel gilt: Niemals mit Dreiecken modellieren!
Bei Polygonen wird unterschieden zwischen Dreiecken, Vierecken und N-Gons
(Vielecken). Ist beim Modellieren von der Polygonanzahl die Rede, ist damit die Anzahl
von Vierecken gemeint. Während 3D-Grafikprogramme in der Regel mit Dreiecken,
Vierecken und N-Gons umgehen können, benutzen Spiele-Engines ausschließlich
Dreiecke.

Benennung und Rechtschreibung
Jedes Objekt und jedes Unterobjekt eines Objekts braucht einen aussagekräftigen
Namen! Das erleichtert das Finden später in der Spiele-Engine enorm.
Um Export- und Import-Fehlern vorzubeugen, muss bei der Objekt-Benennung
akribisch darauf geachtet werden, dass Sonderzeichen und bestimmte Buchstaben (ä,
ö, ü, ß) vermieden werden.
ß = ss         ä, ö, ü = ae, oe, ue keine „/“ und „ , “ oder andere Sonderzeichen
Ausnahmen: „.“ „-“ „ _“

Normalen
Polygone haben eine Vorderseite und
eine Rückseite. Welche der beiden
Seiten die Vorderseite ist, gibt die
Richtung der sogenannten „Normale“
an. Die Normale ist ein Vektor, der
orthogonal zum Polygon verläuft. In

                                                                     13
3D-Grafikprogrammen selbst sind in
der Regel sowohl Vorder- als auch Backface Culling
Rückseite sichtbar. In Spiele-Engines jedoch ist immer nur die
Vorderseite von Polygonen zu sehen.
Um zu verhindern, dass ein exportiertes Objekt falsch in der Spiele-Engine angezeigt
wird, sollten vor dem Export die Richtungen der Normalen überprüft werden. Dazu
bieten fast alle 3D-Programme die Option „Backface Culling“ an. Ist Backface Culling
aktiviert, sind nur noch die Vorderseiten von Polygonen sichtbar. Verdrehte Polygone
lassen sich so meist schnell finden (Im Beispielbild sind alle Normalen nach innen
gekehrt). Auch ist es in einigen Programmen möglich, Normalen als Linien anzeigen zu
lassen (in Blender: „Display Face Normals As Lines“).

Maßstab
Als Maßstab wurden die realen Maße der Hochschule und der darin befindlichen
Objekte gewählt. Dadurch ist gewährleistet, dass alle Objekte im richtigen
Größenverhältnis zueinander stehen, unabhängig davon, in welchem Programm sie
erstellt wurden. Das funktioniert nur, wenn zuvor die Systemgröße korrekt eingestellt
wurde. Es empfiehlt sich Objekte gleich im richtigen Maßstab zu modellieren, um
später Probleme beim Skalieren zu vermeiden.

Skalierung, Rotation
Das Skalieren von Objekten sollte beim Modellieren für ein Spiel möglichst vermieden
werden, zum einen um Export- und Import-Fehler zu vermeiden, aber auch damit
Physikberechnungen in der Spiele-Engine reibungslos funktionieren können, da diese
sich an der Skalierung orientieren.
Sollte es doch einmal nötig sein, empfiehlt es sich nicht das Objekt als Ganzes zu
skalieren, sondern alle Polygone, Vertices oder Kanten im Bearbeitungsmodus
auszuwählen und diese dann entsprechend zu skalieren. Dadurch bleibt die Größe des
Objekts im Programm bei 1 (Blender), bzw. bei 1 00 (3ds Max), während sich die
tatsächliche Größe jedoch verändert.
Vor dem Export müssen Rotation und Skalierung eines Modells noch einmal überprüft
werden. Die Rotation sollte auf 0° sein und die Skalierung auf 1 , bzw. 1 00.
Für bewegliche Teilen darf man Ausnahmen machen bei der Rotation.
Falls die Skalierung oder Rotation doch von den Standardwerten abweichen sollten,
lässt sich das durch „Freezen“ beheben. Durch Freezen werden Skalierung, Rotation
oder Position auf den Standardwert zurückgesetzt, ohne dass dabei die Größe,
Rotation oder Position wirklich verändert wird.
In Blender ist das über das Kürzel „Strg A“ möglich, in 3ds Max im „Hierarchy“-Panel
unter„Adjust Transform -> Reset: Transform / Scale“.

                                                                    14
Modellieren projektspezifisch
Warum Blender für das
Hochschulgebäude?
Ausschlaggebend für die Entscheidung, das
Hochschulgebäude in Blender zu modellieren, waren
zwei in Blender vorhandene Optionen: „Mesh Display:
Edge Length“ und „Mesh Display: Display Face
Normals As Lines“.
Ist die Option „Edge Length“ aktiv, werden die
Kantenlängen ausgewählter Kanten eines Objekts
                                                       Edge Length
angezeigt. Das erleichtert exaktes Modellieren (nach
Gebäudeplan) erheblich und auch die Fehlersuche
und das Vornehmen von Korrekturen wird dadurch
vereinfacht.
Die Option „ Display Face Normals As Lines“ zeigt im
Viewport die Normalen von Polygonen an. Dadurch
lassen sich schon beim Modellieren verdrehte
Normalen erkennen oder nach dem Modellieren
schneller und leichter als mit „Backface Culling“
finden.

Aussenwand - Aufbau und Struktur der                   Display Face Normals as Lines
Projektdatei in Blender
Damit gewährleistet ist, dass alle Räume, Türen, Fenster, etc. genau zusammenpassen,
wurde die Hochschule aus einem Guss modelliert, das heißt: in einer einzigen
Projektdatei. Einige der so erstellten Objekte wurden danach zu Weiterverarbeitung
nach 3ds Max exportiert. Aufgrund der Größe und Komplexität des Hochschulmodells,
wurde es über mehrere Layer (Ebenen) in Blender verteilt, um es möglichst
übersichtlich zu halten.
Wichtig sind die Ebenen 1 bis 4 und die Ebenen 1 6 bis 20. Auf den Ebenen 1 bis 4
befindet sich das gesamte Äußere des D-Gebäudes, die „Aussenwand“ (ß -> ss). Über
die Ebenen 1 6 bis 20 sind die Räume des D-Baus verteilt, das Innenleben also.

                                           Aussenwand

                                                                        15
                                           Räume
Welche Ebene was beherbergt steht in folgender Liste:

Ebene 1                          Grundgebäude
Ebene 2                          Bodenleisten
Ebene 3                          Fensterrahmen der Außenfassade
Ebene 4                          Außenwelt (Stellvertreterobjekte)
Ebene 6                          Fensterscheiben-Vorlagen für Erstellung in 3ds Max
Ebene 7                          Gebäudeobjekte; Weiterverarbeitung in 3ds Max
Ebene 8                          Türrahmenreferenzen und Verschiedenes
Ebene 1 5                        Kameras und Licht zum rendern - für das Projekt irrelevant
Ebene 1 6                        D001
Ebene 1 7                        Studios EG
Ebene 1 8                        Studios 1 . Stock
Ebene 1 9                        Büros 3. Stock
Ebene 20                         Vorlesungsräume, Labore und Toiletten

Für das Modellieren des D-Baus wurden freundlicherweise Gebäudepläne
bereitgestellt, die durch eigene Messungen ergänzt wurden. Im „fertigen“ Modell
allerdings gibt es einige Unterschiede zu den Plänen. So waren beispielsweise die
Fensterrahmen in der Realität niedriger als im Plan angegeben, weshalb hier beim
Modellieren immer wieder Kompromisse gefunden werden mussten. Weitere Beispiele
sind die Raumhöhen des Erdgeschosses, des 1 .Stocks und des 2. Stocks, die einander
angeglichen wurden, sowie die Türrahmenhöhen der Hörsäle der unterschiedlichen
Stockwerke, die im Plan in unterschiedlichen Höhen angegeben wurden, in der Realität
aber gleich hoch waren etc.
Einige Wände in der Aussenwand mögen auf der ersten Blick sehr konfus, löchrig und
unnötig aufgeteilt aussehen, doch das sind sie nicht ohne Grund. Man muss bedenken,
dass später in Unity nicht nur die Anzahl der Polygone die Performance schwächen
kann, sondern auch andere Faktoren eine Rolle spielen können, wie z.B. die Lightmaps.
Es gilt: Umso mehr Fläche existiert, umso größer werden die Lightmaps, weil für mehr
Fläche mehr Licht und Schatten berechnet werden muss.
Um die Lightmaps also klein zu halten, wurden und sollte man auch weiterhin

                                                                           16
unnötige Flächen bestenfalls „ausschneiden“, auch wenn dadurch einige Polygone
mehr entstehen. Unnötige Flächen sind in der Regel Flächen, die
der Anwender nie zu Gesicht bekommt, z.B. Teile einer Wand, die
durch das Innere eines Lüftungsschachts läuft oder Teile von
Wänden, die sich unter der Erdoberfläche befinden.
Aussenwand – Export aus Blender als FBX

        1 . Vor dem Export der Außenwand müssen zunächst auf allen
        Ebenen alle Objekte deselektiert werden.
        2. Danach wählt man die Ebenen 1 bis 4 als einzige sichtbare
        Ebenen aus.
        3. Um sicherzustellen, dass sich das aktive ausgewählte Objekt
        auf einer der sichtbaren Ebenen befindet, kann ein beliebiges
        sichtbare Objekt im 3D-Fenster (Viewport) ausgewählt werden.
        4. Nun müssen alle Objekte auf den sichtbaren Ebenen selektiert
        werden, durch einfaches Betätigen der A-Taste im 3D-Fenster.
        5. An der oberen Informationsleiste landet man über
        „File -> Export -> Autodesk FBX (.fbx)“ im Export-Menü.
        Dort sollte man die Option „Selected Objects“ in den
        Export-Einstellungen aktivieren, ansonsten aber alle Einstellungen
        so belassen wie sie sind.
        6. Dann muss nur noch der Zielordner ausgewählt und die Datei
        exportiert werden.

Räume – Export aus Blender als FBX
Während die Außenwand über vier Ebenen verteilt ist, sind mehrere Räume immer auf
einer Ebene zusammengefasst. Dass nicht jeder Raum in eigener eigenen Ebene liegt,
hängt damit zusammen, dass die Standardanzahl der Ebenen nicht ausreicht für alle
Räume und es in Blenders Ebenen-System nicht möglich ist neue Ebenen
hinzuzufügen. Man kann also nicht einfach alles in einer Ebene selektieren, wenn man
einzelne Räume exportieren möchte, sondern muss in einer Ebene gezielt den
gewünschten Raum auswählen. Um das so einfach wie möglich zu halten, sind die
Räume so auf die Ebenen verteilt, dass die Auswahl einer einzelnen Räumlichkeit ohne
große Probleme aus der orthographischen Ober-, Vorder- oder Seitenansicht erfolgen
kann, mithilfe von Border Select.

Raumauswahl aus der Vorderansicht

                                                                      17
Der Export eines Raumes erfolgt also folgendermaßen:
       1 . Sicherstellen, dass nichts selektiert ist
       2. Die Ebene auswählen, in der sich der zu exportierende Raum befindet
       3. In die vorgesehene orthographische Seiten-, Vorder-, Oberansicht wechseln
       4. In die Wireframe-Ansicht wechseln, damit auch verdeckte Objekte
       des Raumes selektiert werden können
       5. Ein Objekt des zu exportierenden Raumes selektieren um es als aktives
       Objekt zu markieren
       6. Mithilfe von Border Select den Raum, also alle zum Raum gehörenden
       Objekte, selektieren
       7. „File -> Export -> Autodesk FBX (.fbx)“ und „Selected Objects“ aktivieren,
        wenn es nicht schon aktiviert ist
       8. Zielordner auswählen und exportieren

Polygone sparen
Kreise, Zylinder, runde Objekte:
Kreise, runde Objekte und Zylinder sind naturgemäß sehr polygonlastige Objekte. Um
Kreise und Zylinder spieletauglich zu machen, muss etwas getrickst werden: Die
Seitenanzahl wird auf ein Minimum reduziert (6 Seiten). Dadurch werden allerdings
Flächen mit harten Kanten sichtbar. Diese harte Kanten kann man jedoch
verschwinden lassen, indem man die Kanten-Interpolation der Flächen von „hart“ auf
„weich“ stellt.

Kanten-Beispiel:
Blender                                   3ds Max

                                                                      18
Flat               Smooth                  Ohne Smoothing-   Mit Smoothing-
                                           Group             Group
Für die Seitenanzahl von Kreisen gilt:
In der Regel: 6-1 0 Seiten
In wenigen Ausnahmefällen: 4-seitig. Nur bei sehr kleinen Gegenständen.
Bei großen Objekten, ab etwa 30 bis 50 cm Durchmesser: mehr als 1 0 Seiten

Generell dürfen runde Objekte ruhig etwas eckig sein, da das später in der Anwendung
nicht sonderlich auffällt.

Vertices zusammenfassen:
Ein weiterer Weg Polygone zu sparen ist, Vertices, die auf einer Linie liegen,
zusammenzufassen. Dieser Schritt geschieht nach dem Modellieren und sollte
bevorzugt bei flachen Ebenen angewandt werden, weniger bei organischen Objekten.

Vor dem Zusammenfassen                     Nach dem Zusammenfassen

Aber Vorsicht: Bei dieser Methode können Dreiecke entstehen, wie auf dem zweiten
Bild zu sehen ist. Bei flachen Ebenen sind Dreiecke weniger ein Problem, sofern das
Objekt wirklich FERTIG modelliert ist. Bei organischen Objekten allerdings, wie
Menschen oder Pflanzen, sollten Dreiecke auf jeden Fall vermieden werden, da
Dreiecke unter anderem das UV-Mapping erschweren können.

Probleme und Lösungen
3ds Max - Viewport-Clipping
Hat man in 3ds Max die richtige Systemgröße eingestellt,
wird man häufig mit einem Clipping-Problem konfrontiert.
Das bedeutet, dass Teile, die näher an der Viewport-
Kamera liegen, „abgeschnitten“ werden. Das erschwert das

                                                                      19
Bearbeiten von Objekten.                                   Clipping
Lösung:
Clipping lässt sich beheben, indem man im Viewport oben links unter „Perspective“ das
sogenannte „Viewport-Clipping“ aktiviert. Danach erscheint rechts am Rand im
Viewport eine gelbe Leiste mit zwei Markern. Der obere Marker kontrolliert das
Clipping in der Entfernung, der untere das Clipping vor der Kamera.
Schiebt man den unteren Marker an das untere Ende der Leiste, verschwindet das
Clipping und es lässt sich wieder unbeschwert arbeiten.

Blender – FBX-Export
Folgende Bugs traten bei Blenders FBX auf:

Animationen werden fehlerhaft als .fbx exportiert.
Lösung:     in 3ds Max oder Maya animieren.

Kantenglätten von Polygonen werden immer auf Smooth gesetzt beim Export als .fbx.
Lösung 1 : Beim Import in Unity die Normalen neu kalkulieren lassen!
Lösung 2: Wenn genaues Festlegen der Kantenglätten nötig ist, Objekt exportieren
             und Kantenglätten in 3ds Max oder Maya (oder anderem 3D-
             Bearbeitungsprogramm) bearbeiten

Beim Import einer Blender-FBX nach Maya waren die Objekte der Datei überall im
dreidimensionalen Raum verstreut.
Lösung:      Vor dem Exportieren aus Blender muss die Location aller Objekte auf 0
             gesetzt werden (Strg A)

3ds Max - FBX-Import
Beim Import von FBX-Dateien nach 3ds Max werden diese oft mit einer Größe von 1
anstatt von 1 00 importiert.

Lösung:
Das Skalierungs-Problem lies sich teilweise beheben, indem man beim Import in den
„Advanced Options“ unter „Units -> File units converted to“ die Units zu „Centimeter“,
manchmal aber auch „Meters“ umstellte. Allerdings hilft das nicht immer. Oft bleibt
nichts anderes übrig als die Skalierung der importierten Objekte per Hand zu justieren.

                                                                      20
3ds Max – Blender-FBX Korrektur
Blender setzt beim Export als .fbx immer alle Polygone auf„smooth“.
Das Problem ist, dass sich das „Smooth“ nicht einfach über die
Smoothing Groups in 3ds Max beheben lässt, da 3ds Max smoothe
Polygone aus Blender nicht als solche erkennt.
Lösung:
Als erstes verpasst man dem Objekt den „Turn To Poly“-Modifier. Danach konvertiert
man das Objekt samt Modifier in ein neues Polygon-Objekt, indem man einen
Rechtsklick auf das Objekt macht und im darauf erscheinenden Menü „Object ->
Convert to Poly“ wählt. Nun sind die Kantenglätten aller Polygone auf „flat“
zurückgesetzt und Smoothgroups können wieder gezielt auf bestimmte Polygone
angewandt werden, oder eben auch weggelassen werden.

Abgabe-Checkliste
Folgende Punkte fassen nochmal zusammen, was vor jedem Export beachtet werden
sollte:
        1 . Ist das FBX sinnvoll (= da wo nötig) in Objekte unterteilt?
        2. Bei möglicherweise (geplant oder denkbar) beweglichen Teilen:
                  2a) Sind diese Objekte verschachtelt?
                  Hat Verschachtelung einen Vorteil?
                  2b) Sind die Pivot-/Drehpunkte richtig gesetzt?
        3. Normals: Schauen die Faces in die richtige Richtung?
        4. Gibt es irgendwo sinnlose Polygone? Insbesondere:
                  - auf geraden Flächen?
                  - an nicht sichtbaren Stellen?
                  - an schwer sichtbaren Stellen?
        5. Sind weiche Kanten auf smooth eingestellt? Sind harte Kanten
        und glatte (z.B. flache Polygone einer Fläche) auf hart eingestellt?
        6. Sind alle Objekte korrekt, einheitlich und ohne ä ü ö ß oder
        Sonderzeichen benannt?
        7. Transformations: Sind alle Skalierungen gefreezt, also auf 1 ?

                                                                 21
Texturen
Texturen spielen in Echtzeitumgebungen eine komplexere Rolle, als in gerenderten
Filmen und Bildern. Da die Models aufgrund der Performance mit deutlich weniger
Polygonen, nämlich als Low-Poly-Modelle erstellt werden, müssen ihre Details über die
Texturen visualisiert werden. Dabei muss die Textur möglichst effektiv und sinnvoll
angelegt werden, wobei Muster, die sich wiederholen (beispielsweise die Radkappen
eines Autos) nur einmal abgebildet und auch die Größe (HD-Texturen fordern deutlich
mehr Rechenleistung) je nach Model gründlich abgewägt werden sollte.
Es gilt zu unterscheiden zwischen „passgenauen“ Texturen und nahtlosen Texturen.
Letztere werden für große und sehr große Flächen, meistens Berge, Wege und
Landschaften verwendet und mehrfach aneinandergereiht. Der Ausschnitt, den der
Spieler betrachtet, weist meist keine oder nur wenige Wiederholungen auf und wirkt
somit „korrekt“, während Ressourcen gespart werden, da keine riesige Textur in den
Speicher geladen werden muss.

Grundlagen zur Arbeitsweise
Für das Projekt wurden nahezu alle Texturen selbst erstellt, zudem wurden wenige freie
Texturen verwendet. Dies lag vor allem daran, dass der Bau realitätsgetreu abgebildet
werden sollte, in den meisten Fällen also Fotos zur Herstellung der Textur zur Hand
genommen wurden. Diese Arbeitsweise wurde etwas erschwert durch die
Notwendigkeit, die Gegenstände an Ort und Stelle abzulichten und nicht etwa in
einem gut ausgeleuchteten Fotostudio mit den Objekten arbeiten zu können.
(Letzteres wäre unter gegebenen Umständen auch utopisch und keineswegs
umsetzbar gewesen). Oberflächen, die nicht fotografiert werden konnten, wurden
deshalb in Photoshop erstellt.

Fototexturen
Der zu texturierende Gegenstand sollte von allen sichtbaren Seiten frontal und gerade
abgebildet werden. Unebenheiten können in Photoshop mithilfe des „Frei-

                                                                     22
Transformieren“-Werkzeugs beseitigt werden. Um Fototexturen zu erstellen, eignet
sich Photoshop aufgrund der besseren Flexibilität und des höheren
Funktionsumfangs eben dieses Werkzeugs besser. Gearbeitet wurde
mit Rohdaten im DNG-Format („Digital-Negative“-Format), die mit
dem Photoshop-eigenen RAW-Konverter („Camera Raw“) einfach
für die Bearbeitung aufbereitet werden können.
Aber auch für die Arbeit mit Gimp gibt es Open-
Source-Software, die sich gut zur Behandlung
der Rohdaten eignet. Benutzt wurde bei diesem
Projekt beispielsweise Photivo.
Die Textur sollte derart angelegt werden, dass
es möglichst einfach ist, das 3D-Model
zweidimensonal darauf abzubilden, gleichzeitig
sollten sich wiederholende Oberflächen aber                    Textur des Feuermelders
nur einmal vorkommen.

Nahtlose Texturen
Die meisten Probleme bei nahtlosen Texturen machen die Helligkeitsunterschiede.
„Kachelt“ man das Bild, werden schnell unwillkommene Muster sichtbar, außerdem
bereitet das „nahtlos machen“ der Texturränder Probleme. Entgegenwirken kann man
durch das Abschneiden des Bildrandes (Ausschneiden eines mittigen Bildbereichs), der
durch die Fotografie meist technisch bedingt abgedunkelt ist oder durch
entsprechende Einstellungen im RAW-Konverter (in Photoshops Camera Raw:
„Objektivkorrekturen“). Die Helligkeit kann auch angepasst werden, indem man das
Bild durch sein eigenes Duplikat überlagert, das farblich invertiert, entsättigt und
weichgezeichnet wurde. Der Nachteil liegt hier jedoch im Gaussischen Weichzeichner,
der kaum erkennbare „Schlieren“ durch die Interpolation erzeugt, die sich jedoch beim
Erstellen der Specularmap deutlich zeigen.
Um die Ränder zu kaschieren, gibt es zwei Möglichkeiten, die im Optimalfall
kombiniert eingesetzt werden können:

1 ) Soll bspw. der rechte Rand des Bildes nahtlos an den linken angepasst werden, so
kann ein Stück, das direkt rechts anliegt (der später zu verwendende Bereich ist durch
die blauen Linien markiert), kopiert und an den linken Rand gelegt werden. Die
dadurch entstehende harte Kante muss natürlich retuschiert werden.

Ausgewählter, zu bearbeitender Bereich mit kopierter Auswahl                         23
2) Mithilfe des Filters „Verschiebungseffekt“ (Photoshop) kann das Bild verschoben und
somit die Kanten zentriert werden. Diese können dann z.B. mithilfe des Stempel-
Werkzeugs retuschiert und entfernt werden.

Verschiebungseffekt                        Finale Textur

Zur Erstellung nahtloser Texturen eignet sich Gimp ein wenig besser, zudem es den
Filter„Nahtlos machen“ bereit hält, der manchmal Arbeit ersparen kann.

Photoshoptexturen
Mithilfe der Filter im Grafikprogramm können Oberflächenstrukturen generiert werden.
Die Ebenenoptionen (z.B. „Schlagschatten“ und „Relief“) ermöglichen die Visualisierung
von Tiefe. Vor allem künstliche Ober-
flächen lassen sich so einfach und über-
zeugend darstellen.

Ihre Authentizität erhalten Texturen üb-
licherweise durch die Kombination mit
Schmutz und Zeichen der Abnutzung. Da
in diesem Projekt jedoch die Realitäts-
treue an erster Stelle stand, war dies
kaum einzusetzen.

                                            Textur aus Metallplatten für die Wand in D001

                                                                          24
Texturarten
Die oben aufgezeigten Texturen sind alle Diffuse-Maps: Sie speichern ausschließlich die
Farbwerte für die Polygone des Models. Um eine möglichst realitätsnahe Oberfläche zu
gestalten, bedient man sich der Methode, auch das Glanzverhalten und den
Schattenwurf in Texturen darzulegen. Diese sind dann in Graustufen abgelegt.

Specular-Map
Die Specular-Map speichert die Werte für den Glanz (Weiß = hellste Stelle, Schwarz =
kein Glanz). Am einfachsten ist sie mittels einer Schwellenwertsberechnung der
entsättigten Diffuse-Map zu erstellen (Nur Werte ab einer bestimmten Helligkeit
werden beibehalten). Im Projekt wurde sie entworfen, indem die Helligkeitswerte
komprimiert wurden (Weiß überstrahlt teilweise, andere Teile werden Schwarz). Die
Specular-Map wird in Unity als Alphakanal der Diffuse-Map implementiert, beide sind
also in derselben Textur als RGB+Alpha verpackt.

Specularmap             Textur ohne Specular          Textur mit Specularmap

Bump-Map
Über die Bump-Map wird eine Schattierung und somit ein höherer Detailgrad der
Oberfläche simuliert. Dabei werden die Werte über die Unebenheiten einer
Oberfläche ebenfalls in einer Textur abgespeichert (Weiß = höchster Punkt, Schwarz =
tiefster Punkt).

                                                                       25
Bump-Map                Ohne Bump-Map                   Mit Bump-Map

Eine Bump-Map wirkt illusionär, sie verändert das Model nicht.
Beim Import muss sie als „Normalmap“ gekennzeichnet werden.
Height-Map
Generell gibt es keinen Unterschied zwischen einer
Bump-Map und einer Height-Map, Unity aber
differenziert an dieser Stelle noch einmal. Die
Height-Map wird nicht als Normal-Map importiert.
Sie ist in der Lage, grobe Formen aus einer Fläche
"herauszuheben", indem sie Höhenunterschiede
generiert. Dies kann sogar ohne Textur umgesetzt
                                                            Heightmap
werden (einfache Skalierung der Oberfläche). Die
Height-Map ist ebenfalls rein visuell und verändert
das Model nicht. Über eine Alpha-Map (in Unity
anzugeben beim Import der Textur) wird festgelegt,
welche Teile wie weit herausragen (Weiß = höchster
Punkt, Schwarz = tiefster Punkt).

Displacement-Map
Displacement-Maps sind ebenso wie Bump-Maps
angelegt, verändern die Oberflächenstruktur des
Models jedoch tatsächlich und wirken demnach Material mit Heightmap
realistischer, sind aber auch rechenaufwändiger. In
Unity gibt es noch keine Möglichkeit, Displacement-Maps einbinden.

Atlastexturen
Die Hochschule bot einige Objekte, die sich in der Struktur gleichen, jedoch
unterschiedliche Texturen benötigen. Hierzu gehören Bilderrahmen, Türschilder,
Anzeigen und Knöpfe. Wir lösten den Umstand, mehrere Texturen für dasselbe Model
anlegen zu müssen, indem wir gleichartige Texturen in derselben Größe auf einer
sogenannten Atlastextur zusammenführten. Mittels des Skripts "UV-Tiling-Adapter"
(komplette Funktion nachzulesen in Kapitel 4.2 "Skriptreferenz") wurde dann dem
entsprechenden Objekt seine Textur auf dem Atlas zugewiesen.
Wichtig: Um den UV-Tiling-Adapter nutzen zu können, müssen alle Texturausschnitte
dieselbe Größe (bspw. 200 x 200 Pixel) besitzen.

                                                                        26
Atlastextur für die Knöpfe des Fahrstuhls, unten gedrückt
UV-Maps
Neben einer möglichst niedrigen Polygonzahl der
Models sollte sich auch die Anzahl der
Materialzuweisungen beschränken. Idealerweise
sollten alle Oberflächen eines Objektes in einer
Textur untergebracht werden.
Die Textur muss an das Model „angepasst“ werden,
was mithilfe von UV-Koordinaten geschieht. Im 3D-
Programm (im Projekt wurde mit Maya gearbeitet),
werden die Vertices in „UVs“ abgebildet, d.h. aus
dem dreidimensionalen Modell wird ein               An Textur angepasstes UV-Mesh
zweidimensionales Netz generiert. Dessen
Polygone/Vertices können nun an die zugehörigen
Plätze auf der Textur geschoben werden. Dabei
sollten für die Verwendung in Unity die UV-Werte
jedes Vertex optimalerweise zwischen 0 und 1 (UV-
Skala) liegen.

                                                    Texturiertes Model im Viewer
Effektivität
Je nach Polygonzahl kann das Mappen viel Zeit in Anspruch nehmen. Es ist deshalb
intelligent, sich vorher zu überlegen, wie man die Polygone am besten auf der Textur
anordnen kann und danach erst die Textur zu entwerfen. In Maya gibt es drei simple
Methoden, um UVs zu erstellen:

Planar:   Bildet die Polygone/Vertices frontal ab. Die Sicht definiert man dabei als
Fläche, die über die drei Achsen (X, Y, Z) gedreht sowie verschoben und somit
angepasst werden kann. Vertices, die von dieser Fläche aus gesehen hintereinander
liegen, werden demnach auf der UV-Map auf dieselbe Position übereinander gesetzt.

                                                                       27
Planar-Mapping eignet sich für vorwiegend rechteckige Models und sehr simple
Strukturen (Türen, Tische, Wände,...).
Zylinderförmig: „Rollt“ die Polygone in eine Richtung ab. Am einfachsten ist dies
am Beispiel eines Zylinders selbst zu erklären: Möchte man diesem eine Textur
auftragen, so muss man die Sektoren aneinandergereiht zu einer Fläche
zusammenfügen. So kann man die Textur auf den Zylinder „aufwickeln“. Eignet sich bei
Models, die nur in eine Richtung abschließen oder Zylinderform besitzen (Uhren,
Fussbodenleisten, …)

Kugelförmig:      Grundsätzlich für kugelförmige Objekte, aber auch gut zu
gebrauchen, wenn weder planares noch zylinderförmiges Mapping effektiv
anwendbar ist. Ein gutes Beispiel ist hier die PC-Maus: Sie besitzt eine sehr organische
Form, keine klaren Kanten und Rundungen. Das Kugel-Mapping ermöglicht eine
schnelle Abbildung der Faces als zweidimensionales, zusammenhängendes Mesh, das
zudem relativ gut proportioniert ist.

Größen
Im Falle der Hochschule gibt es sehr
viele Flächen, die dieselben Texturen
aufweisen (Wände, Böden,...), jedoch in
der Größe starke Unterschiede besitzen.
Würde man eine 2m²-Wand „uniform“ in
das UV-System mappen, also so, dass
die Polygone das UV-Feld füllen und
eine 20m²-Wand auf die gleiche Weise,
so ist die UV-Fläche der kleineren Wand Gleiche UV-Koordinaten
größer im Verhältnis zur Fläche des
Objektes. Benutzt man nun dasselbe
Material, so wird es auf der größeren
Fläche stark skaliert werden (niedrigere
Auflösung der Textur durch kleinere
Größe im UV-System).
Maya bietet die Möglichkeit, beim
Planar-Mapping die Größe der
Projektionsfläche festzulegen. Die Gleiches Projektionsverhältnis

                                                                       28
Oberfläche des Objektes wird dann abhängig von dieser Fläche skaliert. Stellt man also
bei jeder Projektion die gleiche Flächengröße ein, so wird im späteren Schritt auch
immer die Textur in der gleichen Skalierung aufgetragen werden.
Die meisten Wände im Projekt wurden mit einer Projektionsfläche
von 0,5 auf 0,5 gemappt.
Mehrere Materialien
Sollen dennoch mehrere Materialien auf ein Objekt gelegt werden, so ist die
Materialbelegung am effektivsten während des Mapping-Schrittes zu bezeichnen.
Dazu muss man nur die betreffenden Polygone auswählen und ihnen ein neues
Material zuweisen. Unity entnimmt den FBX-Daten beim Import automatisch die
Information, wie viele unterschiedliche Materialien einem Objekt zugeordnet wurden.

Nahtlose Texturen
Bekommt ein Model eine nahtlose Textur und erscheint im Unity-Projekt nicht in
unterschiedlichen Größen (z.B. diverse Stühle), so kann für dieses sehr schnell und
einfach mit der Funktion "Automatic Mapping" eine UV-Map erstellt werden. Nachteil
des automatischen Mappings ist, dass man die Anzahl der Shells (Gruppe aus
miteinander verbundenen UVs) schlecht kontrollieren kann und kein
Projektionsverhältnis eingestellt werden kann.

Komplexe Models
Eigentlich ist es üblich, eine UV-Map zu erstellen, indem man eine "Naht" ("Seam")
definiert und dann anhand dieser einen "Unwrap" ausführt. Dabei wird die zu
projezierende Fläche an den Nähten aufgeschnitten und für jede durchgehende Naht
eine Shell erzeugt. Diese Methode wurde bei unserem Projekt jedoch nicht genutzt, da
sie aufwendiger ist und nicht nötig war, da die Models sehr einfach strukturiert waren.
Sollten in das Projekt einmal komplexere Models mit organischen Strukturen (z.B.
Menschen) eingebunden werden, sollte diese Methode unverzichtbar werden.

                                                                     29
Sound
Ohne Sound würde in einer solchen Anwendung eine Dimension fehlen. Das Ziel
unseres Projektes war es, die Hochschule realitätsnah darzustellen. Hierfür gehört ein
Sounddesign, welches authentisch ist und den „Spieler“ dabei unterstützt, in die Welt
einzutauchen.

Folgende Fragen galt es für uns zu beantworten:

       - Was hören wir, wenn wir an der Hochschule sind?

       - Welche Geräusche sind durchgehend zu hören und welche
         entstehen erst durch Interaktionen mit Objekten?

       - Welche Interaktion werden im Spiel möglich sein?

       - Jedes Geräusch ist einzigartig.
         Wie kommen wir dem Realismus möglichst nah?

In der Tongestaltung haben wir zwischen zwei Tonebenen unterschieden:

       - Atmo (diffuse Hintergrundgeräusche, Stereoaufnahme)
       - Geräusche (im Vordergrund, entstehen durch Interaktion,
         Monoaufnahme)

Atmo
In der 3d-Umgebung haben wir bezüglich der Atmo sowohl zwischen Tag und Nacht,
als auch zwischen den verschiedenen Räumen und Fluren Unterscheidung getroffen.
Hierbei galt es darauf zu achten, dass die jeweilige Atmo den Raumeindruck vermittelt
und keine Geräusche besitzt die Vordergründig auftreten. Dies ist wichtig, weil die

                                                                     30
Aufnahmen sich regelmäßig in einer Schleife wiederholen und so markante Geräusche
Aufmerksamkeit auf sich ziehen würden.
Die Herausforderung bei der Bearbeitung der Atmos bestand darin,
einen fließenden Übergang vom Ende des Sampels zum Anfang zu
erzeugen. Die Programmierung von Crossfades in Unity wäre zu
aufwendig. Die Lösung bestand darin, die Spur zu schneiden und die beiden
Schnittstellen jeweils an den Anfang und ans Ende zu setzen. Die daraus entstandenen
zwei Spuren wurden mit einem Crossfade zu einer Spur gefügt.

Die beim Schnitt entstandenen zwei Spuren wurden so vertauscht, dass die Schnittpunkte jeweils den Anfang
und das Ende der Spur bilden.

Geräusche
Um eine möglichst realistische Klangumgebung zu gestalten, haben wir in die 3D-
Umgebung jeweils verschiedene Variationen einer „Geräuschart“ eingebunden.
Außerdem wurden viele Geräusche darin unterschieden, von welcher Position aus sie
gehört werden. Das Zuschlagen der Hörsaaltür aus dem Flur hat beispielsweise eine
andere Klangcharakteristik als das Zuschlagen der Tür aus dem Hörsaal.
Der wichtigste Faktor für die Planung der Geräuschaufnahmen, war das Wissen um die
Implementierung der Sounds in Unity.

Im Folgenden, ein Beispiel anhand der Türklinke:
Das Drücken und Loslassen der Maustaste soll das Drücken und Loslassen der Türklinke
simulieren. Hierfür reicht es also nicht, im Spiel eine Aufnahme für das Drücken und
Loslassen wiederzugeben, da der Spieler selbst entscheidet, wann er die Türklinke
wieder loslässt.
Es wird ein „Druckgeräusch“ und ein „Loslassgeräusch“ benötigt, um je nach Aktion des
Spielers das jeweilige Geräusch abspielen zu können.
Aufgrund der geplanten Interaktionen und der damit verbundenen Synchronisation
wurden die Geräusche in ihre einfachste Form zerteilt und geschnitten.

Unterteilung der Aufnahmen am Beispiel vom Gehen in einzelne Schritte.

                                                                                    31
Die zerteilten Aufnahmen mussten hierbei sowohl für sich als auch
als Ganzes funktionieren.
Bearbeitung der Aufnahmen
Nach der Tonaufnahme wurden die Daten vorsortiert und bereits vollständig benannt.
Zur Bearbeitung der Tonaufnahmen haben wir die Software Cubase 5 benutzt.
Als ersten Schritt galt es sowohl Störgeräusche, als auch Geräusche die zu
Vordergründig sind bei den Atmos zu entfernen. Weiterhin wurden die Atmos so
bearbeitet, dass sie in einer Schleife abspielbar sind ohne ein Knacksen zu verursachen.
(Siehe Atmo)

Die Geräusche die Störungen beinhalteten wurden aussortiert. Manche mussten neu
Aufgenommen werden weil es bei der Aufnahme zu einer Übersteuerung kam.
Nach der Unterteilung in die einzelnen Bestandteile wurden die Sampels jeweils mit In-
und Outfades versehen damit keine Störlaute entstehen, wenn die Bestandteile
nacheinander abgespielt werden.

Als letzten Schritt der Tonbearbeitung galt es die Atmos und Geräusche zu Pegeln. Weil
wir bereits bei der Aufnahme darauf geachtet haben den Eingangspegel nicht zu
verändern, waren nur ein paar Feinjustierungen nötig.

                                                                      32
3.
Umsetzung
 mit Unity
Struktur
Bevor die Details und der genaue Umgang mit den Projektbestandteilen in Unity
erklärt werden, lohnt es sich, einmal die groben Strukturen betrachtet zu haben.
Grundsätzlich hält sich unser Projekt an die üblichen Konventionen eines normalen
Unity-Projektes, die in den offiziellen "Unity Basics" gut verständlich beschrieben sind.
Darauf aufbauend gibt es für die virtuelle Hochschule allerdings ein paar
Konventionen, an die wir uns während der Entwicklung gehalten haben, die
nachfolgend aufgelistet sind.

Ordnerstruktur
Die Projekt-"Datei" ist Unity-typisch ein Projektordner. Diesen haben wir weiter mit
Unterordnern unterteilt, wobei von uns zwischen folgenden Inhalten unterschieden
wird:

Editor
Dieser Ordner enthält (selbstgeschriebene und vorgefertigte) Editor-Scripts, welche
direkt im Unity-Editor ausgeführt werden. Damit kann der Editor selbst um bestimmte
Funktionen erweitert werden. Genauere Informationen finden sich im Unity-Manual.

Materials
Alle im Projekt vorkommenden Materials. In diesem Ordner befinden sich NUR die
Materials; dazugehörige Prefabs und Texturen haben dagegen einen eigenen Ordner.
Die Materials werden weiter unterteilt nach "randlos", "universal" und UV-Maps. Siehe
Kapitel "Materials".

Meshes
Die gemappten und im finalen Projekt verwendeten Mesh-Dateien aus den 3D-
Modeling-Programmen befinden sich in diesem Verzeichnis. Die Ordnerunterteilung ist
die gleiche wie im Prefabs-Ordner (siehe nächster Abschnitt: "Objektkategorisierung").

                                                                       34
Prefabs
Vorlagen für alle vorkommenden Objekte werden als Unity-"Prefabs" in diesem Ordner
gespeichert. Genaueres zum Thema Prefabs ist dokumentiert im Kapitel "Objekte &
Prefabs". Die Ordnerunterteilung ist die gleiche wie im Meshes-Ordner (siehe nächster
Abschnitt: "Objektkategorisierung").

Scripts
Dieser Ordner enthält alle selbstgeschriebenen Unity-Scripts, welche zur Laufzeit
ausgeführt werden.

Sounds
Alle Geräusche und Atmos, nach Verwendungszweck unterteilt.

Standard Assets
Dieser Ordner enthält vorgefertigte Inhalte, die von den Unity-Entwicklern
bereitgestellt werden. In unserem Fall sind dies konkret: Der Character-Controller
(siehe Unity-Manual) sowie Image Effects (ebenfalls im Manual).

Szenen
An diesem Platz liegen alle im Spiel vorkommenden Levels, in Unity "Szenen" genannt,
sowie die zugehörigen Lightmaps. Das Projekt besteht zum derzeitigen Stand aus nur
einer einzigen, großen Szene.

Texturen
Die Texturen zu den im Projekt vorkommenden Materials werden an dieser Stelle
separat gespeichert, um einen schnellen Wechsel der Import-Einstellungen zu
ermöglichen und den Überblick nicht zu verlieren.

                                                                    35
Objektkategorisierung
Es war schnell klar, dass die Unmengen an Gegenständen in der virtuellen Hochschule
in irgendeiner Art und Weise geordnet werden müssen. Perfekte Kategorien zu finden
war wegen der vielen Überschneidungen und Mischformen nicht möglich, weswegen
wir folgende Näherung verwendeten, die zumindest meistens eine grobe, in etwa
gleich umfangreiche Unterteilung ermöglicht:

Grobe Bausubstanz
Diese Kategorie umfasst alle gröberen, im Sinne von größeren, baulichen Objekte in
der Hochschule. Typischerweise Wände, Treppen, Türen, Fenster, Geländer...

Gebäudezubehör
Objekte, die nicht unter die Kategorie "Grobe Bausubstanz" fallen, allerdings der
Verwendung nach eher dem Gebäude an sich, als dem Hochschulbetrieb zuzuordnen
sind, finden sich hier. Typische Beispiele wären Sicherheitssysteme wie Feuermelder,
Lampen, Steckdosen, WC-Bauteile.

Fixierte Einrichtung
Dem Hochschulbetrieb zuzuordnende Gegenstände, welche fest verankert oder auf
sonstige Weise fixiert sind.

Lose Einrichtung
Dem Hochschulbetrieb zuzuordnende Gegenstände, welche beweglich oder lose sind.

Außenbereich
Alle Objekte, welche sich im allgemeinen außerhalb der Mauern des D-Gebäudes
befinden.

Räume
Das Fundament der einzelnen Räume, bestehend aus mindestens Boden, Wänden und
Decke wurde von uns separat behandelt. Markante darin befindliche Eigenheiten,
bspw. typische Rohre, Fensterrahmen oder Bodenerhöhungen können eingeschlossen
werden.

                                                                    36
Sie können auch lesen