Ein Vorgehensmodell zur Integration von realen

Bachelorarbeit zum Thema
„Ein Vorgehensmodell zur Integration von
realen Umgebungen in Rennsimulationen am
Beispiel des Alemannenrings“
zur Erlangung des akademischen Grades
Bachelor of Science(FH)
vorgelegt dem
Fachbereich Informatik der Fachhochschule Schmalkalden
Ricardo Hohmann
Matrikel-Nr: 270187
Schmalkalden, den 10. September 2010
Betreuer: Prof. Ralf Böse
Gutachter: Prof. Klaus Chantelau
Inhaltsverzeichnis
1. Einleitung
6
2. Grundlagen
2.1. Rennsimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Modifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Notwendige Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
9
9
3. Vorgehensmodell
3.1. Auswahl realer Umgebung . . . . . . . . . . . . . . . . .
3.2. Suche nach Referenzen . . . . . . . . . . . . . . . . . . .
3.3. Auswahl der Rennsimulation/Software . . . . . . . . . .
3.3.1. Vertraut machen mit gewählter Simulation . . . .
3.3.2. Auswahl der Software . . . . . . . . . . . . . . . .
3.4. Umsetzung realer Inhalte . . . . . . . . . . . . . . . . . .
3.5. Der Weg von einer virtuellen Umgebung zur Rennstrecke
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
13
13
14
14
15
4. Auswahl der Rennsimulation
4.1. Überblick über Rennsimulationen . . . . . .
4.2. Entscheidungskriterien . . . . . . . . . . . .
4.3. Entscheidung für rFactor . . . . . . . . . . .
4.4. verwendete Software . . . . . . . . . . . . .
4.4.1. rFactor-spezifische Tools und Plugins
4.4.2. Modellierung - 3dsMax . . . . . . . .
4.4.3. Bildbearbeitung - Photoshop . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
20
20
20
21
22
5. Modellierung
5.1. Modellierung der Strecke
5.1.1. FFD-Modelling .
5.1.2. Loft-Extrusion .
5.1.3. Checkpoints . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
5.2. Modellierung der Umgebung . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1. Entstehung eines Hauses . . . . . . . . . . . . . . . . . . . . . . .
5.2.2. weitere Umgebungsobjekte . . . . . . . . . . . . . . . . . . . . . .
6. Materialien
6.1. Texturen . . . . . . . . . . . . . . . . .
6.1.1. verschiedene Arten . . . . . . .
6.1.2. Verwendung . . . . . . . . . . .
6.2. Der Materialeditor . . . . . . . . . . .
6.3. Shader und Multitexturing . . . . . . .
6.4. Auswirkung der Materialnamen auf das
7. Filestruktur
7.1. .gdb Datei - Informationen
7.2. .scn Datei - Objekte . . .
7.3. .aiw Datei - KI-Linien . .
7.4. .cam Datei - Kameras . . .
über
. . .
. . .
. . .
die
. .
. .
. .
8. Abschließende Bemerkungen
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Fahrverhalten
Strecke
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
31
.
.
.
.
.
.
32
32
32
33
34
36
38
.
.
.
.
39
40
41
42
42
43
A. Anhang
44
A.1. Gedanken und Vorgehensweise einen Profis . . . . . . . . . . . . . . . . . 44
A.2. Tabelle zu Materialien in rFactor . . . . . . . . . . . . . . . . . . . . . . 46
A.3. Waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B. Literaturverzeichnis
48
3
Abbildungsverzeichnis
4.1. Matrix zur Einordnung der Simulationen . . . . . . . . . . . . . . . . . .
18
5.1.
5.2.
5.3.
5.4.
5.5.
.
.
.
.
.
24
25
26
27
30
Gebäude des Ale. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
34
35
35
36
37
7.1. Screenshot: Hauptordner Alemannenring . . . . . . . . . . . . . . . . . .
7.2. Screenshot: Unterordner Streckenvariante Alemannenring . . . . . . . . .
39
40
Bilderserie: Schritte beim FFD-Modelling . . . . . . . . . . .
Konturspline mit Material-ID´s und Pfadspline . . . . . . .
Rollout: Oberflächen- und Hauptextrusionsparameter (Loft)
Loft-Extrusion mit Kontursplines . . . . . . . . . . . . . . .
Bilderserie: Die Entstehung eines Hauses . . . . . . . . . . .
6.1. Vergleich beider Varianten zur Texturierung an einem
mannenrings . . . . . . . . . . . . . . . . . . . . . . .
6.2. Materialeditor: Rollout Multi-/Unterobjekt . . . . . .
6.3. Materialeditor: Rollout gMat . . . . . . . . . . . . . .
6.4. Materialeditor: Rollout gTex . . . . . . . . . . . . . .
6.5. Shader: Zusammenspiels verschiedener Texture Stages
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
4.1. aktuelle Rennsimulationen . . . . . . . . . . . . . . . . . . . . . . . . . .
17
A.1. rFactor Materialien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5
1. Einleitung
„Aus der Werbung, aus Computerspielen und Filmen kommen sie uns kühl, glatt und
perfekt entgegen und sehen doch aus, als könne man in sie hineingreifen: dreidimensionale
Computergrafiken.“1
Mit der Erstellung solcher virtuellen Realitäten befasst sich diese Arbeit, speziell mit
der Integration realer Umgebungen in Rennsimulationen. Dies ist ein sehr umfangreiches
Unterfangen und sollte nicht überstürzt werden.
Die Bachelorarbeit erhebt den Anspruch, dem Leser einen Einblick zu geben, wie aus
einer realen Umgebung eine virtuelle Rennstrecke entsteht. Dem Leser wird dabei ein
Überblick über aktuelle Rennsimulationen gegeben und mit dem Vorgehensmodell eine Art Anleitung vorgestellt zu den notwendigen Schritten, ein solches Vorhaben auch
tatsächlich umzusetzen.
Dabei bezieht sich die Arbeit auf eine reales Beispiel, den Alemannenring in Singen, der
als Modifikation für die Rennsimulation rFactor entwickelt wird.
Der Alemannenring ist eine Stadtstrecke in Singen. Genauer gesagt ist er die südlichste
Rennstrecke Deutschlands, die in den Jahren 1991 bis 19952 von diversen Rennserien wie
z.B. der DTM genutzt wurde. Dabei wurde das Industriegebiet von Singen für jeweils
ein Wochenende zu einer Rennstrecke umfunkioniert und alle notwendigen Vorkehrungen
getroffen, um einen reibungslosen Veranstaltungsablauf sowohl für die Stadt Singen als
auch die Rennserie zu garantieren.
Aufbau der Arbeit
Im ersten Kapitel werden die Begriffe Rennsimulation und Modifikation näher untersucht. Zudem wird die Software besprochen, die für die Erstellung einer virtuellen Rennstrecke notwendig ist.
1
2
Häßler, U.: 3D-Imaging
vgl. http://alemannenring.de/info/index.html
6
1. Einleitung
Es folgt das Kapitel Vorgehensmodell, in welchem der Weg von der Idee bis zur fertigen
Rennstrecke in einer Rennsimulation beschrieben wird. Dabei beginnt das Kapitel mit
der Auswahl der realen Umgebung und führt über mehrere Zwischenschritte bis zur
Entwicklung einer virtuellen Rennstrecke, auf welcher Rennveranstaltungen abgehalten
werden können.
Im Anschluss wird dem Leser ein Überblick über aktuelle Rennsimulationen gegeben und
selbige gegeneinander abgegrenzt. Dies soll den Entscheidungsprozess für eine Simulation
vereinfachen. Überdies werden die Beweggründe des Verfassers erläutert, gerade rFactor
für die Integration des Alemannenrings zu verwenden. Am Ende des Kapitels wird die
für das Alemannenringprojekt verwendete Software vorgestellt.
Es folgen die 3 Kapitel Modellierung, Materialien und Filestruktur. Diese beziehen sich
auf die Konvertierung von der realen Umgebung in die virtuellen Realität der Rennsimulation. Dabei wird die sukzessiv steigende Kopplung zwischen den Entwicklungsschritten
und der gewählten Rennsimulation rFactor deutlich.
Im Kapitel Modellierung werden Methoden zur Streckenmodellierung vorgestellt und die
Entstehung eines Gebäudes des Alemannenrings erläutert.
Folgend findet sich das Kapitel Materialien, in welchem die Funktion des Materialeditors (gMotor-Material) näher beschrieben. Des Weiteren wird in diesem Kapitel auf die
Verwendung von Texturen und Shader eingegangen.
Im Anschluss wird die Filestruktur einer Rennsimulation exemplarisch an der Kombination von Alemannenring und rFactor beschrieben und die notwendigen Files dargelegt,
welche für die Funktion der Rennstrecke unabdingbar sind.
Nach einigen abschließenden Bemerkungen endet die Arbeit mit dem Anhang und dem
zugehörigen Literaturverzeichnis.
7
2. Grundlagen
Der Alemannenring ist eine Modifikation für eine Rennsimulation. Zum besseren Verständnis werden folgenden Kapitel diese beiden Begriffe näher erläutert. Danach wird
die Software beschrieben, die für eine solches Modifikation notwendig ist.
2.1. Rennsimulation
„Eine Rennsimulation ist ein Computerspiel des Typs Rennspiel, bei dem der Spieler
in der Rolle einer der wetteifernden Fahrer ein möglichst wirklichkeitsgetreu simuliertes
Fortbewegungsmittel zum Sieg steuern muss.“1
Beginnend mit Arcade-Simulatoren hat diese Spielegattung einen weiten Weg hinter sich.
Zur Veranschaulichung des Realitätsgrades heutiger Simulationen sollen zwei Beispiele
dienen.
Professionelle Rennfahrer trainieren mittlerweile nicht mehr nur real, sondern auch mit
Hilfe qualitativ hochwertiger Rennsimulationen. Weiterhin finden sich vor allem bei iRacing, dem aktuell hochwertigsten Produkt des Genres bzgl. der Fahrphysik, mitunter
sogar (ehemalige) Formel 1 oder Nascar Fahrer auf den Spieleservern.
Der entgegengesetzte Weg existiert ebenso. Es gab schon diverse Veranstaltungsserien
im Rahmen von Rennsimulationen, bei denen die Erstplatzierten zu einer Fahrersichtung
in einem realen Rennwagen eingeladen wurden. Dort mussten sie ihr Können bei realen
Bedingungen unter Beweis stellen.
Ein Überblick über aktuelle Rennsimulationen wird in Kapitel 4 gegeben. Diese sind
mittlerweile so ausgereift, dass sie beinahe zwingend mit Peripheriegeräten (Lenkrad
und Pedale) zu spielen sind. Ohne selbige ist die Kontrolle über das Fahrzeug nicht im
notwendigen Maße vorhanden.
1
http://de.wikipedia.org/wiki/Rennsimulation
8
2. Grundlagen
2.2. Modifikation
„Eine Mod ... ist eine üblicherweise kostenlose, meist von Hobby- oder selten auch beruflichen Spieleentwicklern erstellte Erweiterung bzw. Veränderung eines bereits veröffentlichten Computerspiels.“2
Dabei gibt es bei Mod´s unterschiedliche Ausschweifungen. Kleinere Veränderungen am
Spiel können darin bestehen, dass einzelne 3D-Modelle oder Texturen ausgetauscht oder
überarbeitet werden, um das Erscheinungsbild des Spiels zu verändern.
Am anderen Ende der Möglichkeiten stehen sogenannte „Total Conversions (engl. für
‚vollständige Umwandlung‘). (Sie) modifizieren das Spiel völlig. Es bleibt lediglich die
Spiel-Engine erhalten.“ Kennzeichnend für Total Conversions sind oft „Veränderungen im
grundlegenden Spielprinzip oder beispielsweise die Implementierung eines völlig neuen
Szenarios.“3
Bei einigen Spielen wird schon in der Entwicklungsphase eines Spiels darauf geachtet,
dass selbiges leicht modbar ist. Dies kann geschehen, indem weit verbreitete Dateiformate Verwendung finden oder das Spiel so gestaltet wird, dass es leicht erweiterbar ist.
Für ein Vorhaben wie die Integration einer Rennstrecke in eine Rennsimulation ist letzteres ein wichtiger Aspekt.
2.3. Notwendige Software
Für die Entwicklung einer Rennstrecke für eine bestimme Rennsimulation wird Software
in folgenden Bereichen benötigt. 4
Der erste Bereich ist die Modellierungssoftware. Mit ihrer Hilfe werden das 3d-Modell
der Strecke und die Umgebungsobjekte erstellt. Gerade das Streckenmodell ist für eine Rennsimulation entscheidend, da sich auf jenem der Hauptteil des Rennens abspielt.
Aus diesem Grunde ist der professionellen Streckenerstellung ein extra Kapitel gewidmet
(siehe Kapitel 5.1). Die entsprechende Software sollte Funktionen bereitstellen, die einen
solchen Streckenentwurf ermöglichen, da sie sonst für ein derartiges Vorhaben schlicht
ungeeignet ist.
Darüber hinaus muss die Software über einen Materialeditor verfügen und die fertigen
2
http://de.wikipedia.org/wiki/Mod_(Computerspiel)
http://de.wikipedia.org/wiki/Mod_(Computerspiel)
4
Der Besitz eines Texteditors und der entsprechenden Simulation wird vorausgesetzt.
3
9
2. Grundlagen
Modelle im von der Simulation benötigten Dateiformat exportieren können oder zumindest über Umwege die Möglichkeit geben, die 3d-Dateien in das besagte Format zu
konvertieren.
Der zweite Bereich ist eine Software zur digitalen Bildbearbeitung. Die Auswahl dieser
ist nicht so kritisch wie die der Modellierungssoftware.
Wichtigster Punkt ist, dass die Software die spielinternen Grafikformate unterstützt.
Des Weiteren wird die Bildbearbeitungssoftware vorrangig dafür benötigt, um aus realen
Aufnahmen Texturen zu erstellen und diese weiterzuverarbeiten. Darüber hinaus müssen
mit ihr bestehende Texturen verändert werden können, um das Gesamtbild der Strecke
harmonisch gestalten zu können.
Der dritte Bereich beschreibt spielspezifische Software. Je nach gewählter Rennsimulation (siehe Kapitel 4) wird zusätzliche Software benötigt, beispielsweise um die KI-Linien
zu erstellen oder Kameras auf der Strecke zu platzieren. Des weiteren kann es vorkommen, dass die Entwickler nicht-standardisierte Dateiformate verwenden, für dessen
Interpretation und Änderung entsprechende Tools oder Plugins notwendig sind. Diese
Art von Software lässt sich nicht verallgemeinern.
Auf speziell für rFactor entwickelte Tools wird in Kapitel 4.4.1 eingegangen.
10
3. Vorgehensmodell
In diesem Kapitel wird der Weg von der realen Umgebung zu einer virtuellen Rennstrecke in mehrere Entwicklungsschritte eingeteilt. Dabei empfiehlt es sich, die dargestellte
Schrittfolge einzuhalten, da die Entwicklungsschritte chronoligisch sortiert sind und teilweise aufeinander aufbauen. An dieser Stelle ist auf den Anhang A.1 zu verweisen. Dort
findet sich eine E-Mail, in der ein Profi bzgl. des Themas Streckenerstellung einige zentrale Fragen beantwortet und auf seine eigene Vorgehensweise eingeht.
3.1. Auswahl realer Umgebung
Zu Beginn muss die Entscheidung gefällt werden, welche reale Umgebung virtuell umgesetzt werden soll. Dabei sind der Kreativität der Entwickler keine Grenzen gesetzt.
Jegliche Umgebung, die in der Realität für Rennen genutzt werden könnte, kann auch
Referenz für eine virtuelle Rennstrecke sein.
Im Regelfall werden reale Rennstrecken nachgebildet oder auch ehemalige Strecken wieder zum Leben erweckt. Letzteres ist auch beim Alemannenring der Fall. Ebenso möglich
ist es natürlich, aus einer normalen Straßenumgebung eine Rennstrecke zu erstellen oder
einen Waldabschnitt zu einer Rally-Etappe umzugestalten.
Diese Entscheidung sollte nicht überstürzt werden, da der komplette folgende Entwicklungsprozess von ihr abhängig ist. Sofern die geplante Umgebung noch nie für reale
Rennen genutzt wurde, sollte auch der geplante Streckenverlauf möglichst frühzeitig
feststehen, um einer Fehlentwicklung vorzubeugen.
3.2. Suche nach Referenzen
Ist die gewünschte Umgebung gewählt, folgt als nächster Schritt die Suche nach Referenzen. An dieser Stelle sollte sich der Entwickler auch Gedanken darüber machen, wie
11
3. Vorgehensmodell
detailliert die virtuelle Strecke werden soll, da von dieser Entscheidung die Anzahl der
notwendigen Referenzen abhängt.
Referenzen können Fotos, Videos, GPS-Daten oder auch Karten der Strecke sein. Dabei
variiert deren Anzahl und Verfügbarkeit je nach Bekanntheitsgrad der Strecke. Für sich
im Betrieb befindende Strecken gestaltet sich die Suche nach Referenzen am Einfachsten,
für ehemalige Rennstrecken schon schwieriger und noch komplizierter wird es, soll eine
noch nie für Rennen verwendete Strecke virtuell erschaffen werden.
Gerade an letzterem Fall ist zu erkennen, dass eine örtliche Nähe der Entwickler zur
gewählten Umgebung große Vorteile haben kann.
Hauptquelle für Referenzmaterial ist das Internet. Viele Rennstrecken besitzen eine eigene Webseite, auf der viele Informationen und auch Bilder der Strecke zu finden sind.
Darüber hinaus findet sich auch auf Webseiten diverser Rennveranstaltungen oder mit
Hilfe von Suchmaschinen genügend Bildmaterial.
Ein weiterer vielversprechender Anlaufpunkt sind Foren. Speziell für historische Rennstrecken finden sich dort oft Liebhaber, die Fotos oder gar Videos aus vergangenen Zeiten
besitzen und zur Verfügung stellen können.
Mit Hilfe von Karten der Strecke (z.B. Google Earth) kann der Kurvenverlauf aus der
Draufsicht nachverfolgt werden. Zudem wird ein Überblick über die Beschaffenheit der
Streckenumgebung gegeben und je nach Größe und Qualität der Karten wird sogar eine
variierende Streckenbreite ersichtlich.
Videos gliedern sich in zwei Kategorien, zum einen sind dies Onboardvideos, die aus
dem Auto heraus gefilmt werden und zum anderen Videos von außerhalb, z.B. den
TV-Kameras bei Fernsehübertragungen realer Rennen. Gerade Onboardvideos sind ein
probates Mittel, um die Steigungen der Strecke einzufangen und auch Bodenwellen zu
erkennen.
Videos von Außen eignen sich speziell dafür, die Umgebung der Strecke nachbilden zu
können.
Eine Mischung aus On- und Offboardvideos ermöglicht es dem Entwickler, die unmittelbare Fahrbahnumgebung zu ergründen wie z.b. die Beschaffenheit und Lage der Leitplanken, Reifenstapel, Curbs und Auslaufzonen.
Oft können Fotos auch dazu verwendet werden, die umgebenden Streckengebäude nachzubilden, wenn die Proportionen selbiger aus ihnen ersichtlich werden. Gerade bei örtlicher Nähe der Entwickler können auch Fotos der Strecke gemacht werden, die zur
Erstellung von Texturen verwendet werden können.
12
3. Vorgehensmodell
Speziell beim Alemannenring existieren verschiedene Arten von Referenzen. Ein Mitarbeiter des Projektes wohnt direkt in Singen und kann somit aktuelle Fotos der Gebäude
und des Geländes machen. Des weiteren gibt es mehrere große Karten (Größe A0), u.a.
mit einem Leitplankenplan (mit Höhenmarkierungen) und einem Satellitenbild der Strecke. Darüber hinaus besitzt das Modding-Team Aufnahmen der Fernsehübertragungen
aus den Jahren von 1991 bis 1994 sowie über 100 Fotos aus damaliger Zeit. Mit Hilfe
von OnBoard Videos und besagten Höhenmarkierungen können sowohl die Steigungen
als auch Bodenwellen auf der Straße nachgebildet werden.
3.3. Auswahl der Rennsimulation/Software
Wenn genug Referenzmaterial zur Verfügung steht, um die Strecke und Umgebung virtuell nachzubilden, sollte sich für die Rennsimulation entschieden werden, in welche die
Strecke integriert werden soll.
Diese Entscheidung sollte gerade an dieser Stelle erfolgen, weil folgende Entwicklungsschritte eine zunehmend stärkere Kopplung an die gewählte Simulation mit sich bringen,
während vorangegangene unabhängig von der gewählten Rennsimulation waren.
Aufgrund der Komplexität und enormen Wichtigkeit dieses Entwicklungsschrittes ist
ihm ein eigenes Kapitel gewidmet. (siehe Kapitel 4)
3.3.1. Vertraut machen mit gewählter Simulation
In diesem Schritt wird die gewählte Simulation im Hinblick auf die Entwicklung der
Modifikation näher erforscht. Dabei spielen folgende Fragen für den Entwickler eine
zentrale Rolle:
• Wie ist die Filestruktur aufgebaut?
• Welche Dateiformate für 3d-Objekte und Texturen sind erlaubt?
• Welche Tools oder Plugins gibt es, die den Prozess der Integration von Drittinhalten unterstützen?
• Welche Konventionen seitens der Engine gibt es, die bei der Umsetzung realer
Inhalte (siehe 3.4) beachtet werden müssen.1
1
z.B. Wie werden unterschiedliche Untergründe implementiert? oder Existieren Restriktionen bzgl. des
Polycounts von Objekten?
13
3. Vorgehensmodell
• Welche vorhandenen Dateien müssen ggf. verändert werden, damit die neue Strecke
erkannt von der Simulation als solche wird.
Für diese und weitere Informationen sind an dieser Stelle wiederum Modding-Foren oder
Tutorials eine gute Anlaufstelle zur Aneignung des notwendigen Wissens. Sofern für die
gewählte Rennsimulation schon Strecken von Drittanbietern existieren, bietet es sich an,
eine solche zu beschaffen und genauer zu inspizieren, um einen Einblick zu bekommen,
welche Dateien und Ordner für die Eigenentwicklung notwendig sind.
3.3.2. Auswahl der Software
Welche Bereiche von Software für das Projekt virtuelle Rennstrecke abgedeckt werden
müssen und welche Besonderheiten dabei zu beachten sind, wurde schon in Kapitel 2.3
erläutert.
Sofern die bisherigen Entwicklungsschritte abgearbeitet wurden, sind an dieser Stelle
die nachzubildende Umgebung festgelegt und alle notwendigen Referenzen vorhanden.
Weiterhin sind die Eigenheiten der gewählten Simulation, insbesondere hinsichtlich der
Dateiformate und verfügbaren Tools bzw. Plugins, bekannt.
Demnach sind alle Voraussetzungen erfüllt, um die Entwicklungssoftware auszuwählen,
mit deren Hilfe die reale Umgebung in eine virtuelle Realität überführt wird.
3.4. Umsetzung realer Inhalte
Dies ist der aufwendigste Entwicklungsschritt. Von der gewählten Umgebung muss ein
komplettes virtuelles Abbild geschaffen werden. Dabei untergliedert sich die Integration
jedes einzelnen Objektes in 3 Schritte:
1. Modellierung des 3d-Objektes.
2. Zuweisung von Materialien.
3. Integration in die Simulation.
Auf die Modellierung bzw. Zuweisung von Materialien wird den Kapiteln 5 bzw. 6 eingegangen. Die Integration variiert je nach Simulation und wird daher in dieser Arbeit
nicht näher erläutert.
14
3. Vorgehensmodell
Es empfiehlt sich, diese drei aufgelisteten Schritte als eine Einheit zu verstehen. Jedes
Objekt sollte vom Beginn der Modellierung bis ins Spiel gebracht werden, bevor die
Erstellung des nächsten Objektes begonnen wird. Der komplette Prozess ist am Beispiel
einer Gebäudemodellierung in Kapitel 5.2.1 aufgezeigt. Durch eine solches Vorgehen
können potenzielle Fehler bei der Entwicklung schneller gefunden werden. Ferner ist der
Motivationsfaktor, die Objekte direkt in der Simulation betrachten zu können, nicht zu
unterschätzen.
3.5. Der Weg von einer virtuellen Umgebung zur
Rennstrecke
An dieser Stelle der Entwicklung sind alle Objekte in die Simulation eingefügt und mit
Materialien versehen. Die Strecke ist befahrbar und optisch gesehen fertig.
Jedoch ist die Strecke noch nicht für den Rennbetrieb geeignet, was allerdings das Endziel
der Entwicklung ist.
Um diesen Ziel zu erreichen, müssen die folgenden Punkte abgearbeitet werden.
Definition der Fahrbahn Der Spielengine müssen Informationen darüber bereitgestellt werden, wo sich die erlaubte Fahrbahn und die Boxengasse befinden, auf
welcher die Fahrer ihr Rennen zu absolvieren haben.
Kameras Durch Kameras wird das Renngeschehen ins rechte Licht gerückt. Wie bei
Fernsehübertragungen können auch virtuelle Rennen über TV-Kameras von Außen
mitverfolgt werden.
KI-Linie Die meisten Rennsimulationen bieten die Möglichkeit, gegen virtuelle Konkurrenten anzutreten. Für ein solches Feature müssen KI-Linien erstellt werden,
damit die Fahrweise der künstlichen Intelligenz berechnet werden kann.
Zeitnahme Ohne Zeitnahme macht ein virtueller Rennbetrieb keinen Sinn. Daher müssen der Strecke sogenannte „Checkpoints“ zugefügt werden (siehe Kapitel 5.1.3).
Beleuchtung Grundsätzlich reicht ein Licht, um die virtuelle Umgebung auszuleuchten. Dieses simuliert eine virtuelle Sonne. Falls die Strecke jedoch längere Unterführungen bzw. Tunnel besitzt oder die Rennsimulation Nachtfahrten unterstützt,
so müssen weitere Lichter auf der Strecke platziert und in die Simulation integriert
werden.
15
3. Vorgehensmodell
Streckenspezifische Dateien Dieser Punkt beschreibt spielspezifische Änderungen,
die notwendig sind, damit die Simulation die Strecke erkennt und letztere ausführbar wird.
Sind diese Punkte abgearbeitet, sollte noch ein sogenannter Beta-Test erfolgen. Sind die
ggf. aufgetretenen Fehler behoben, so ist die Strecke als fertig zu bezeichnen und ihrem
Release steht nichts mehr im Wege.
16
4. Auswahl der Rennsimulation
Die Entscheidung für eine Rennsimulation ist ein sehr wichtiger Schritt für die Integration einer realen Umgebung. Dieses Kapitel soll einen Überblick über die verschiedenen
Simulationen geben und sie gegeneinander abgrenzen, um eben diesen Entscheidungsprozess zu unterstützen.
4.1. Überblick über Rennsimulationen
Die Tabelle 4.1 zeigt eine Auswahl der wichtigsten Rennsimulationen des letzten Jahrzehnts. Dabei beschränkt sie sich auf Spiele, die für den PC erschienen sind. Der in der
Tabelle vergebene Index bezieht sich auf die folgende Matrix. Dabei wurden alle SimbinSimulationen zu einem Index zusammengefasst, da sie auf der selben Spiele-Engine basieren und sich somit in Punkto Modbarkeit und Simulationsgrad nicht unterscheiden.
Name
F1 Challenge 99-02
Richard Burns Rallye
Live for Speed S2
GT Legends
rFactor
GTR2
Race07
GTR Evolution
iRacing
Colin McRae: DiRT 2
Need for Speed: Shift
Entwicklerteam
Image Space Incorporated
Warthog
3 Entwickler
Simbin
Image Space Incorporated
Simbin
Simbin
Simbin
iR Motorsport Simulations
Codemasters
Electronic Arts
Erscheinungsjahr
2002
2004
2005
2005
2005
2006
2007
2008
2008
2009
2009
Tabelle 4.1.: aktuelle Rennsimulationen
17
Index
1
2
3
4
5
4
4
4
7
6
8
4. Auswahl der Rennsimulation
Abbildung 4.1.: Matrix zur Einordnung der Simulationen
Zur Erleichterung einer solchen Entscheidung soll die Matrix in Abbildung 4.1 dienen.
Dabei werden die verschiedenen Simulationen in den Aspekten Simulationsgrad und
Modbarkeit abgegrenzt.
Die Abbildung 4.1 gibt eine Übersicht der in Tabelle 4.11 aufgeführten Rennsimulationen.
Die Einordnung findet in den Aspekten Simulationsgrad und Modbarkeit statt. Die roten
Kreise (Index zwei und sechs) weisen darauf hin, dass es sich bei diesen Simulationen
um Rallye-Simulationen handelt, während der Fokus der restlichen Simulationen auf dem
Verhalten von Rennwagen auf Asphalt liegt. Die horizontale, rot gestrichelte Trennlinie
teilt den Bereich der Modbarkeit in zwei Hälften. Die Simulationen in der oberen Hälfte
eignen sich für die Integration von Rennstrecken.
Klar ersichtlich ist iRacing die Scene-Referenz bzgl. des Simulationsgrades, während
rFactor die Referenz für die Modbarkeit ist.
4.2. Entscheidungskriterien
Zur weiteren Vereinfachung der Entscheidungsfindung bzgl. der Rennsimulation sollen
die in Tabelle 4.1 genannten Simulationen hinsichtlich verschiedener Kriterien näher
beschrieben werden.
Modbarkeit
Bei der Modbarkeit gibt es große Unterschiede bei den verschienen Simulationen. Sie
1
Tabelle erstellt mit Hilfe von Wikipedia, vgl. http://de.wikipedia.org/wiki/Rennsimulation
18
4. Auswahl der Rennsimulation
erfüllen ein Spektrum von iRacing bis rFactor. Bei iRacing beschränken sich die möglichen Modifikationen auf die Änderung der Fahrzeugtexturen. Es folgen Colin McRae
und Need for Speed, bei denen zudem Grafik- und Kameramods existieren. Für Live for
Speed existieren viele verschiedene Modifikationen wie z.B. Tools, welche die Leistungsdaten der Fahrzeuge verändern. Ferner existieren sogar in das Spiel integrierte Fahrzeuge
von Drittanbietern, welche jedoch nicht legal sind.
Interessant wird die Modbarkeit bei Richard Burns Rallye. Für dieses Spiel lassen sich
sowohl neue Fahrzeuge als auch Strecken erstellen, ebenso für die Simbin-Ableger, F1
Challenge und rFactor. Letzteres ist die Referenzsimulation bzgl. der Modbarkeit. Schon
in der Entwicklung wurde bei rFactor großer Wert auf gute Modbarkeit gelegt und
so existieren direkt von Image Space Incorporated entwickelte Tools und Plugins zur
Unterstützung von Modvorhaben.
Simulationsgrad
Der Simulationsgrad beschreibt die Realitätsnähe einer Rennsimulation im Vergleich
zur Fahrt in realen Rennwagen. Dabei bezieht Realitätsnähe sich hauptsächlich auf das
Fahrverhalten der Fahrzeuge im Spiel. Dieses basiert wiederum zu einem Großteil auf
dem Reifenmodell, da die wirkenden Kräfte bei Rennsimulationen mittels der Reifen
übertragen werden.
Den geringsten Simulationsgrad weisen Colin McRace und Need for Speed auf mit einer
beinahe arcadelastigen Fahrphysik, während iRacing die Königsklasse in diesem Segment darstellt. So werden dort Abnutzung, Temperatur und auch die Verschmutzung
der Reifen simuliert. Weiterhin wird die Aerodynamik in iRacing so genau berechnet,
dass selbst abfallende Fahrzeugteile Einfluss auf das Fahrverhalten haben durch eine
veränderte Luftströmung, ebenso wie eine beschädigte Aufhängung oder Bremsplatten.
Die nicht genannten Simulationen gliedern sich zwischen diesem beiden Extremen ein
(siehe Abbildung 4.1).
Untergrund
Dieses Kriterium bezieht sich auf Bodenbelag, der in der Rennsimulation hauptsächlich
befahren wird. Richard Burns Rallye und Colin McRace: Dirt 2 verstehen sich dabei als
Rallye-Simulationen und nehmen somit eine Sonderstellung in der Auflistung ein. Live
for Speed enthält zwar Strecken, die teilweise aus Asphalt und teilweise aus Schotter
bestehen, jedoch liegt der Fokus nicht auf dem Rallye-Anteil. Die restlichen Simulationen
enthalten keine Rallye-Elemente.
19
4. Auswahl der Rennsimulation
4.3. Entscheidung für rFactor
Im folgenden Kapitel wird erläutert, warum sich der Verfasser für rFactor entschieden
hat.
Bei dem Projekt Alemannenring soll eine temporäre Stadtstrecke in eine Rennsimulation
integriert werden. Aus der Abbildung 4.1 und dem zugehörigen Text im vorigen Kapitel
wird ersichtlich, dass nur noch rFactor, F1 Challenge, Richard Burns Rallye und die
Simbin-Ableger für ein solches vorhaben geeignet sind.
Richard Burns Rallye versteht seinem Namen entsprechend als Rallye-Simulation und
fällt somit aus der Wahl, da der Alemannenring als Stadtstrecke komplett asphaltiert
ist. F1 Challenge, ebenso wie rFactor von ISI entwickelt, ist im Vergleich zu rFactor
veraltet und bietet keinerlei Features, die über das Angebot von rFactor hinausgingen.
Somit verbleiben nur noch rFactor und die Simbin-Ableger. Der Simulationsgrad beider
Endkandidaten ist ähnlich, jedoch wurde bei der Entwicklung von rFactor viel mehr Wert
darauf gelegt, dass die Simulation mit Inhalten von Drittanbietern erweitert werden kann
und so existiert bis dato keine Simulation, die für Modder so zugänglich ist wie rfactor.
Aus diesem und den weiteren aufgeführten Gründen hat der Verfasser sich für rFactor
entschieden.
4.4. verwendete Software
Nachdem die Entscheidung für eine Rennsimulation gefallen ist, geht dieses Kapitel auf
die von den rFactor-Entwicklern erstellten Tools und Plugins ein. Ferner werden die
Softwareprodukte für die Bereiche 1 und 2 (siehe Kapitel 2.3) gewählt und die Entscheidungen begründet.
4.4.1. rFactor-spezifische Tools und Plugins
Die Modding-Tools, die für die Streckenimplementierung nach rFactor notwendig sind,
werden von ISI bereitgestellt. Abgesehen von den .dds-Plugins finden sie sich allesamt
in der Developer´s Corner der offiziellen Homepage der Rennsimulation. 2
rFactor Max Plugins Die Max Plugins stellen die Schnittstelle zwischen der Modellierungssoftware 3dsmax und der Spielengine dar.
2
http://rfactor.net/developers
20
4. Auswahl der Rennsimulation
Nach erfolgreicher Installation können in 3dsMax sogenannte gMotor-Materialien verwendet werden. Dies sind auch die Materialien, die im Spiel verwendet werden. Zudem
ist der .gmt-Exporter ein umfangreiches Werkzeug, das einen direkten .gmt-Export aus
3dsMax heraus ermöglicht. Somit erweist sich die spätere Konvertierung der Dateien aus
3dsMax in die Spielumgebung als denkbar einfach.
dds-plugin Die .dds Plugins sind notwendig, damit sowohl 3dsmax als auch Photoshop
die entsprechenden Dateien dargestellt und bearbeitet werden können.3
gMotor 2.0 MAS File Utility „The gMotor 2.0 MAS utility is used to create MAS
archive files for use in gMotor 2.0 applications only. A MAS file is very similar to other
well-known types of compressed archive files, and contains additional information specific
to a gMotor application.4 “
Weitere Möglichkeiten, die dieses Tool bietet sind die Erstellung von Mip Maps für .dds
Dateien und die Konvertierung von Standard-Bilddateien in das .dds Format.
rFactor AIWCAM Editor Der AIWCAM Editor wird benötigt, um die Wegpunkte
für die Strecke (.aiw) zu erstellen und die Kameras auf der Strecke (.cam) zu platzieren.
Eine Bearbeitung beider Dateien direkt im Quellcode ist zwar möglich, jedoch ist dem
abzuraten, da z.B. eine .aiw-Datei je nach Strecke rund 20000 Zeilen hat.
Vorraussetzung für die Funktion des Editors ist eine installierte rFactor Version, da
dieser direkt auf die Spielinhalte von rFactor zugreift.
4.4.2. Modellierung - 3dsMax
Speziell für die Modellierung von Rennstrecken muss der 3d-Editor Funktionen bereitstellen, welche die Entwicklung des Streckenentwurfs komfortabel und professionell
ablaufen lassen. Genau an diesem Punkt scheitern die meisten OpenSource-Produkte
oder andere 3d-Editoren. 3dsMax, eine „leistungsstarke, integrierte Lösung für 3DModellierung, Animation, und 3D-Visualisierung5 “, deckt diesen Bereich mit dem Modifikator FFD-Modelling und der Loft-Extrusion (siehe Kapitel 5.1) ab.
Auch bei der Erstellung jeglicher Umgebungsobjekte, von Leitplanken über Gebäude,
Bäume und Vegetation im allgemeinen lässt der Editor von 3dsMax keine Wünsche
offen.
3
Zu finden unter http://developer.nvidia.com/object/nv_texture_tools.html
Zitat aus gMotor 2.0 MAS Utility help
5
http://www.autodesk.de/adsk/servlet/pc/index?id=14642267&siteID=403786 15.08.10
4
21
4. Auswahl der Rennsimulation
Überdies sind die von ISI6 zur Verfügung gestellten Modding-Tools extra für verschiedene
3dsMax-Distributionen verfügbar, wodurch die Überführung der 3d-Objekte vom Editor
zu tatsächlichen Spieleinhalten sehr komfortabel und ohne Umwege zu bewerkstelligen
ist.
Aus diesen Gründen wurde sich bei der Modellierungssoftware für 3dsMax entschieden.
4.4.3. Bildbearbeitung - Photoshop
In dem Bereich der Bildbearbeitung ist die Entscheidung auf Photoshop gefallen. Dieses
„setzt neue Maßstäbe für die digitale Bildbearbeitung und kreative Fotogestaltung. Die
Software bietet (weiterhin) eine Fülle an Malpinseln, Auswahl- und Korrekturwerkzeugen.“7
Dabei ist die Auswahl der Bildbearbeitungssoftware nicht sonderlich kritisch 8 . Photoshop wurde gewählt, weil der Verfasser schon Erfahrungen mit dem Programm sammeln
konnte und es zudem einige nütliche Features aufweist.
Mit Hilfe der Funktion „perspektivisch Bearbeiten“ des Freistellungswerkzeuges können
auf einfach Art und Weise Fotos entzerrt und später zur Erstellung von Texturen verwendet werden.
Ein weiteres nützliches Tool ist der Filter Verschiebungseffekt. Mit seiner Hilfe lassen
sich auf schnelle, einfache Weise kachelbare Texturen erstellen, welche für Häuserfassaden oder die Fahrbahn verwendet werden.
Auch für die Bearbeitung bestehender Texturen, seien es nun Angleichungen des Kontrastes, Farbkorrekturen oder sonstige Modifikationen erweist sich Photoshop als gut
geeignet.
6
Abk. für Image Space Incorporated, Entwickler von rFactor
http://www.adobe.com/de/products/photoshop/photoshop/whatisphotoshop/
8
Einzige Vorraussetzung: Unterstützung des .dds-Formats
7
22
5. Modellierung
Dieses Kapitel beschreibt die geometrische Modellierung der Objekte, welche in der
Simulation auftreten sollen.
Für Rennsimulationen ist es absolut essenziell, dass dem Nutzer ein realistisches Fahrgefühl vermittelt wird. Um dieses Ziel erreichen zu können, muss ein größeres Augenmerk
auf die Ausmodellierung des befahrbaren Untergrundes gelegt werden als auf die Umgebung, die eine rein optische Funktion besitzt.
Zur besseren Unterscheidung wird in dieser Arbeit die Modellierung in zwei Teilbereiche
gegliedert, die Modellierung der Strecke und die Modellierung der Umgebung.
Dabei soll der Bereich der Strecke so definiert sein, dass darunter alle Objekte verstanden
werden, mit denen das Fahrzeug in Kontakt tritt. Zum einen ist dies der Untergrund
(Straße, Curbs, Gras etc.), bei dem der Kontakt über die Reifen der Fahrzeuge hergestellt
wird. Zum anderen sind dies Streckenbegrenzungen (Leitplanken, Mauern, Fangzäune
etc.), bei denen der Kontakt über Karosserieteile entsteht. Diese Unterteilung findet sich
auch in der Namensgebung der Materialien (siehe Kapitel 6.4) wieder.
Die Umgebung hingegen beinhaltet alle Streckenobjekte, die sich abseits der Streckenbegrenzung oder auch über der Strecke befinden, so dass die Fahrzeuge diese Streckenobjekte nicht berühren.
Im Idealfall ist die fertige entwickelte Rennumgebung so gestaltet, dass es dem Spieler, abgesehen von außerordentlichen Ereignissen, unmöglich ist, den Streckenbereich zu
verlassen.
5.1. Modellierung der Strecke
Für die Modellierung der Strecke gibt es verschiedene Möglichkeiten. Die Einfachste und
Schnellste ist es, einzelne Polygone zu erstellen und die entsprechenden angrenzenden
23
5. Modellierung
Vertices zu platzieren. Diese Methode ist jedoch für einen professionellen Streckenentwurf
nicht zielführend. Sobald eine Strecke Steigungen enthalten soll, wird es sogar nahezu
unmöglich, auf diese Weise vernünftige Ergebnisse zu erzielen.
Zwei ernsthafte Möglichkeiten, die Strecke zu modellieren, werden folgend vorgestellt.
5.1.1. FFD-Modelling
FFD steht für Free-Form Deformation, daher für die freie Verformung von Körpern.
Folgend wird die Funktionsweise des FFD-Modifikators speziell für die Modellierung von
Rennstrecken anhand der Bilderserie in Abbildung 5.1 erläutert.
Abbildung 5.1.: Bilderserie: Schritte beim FFD-Modelling
Zunächst wird eine lange Ebene mit 3 Breitensegmenten und beliebig vielen Längensegmenten erstellt. Dieses wird folgend in ein bearbeitbares Polygon umgewandelt, mit
Texturen belegt und gemappt. Part 1 der Abbildung zeigt eine leicht modifizierte Version
dieser Ebene.
Im nächsten Schritt wird der FFD(Quad)-Modifier auf die Ebene angewendet und in dem
Rollout FFD-Parameter die Punktzahlen der FFD-Box eingestellt. In dem vorgestellten
24
5. Modellierung
Beispiel sind die Punktzahlen auf 20x4x2 Punkte eingestellt. Das Ergebnis ist in Part 2
der Abbildung zu sehen.
Wenn das FFD-Gitter die Strecke umspannt, so kann diese mittels der Steuerpunkte der
FFD-Box beliebig im 3-dimensionalen Raum bewegt werden. Auf diese Weise werden
sowohl Steigungen der Strecke als auch der allgemeine Streckenverlauf erstellt. Selbst die
Auslaufzonen können in diesem Schritt schon vergrößert bzw. verkleinert werden, indem
schlicht nur die beiden äußeren Steuerpunkte verschoben werden. Zur Veränderung der
Streckenbreite werden analog dazu die inneren Steuerpunkte bearbeitet.
Ein mögliches Ergebnis ist in Part 3 bzw. Part 4 der Abbildung zu sehen. Bei Part 3
sieht man noch die FFD-Box (orange Striche), welche die Strecke umspannt, während in
Part 4 das mit Hilfe des FFD-Modellings erstellte Polygonnetz (rote Striche) kenntlich
gemacht wurde.
5.1.2. Loft-Extrusion
„Lofts bilden eine ausgefeilte Technik des 3d Studios, dreidimensionale Formen aus zweidimensionalen Umrissen zu entwickeln.1 “. Sie bestehen dabei aus 2 einfachen Splines, der
Kontur und dem Pfad.
Abbildung 5.2.: Konturspline mit Material-ID´s und Pfadspline
Die Abbildung 5.2 zeigt Kontur und einen Streckenpfad von ERS, einem anderen Rennstreckenprojekt des Verfassers. Linksseitig findet sich die Kontur mit vergebenen Material ID´s und auf der rechten Seite sieht man den nachgebildeten Streckenverlauf.
„Der Umriß (Kontur) wird entlang eines Pfades in den Raum gezogen - und dieser Pfad
kann eine beliebige Form annehmen.2 “
Ein riesiger Vorteil der Loft-Extrusion ist, dass sowohl Pfad als auch Kontur bis auf kleine
Einschränkungen den kompletten Entwicklungsprozess über verändert werden können.
1
2
Häßler, U.: 3D-Imaging, S. 76
ebd.
25
5. Modellierung
So ist es denkbar einfach, die Strecke beliebig zu erweitern oder Streckenabschnitte zu
verändern.
Aufgrund der einfachen Erweiterbarkeit empfiehlt es sich, bei der Loft-Extrusion die
Kontur bis zum gewünschten Endzustand zu modifizieren, für den Pfad jedoch sehr klein
zu beginnen. Ein Kreis oder noch einfacher eine Gerade ist dabei völlig ausreichend. Im
nächsten Schritt sollte die Kontur genau über den Pfad gelegt werden, so dass bei der
weiteren Bearbeitung keine Fehler auftreten.
Folgend kann die Pfad-Spline nach Belieben modifiziert werden. Ein Hinzufügen bzw.
Löschen von Knotenpunkten ist dabei problemlos und die Veränderungen werden sofort
im Loft sichtbar.
Abbildung 5.3.: Rollout: Oberflächen- und Hauptextrusionsparameter (Loft)
Ist das gewünschte Ergebnis erzielt (im Idealfall der komplette Streckenverlauf), werden
im nächsten Schritt die Hauptextrusions- und Oberflächenparameter (siehe Abbildung
5.3 festgelegt. Die wichtigsten Funktionen sind in der Abbildung gekennzeichnet. Unter
(2) und (3) können die Pfad- bzw. Konturschritte eingestellt werden. Diese legen fest,
wie viele Polygone sich zwischen zwei Kontenpunkten der Splines befinden. Höhere Werte glätten zwar die Geometrie, resultieren jedoch auch in einer erhöhten Polygonzahl.
Unter Punkt (1) findet sich die wichtigste Funktion für das Mapping der Strecke. Die
Wiederholungen legen fest, wie oft die Textur entlang des Pfades gekachelt wird.
Die Vergabe der Material-ID´s erfolgt auf der Kontur-Spline. Dabei kann jedem Segment
der Spline eine eigene ID zugewiese werden..
26
5. Modellierung
Ein sehr interessanter Aspekt bei der Erstellung von Loft´s sind die Verformungsfunktionen. Speziell mittels der Dialogfenster Verdrehung und Skalierung lässt sich die Breite
und Neigung des Streckenlofts komfortabel anpassen.
Es ist ebenso möglich, diese Veränderungen mit Hilfe von Kontursplines zu erzielen.
Diese sind intuitiver als die Verformungsfunktionen zu bedienen und darüber hinaus
können mit ihrer Hilfe mitten im Loft die Material-ID´s verändert werden.
Ein mögliches Endergebnis der Loft-Extrusion zeigt die Abbildung 5.4. Auf der rechten
Seite ist ein Teil der gelofteten Rennstrecke ERS3 sichtbar. Bei genauerem Hinsehen
fallen weiße Kontursplines auf. Linksseitig finden sich diese Konturplines mit (1) bezeichnet wieder. Rot durchschimmernd sieht man das Drahtgittermodell, welches durch
die Loft-Extrusion erstellt wurde. Unter (2) erkennt man sehr schön, wie man mit Hilfe
der Kontursplines auch die Größe der Auslaufzonen schon im Loft ändern kann und bei
(3) beginnt und endet ein Curb-Abschnitt noch im Loft.
Abbildung 5.4.: Loft-Extrusion mit Kontursplines
Die Loft-Extrusion gibt dem Entwickler die Möglichkeit, eine fahrbare Streckenversion direkt in die Simulation zu integrieren, zu testen und ggf. Änderungen am Loft zu
vollziehen, bis er mit dem Ergebnis zufrieden ist.
3
ERS ist ein weiteres Rennstreckenprojekt des Verfassers. An ERS werden Stärken der Loft-Extrusion
deutlicher als beim Alemannenring, weshalb es in diesem Kapitel Verwendung findet.
27
5. Modellierung
Aufgrund der hohen Flexibilität der Loft-Extrusion, der vielen Möglichkeiten, der Genauigkeit und der Einfachheit nachträglicher Änderungen bevorzugt der Verfasser diese
Methode der professionellen Streckenerstellung.
Auch für den Alemannenring wurde die Loft-Extrusion in ähnlicher Weise verwendet.
5.1.3. Checkpoints
Rennstrecken haben im Regelfall eine Start-/Ziellinie und eine Boxengasse. Dabei gibt
es in der Boxengasse eine Geschwindigkeitsbegrenzung, die je nach Rennserie variieren
kann. Zudem werden Rennstrecken meist in mehrere Sektoren eingeteilt, um einen genaueren Überblick über das Renngeschehen geben zu können. Dieser Umstand wird in
rFactor durch sogenannte Checkpoints simuliert. Von diesen gibt es die fünf folgenden,
die jede Strecke enthalten muss, um eine korrekte Funktionalität zu gewährleisten:
xFINISH Die Start-/Ziellinie. Sie muss sowohl die Strecke kreuzen als auch die Boxengasse, so dass auch bei einer Boxendurchfahrt die Runde als solche gewertet
wird.
xSECTOR1 Linie erster Sektor. An dieser Stelle wird die erste Sektorzeit gemessen
und im Spiel angezeigt. Es beginnt Sektor Nr. 2.
xSECTOR2 Linie zweiter Sektor. Der letzte Sektor beginnt und entsprechende Zeiten
werden ermittelt.
xPITIN Boxeneingang. Ab diesem Polygon gilt das eingestellte Speedlimit für die Boxengasse. Weiterhin wird beim Überfahren die rFactor-Routine für einen Boxenstop ausgelöst.
xPITOUT Der Boxenausgang. Das Speedlimit ist aufgehoben und der Boxenstop gilt
als beendet.
Damit die Checkpoints funktionieren, gibt es einige Konventionen bei deren Implementierung. Sie müssen aus einem Objekt mit einem Polygon bestehen, welches mit einem
beliebigen Multi-Unterobjekt-Material versehen ist. Bei der Bezeichnung der Objekte
muss sich strikt an die oben aufgelisteten Bezeichner gehalten werden.
Des weiteren müssen in der .scn-Datei (siehe Kapitel 7.2) folgende Einträge gemacht
werden.
28
5. Modellierung
1
2
3
4
5
6
Instance=xFinish
{
Render=False
MeshFile=XFinish.gmt CollTarget=True HATTarget=False
Response=VEHICLE,TIMING
}
Der xFinish-Checkpoint für die Start-/Ziellinie ist somit im Spiel weder sichtbar (Render) noch ein Kollisionsobjekt (HATTarget). Durchfährt man den Checkpoint, wird dies
jedoch erkannt (CollTarget) und die Zeitnahme aktiviert (Response).
Analog funktionieren die anderen Checkpoints.
Für die Implementierung im Spiel ist es weiterhin ratsam, für die Start-/Ziellinie und die
Boxenein- und -ausfahrt auch noch tatsächlich sichtbare Markierungen auf der Strecke
zu platzieren, um dem Nutzer den Ort der Checkpoints zu veranschaulichen.
5.2. Modellierung der Umgebung
Als Umgebung sollen in dieser Arbeit alle Objekte angesehen werden, die sich hinter
der von der Strecke aus gesehen ersten Leitplanke befinden. Dies sollte dem Bereich
entsprechen, der von den Fahrzeugen nie befahren werden kann.
Speziell für den Alemannenring, einer Stadtstrecke besteht die Umgebung aus vielen verschiedenen Gebäuden, Bäumen, Stromleitungen etc. . Um einen hohen Immersionseffekt
zu erzielen, müssen eben diese Objekte auch im Spiel wiederzufinden sein.
5.2.1. Entstehung eines Hauses
Schematisch für die Erstellung aller Streckenobjekte soll eine Haus des Alemannenrings
dazu dienen, den Weg eines realen Objekts in die Simulation aufzuzeigen. Die zugehörige
Abbildung 5.5 wird in diesem Abschnitt näher erläutert.
Im ersten Schritt müssen Fotos vom realen Objekt erstellt werden. Ein solches findet sich
in Part 1 der Abbildung 5.5. Mit Hilfe von Fotos wird es dem Modellierer ermöglicht,
einen Eindruck über die verschiedenen Proportionen des Gebäudes zu gewinnen. Ist
zusätzlich ein Bild aus der Draufsicht vorhanden, können die Ausmaße des Gebäudes
sehr realitätsnah umgesetzt werden.
29
5. Modellierung
Abbildung 5.5.: Bilderserie: Die Entstehung eines Hauses
Sind genug Fotos vorhanden, so wird das 3d-Modell des Gebäudes erstellt. Dabei gibt
es keine richtige Variante, dies zu bewerkstelligen. Der Verfasser bedient sich für diesen
Vorgang entweder dem Boxmodelling oder dem Polygonmodelling.
Bei ersterem wird ein Quader erstellt, aus dem sukzessiv weitere Details herausgearbeitet
werden.
Beim Polygonmodelling beginnt der Prozess der Modellierung dem Namen entsprechend
mit einem Polygon, z.B. einer Gebäudewand. An dieses werden weitere Gebäudeteile
angefügt, bis der Vorgang der Modellierung abgeschlossen ist.
Dies ist für Part 2 und 3 der Abbildung 5.5 der Fall. Beide sind Render aus 3dsmax heraus. Dabei ist in Part 2 der untexturierte Rohbau des Gebäudes zu sehen. Im nächsten
Schritt müssen Texturen für das Gebäude erstellt werden, die dem Objekt bzw. den einzelnen Polygonen des Objektes zugewiesen werden. Danach folgt noch das Mapping, bei
dem definiert wird, wie die Textuen auf die Polygone „projeziert“ werden. Das Ergebnis
dieser Vorgänge ist in Part 3 zu sehen.
30
5. Modellierung
Im letzten Schritt muss das Gebäude noch ins Spiel integriert werden, um den Prozess
abzuschließen. Das fertige Gebäude in der Simulation ist in der Abbildung 5.5 Part 4 zu
sehen.
5.2.2. weitere Umgebungsobjekte
Analog zu dem oben beschriebenen Gebäude sollten auch alle weiteren Umgebungsobjekte umgesetzt werden, die auch im realen Vorbild existieren. Dies wird in vollem Umfang
jedoch kaum möglich sein, denn „ein grundlegendes Problem beim Streben nach völlig realistischen Bildern ist die Komplexität der realen Welt. (Reale Objekte) haben
viele Oberflächentexturen, subtile Farbabstufungen, Schatten, Spiegelungen und kleine
Unregelmäßigkeiten. ... Dies alles trägt zu einer realen optischen Erscheinung bei.“4
Bei der Umsetzung der realen Welt in eine virtuelle Realität müssen daher Kompromisse gemacht werden und gerade für eine Rennsimulation, bei welcher die Performance
eine wichtige Rolle spielt, muss ein vernünftiger Mittelweg zwischen der Reichhaltigkeit
umgesetzter Inhalte und der Framerate im Spiel gefunden werden.
Ein Beispiel für die Verfolgung dieses Performance-Gedankens stellen Bäume in Rennsimulationen dar. Bäume sind komplexe Strukturen und nur mit erheblichem (Polygon)Auwand realistisch umzusetzen.
Zur Vereinfachung werden bei Bäumen schlicht zwei Ebenen erstellt, die diagonal zueinander stehen und sich mittig treffen. Diesen wird ein zweiseitiges Material zugewiesen,
welches Baumtextur mit Alpha Kanal enthält, der für die Transparenz verantwortlich
ist. Eine andere Möglichkeit ist die Realisierung der Bäume als sogenannte Billboards,
die sich zur Kamera drehen.
Das dabei erzeugte Ergebnis ist nicht perfekt, aber für das Spielgefühl völlig ausreichend,
zumal die Bäume meist eine gewisse Entfernung zur Fahrbahn besitzen.
Für die Entwicklung einer virtuellen Rennstrecke ist es essenziell, dass wichtige Gebäude
und kennzeichnende Merkmale des realen Vorbilds in der Simulation wiederzufinden sind.
Auf übertriebene Genauigkeit kann bzw. muss verzichtet werden.
4
Foley, J. und weitere: Grundlagen der Computergrafik, S.481
31
6. Materialien
„Der Begriff des Materials ... beinhaltet alles, was die Oberflächenbeschaffenheit eines
Objektes ausmacht.
Eine Oberfläche kann hell leuchtend, fluoreszierend, durchscheinend, rauh, glatt oder
spiegelnd sein. Die Belegung Ihrer Objekte mit dem ‚richtigen‘ Material entscheidet
maßgeblich über die Qualität der Darstellung.“1
Demnach sind Materialien unabdingbar für die Erstellung von virtuellen Umgebungen.
In rFactor werden die Materialien dabei durch verschiedene Texturen erzeugt, die durch
verschiedene Shader (siehe 6.3) in Wechselwirkung treten. Die Texturen sind somit der
wichtigste Faktor für die Darstellung der Objekte im Spiel und werden im folgenden
näher behandelt.
6.1. Texturen
Zwei Konventionen der gMotor Engine sind das Dateiformat der Texturen und deren
Auflösung. So dürfen nur Texturen der Formate .bmp, .tga oder .dds verwendet werden.
Bei der Auflösung ist zu beachten, dass die Ausmaße der Textur (Höhe bzw. Breite)
einer Zweierpotenz entsprechen müssen.
6.1.1. verschiedene Arten
Texturen können verschiedene Funktionen haben. Vier der Hauptfunktionen, welche auch
beim Alemannenring Verwendung finden werden im folgenden Text näher betrachtet.
Die meistverwendete Textur ist ein Bitmap (Pixelbild). Diese „werden häufig eingesetzt,
um naturnahe Oberflächen zu erstellen.
1
3d Visualisierung, S. 112
32
6. Materialien
Es ist erheblich leichter, ein Ziegelmauerwerk zu fotografieren, einzuscannen und anschließlich auf (das) 3D-Objekt zu zu ‚mappen‘ als ein bildverarbeitungsprogramm zu
starten, den digitalen Zeichenstift zu schwingen und das Ziegelmauerwerk selber zu erstellen.“2 Eine weitere Texturart wird beim Bump-Mapping verwendet. Dieses „erzeugt
auf Basis eines Graustufenbildes den Eindruck von Erhebungen oder Vertiefungen einer
Oberfläche.“3 Texturen für Specular-Maps und Alpha-Maps sind wiederum Graustufenbilder. Im Fall der Specular-Maps geben die Graustufen an, wie stark Licht von der
Oberfläche reflektiert wird, während bei den Alpha-Map durch die Graustufen die Transparenz des Objektes definiert wird. Texturen für Alpha-Maps werden verwendet, um bei
der Darstellung von Personen, Bäumen oder auch Leitplanken Polygone zu sparen.
Auf das Zusammenspiel verschiedenartigen Texturen wird in Kapitel 6.3 eingegangen.
6.1.2. Verwendung
Kleinere Objekte werden meist mit einer einzigen Textur versehen. Für größere Objekte, insbesondere Gebäude, gibt es potenziell geeignetere Methoden. Am Beispiel eines
Alemannenring-Gebäudes wird dieser Umstand im folgenden veranschaulicht.
Jedes Objekt kann, entsprechende Mapping-Fähigkeiten vorausgesetzt, mit einer einzelnen Textur vollständig texturiert werden. Bei dieser Methode, welche zu Beginn auch
beim Alemannenring Verwendung fand, treten die folgenden drei Probleme auf.
Bei bei einem solchen Verfahren bleibt die gedachte Messgröße Pixel/Meter auf dem
3d-Objekt sehr gering, wodurch die Textur unscharf wird. Ein weiteres Problem ist die
Texturauflösung. Damit Details des Gebäudes überhaupt sichtbar werden, muss die verwendete Textur eine Größe von 1024x1024, bei noch größeren Gebäuden sogar Werte wie
2048x1024 aufweisen. Dies resultiert in einer unerwünscht großen Dateigröße. Zusätzlich
ist der Zeitaufwand, der beim Mapping des Objektes und später der tatsächlichen Texturierung entsteht ist immens und somt das dritte Problem dieser Vorgehensweise.
Ein Beispiel findet sich im linken Teil der Abbildung 6.1. Die Textur wurde dabei von
einem Projektmitarbeiter ohne Hilfe realer Texturen erstellt.
Nachdem im Rahmen des Alemannenring-Projektes ersichtlich wurde, dass ein solches
Texturierungsverfahren zu aufwendig ist, wurde sich für eine andere Methode entschieden. Der rechte Teil der Abbildung 6.1 zeigt das Ergebnis dieses Verfahrens.
2
3
Mach, R.: 3d-Visualisierung, S. 113
ebd.
33
6. Materialien
Abbildung 6.1.: Vergleich beider Varianten zur Texturierung an einem Gebäude des
Alemannenrings
Bei diesem werden anstatt einer großen Textur viele kleine Texturen verwendet. Der
große Vorteil dabei ist die Möglichkeit, einzelne Texturen vielfach zu verwenden und
selbige zu kacheln. Des Weiteren wurden nun Fotos für die Erstellung der Texturen
verwendet, wodurch die Gebäude im Spiel realistischer wirken.
Insbesondere bei Annäherung an das Gebäude fällt auf, wie verwaschen und comichaft
die Texturen bei der veralteten Methode wirken.
6.2. Der Materialeditor
Für die Erstellung und Konfiguration der Materialien wird der Materialeditor von 3dsmax verwendet. Die Einstellungen finden dabei in drei Ebenen statt, die folgend erläutert
werden.
Die oberste Ebene ist das 3dsmax-Material. Dabei ist es eine Konvention der Engine,
dass das Material der obersten Ebene immer ein Multi-/Unterobjekt sein muss. Das
zugehörige Rollout ist in der Abbildung 6.2 zu sehen.
Unter (1) findet sich der Name des Multi-/Unterobjekts. Dieser kann beliebig gewählt
werden. In Feld (2) findet sich die ID des Untermaterials und in (3) dessen Name. Der Name spielt für die Implementierung in rFactor keine Rolle, sollte jedoch trotzdem sinnvoll
34
6. Materialien
Abbildung 6.2.: Materialeditor: Rollout Multi-/Unterobjekt
gewählt werden, da er im Editor von 3dsmax die Suche nach der richtigen Material-Id
vereinfacht. Der Button (*) führt in die nächste Materialebene, die in Abbildung 6.3
sichtbar ist.
Abbildung 6.3.: Materialeditor: Rollout gMat
In dieser findet sich unter (1) der Name des gMat 4 . Bei diesem muss auf die Bezeichnung geachtet werden. Jedes gMat darf auf der kompletten Strecke nur einmal verwendet
4
gMat steht dabei für gMotor Material
35
6. Materialien
werden und weiterhin bestimmt die Bezeichnung des gMat die Fahreigenschaften, siehe Abschnitt 6.4. Bei (2) kann eingestellt werden, wie stark und mit welcher Farbe das
Material Licht reflektiert. Unter (3) finden sich die Shadereinstellungen und die verschiedenen Texture-Stages. Deren Anzahl ist abhängig vom gewählten Shader. Der Button
(*) führt auf die unterste Materialebene, siehe Abbildung 6.4.
Abbildung 6.4.: Materialeditor: Rollout gTex
Dieses Rollout beinhaltet die Einstellungen für die Texturebene, bezeichnet als gTex 5 .
Der Name (1) kann beliebig gewählt werden. Unter (2) muss die gewünschte Textur
ausgewählt werden. Ist die Textur eine .dds- oder .tga-Datei mit einem alpha-Kanal, so
muss das Häkchen bei (3) Croma Color gesetzt und die Farbe auf schwarz eingestellt
werden, um den alpha-Kanal zu aktivieren. Die MIP Bias (4) legt die Texturschärfe in
der Entfernung fest, für die meisten Texturen empfiehlt sich der Wert -1,0, für Straßen
kann er noch niedriger gesetzt werden. Zu niedrige Werte resultieren allerdings im Spiel
in einem Flackern der Textur.
6.3. Shader und Multitexturing
„Shader, auch als Schattierer bezeichnet, sind Hardware- oder Softwaremodule, die bestimmte Renderingeffekte bei der 3D-Computergrafik implementieren. Aus technischer
5
gTex steht für gMotor Texture
36
6. Materialien
Sicht bezeichnet ‚Shader‘ denjenigen Teil eines Renderers, der für die Ermittlung der
Farbe eines Objektes zuständig ist.“6
Die richtige Wahl und Konfiguration der Shader hat einen großen Einfluss auf die Optik
der Strecke. Es ist aus diesem Grunde lohnenswert, an dieser Stelle viel zu experimentieren und die Wirkung der verschiedenen Shader in der Simulation zu testen.
An dieser Stelle soll die Funktion eines Shaders näher erläutert werden. Dieser trägt
im Materialeditor die Bezeichnung: „Bump Specular Map T1“. Sowohl die Fahrbahn
als auch die Reifenstapel verwenden dabei diesen Shader mit drei Textur-Stages. Dabei
fallen jedoch die Konfiguration des selbigen unterschiedlich aus.
Abbildung 6.5.: Shader: Zusammenspiels verschiedener Texture Stages
Anhand der Reifen in Abbildung 6.5 wird die Funktion der einzelnen Texture-Stages klar.
Die Color-Stage (1) definiert die Farbe des Objektes. Die Bump-Map (2) erzeugt gibt
der Oberfläche der Reifen eine Struktor. Eine Specular-Map (3) definiert, welche Teile
des Reifens das auf ihn treffende Licht wie stark reflektieren. Das fertige Endergebnis
findet sich bei (4).
Bei den Reifen sind alle Texture-Stages identisch auf die Reifenstapel gemappt. Ein
großer Vorteil beim Multi-Texturing und die wahre Stärke eines solchen Verfahrens ist,
6
http://de.wikipedia.org/wiki/Shader
37
6. Materialien
dass für jede Textur verschiedene Mapping-ID´s verwendet werden können. Bei genauerer Betrachtung der vier Straßenteile in Abbildung 6.5 fällt auf, dass die Texturen unterschiedlich stark gekachelt sind. Eine Kachel der Fahrbahntextur (1) breitet sich über
die komplette Straße aus (grob 10m x 10m), während die Texturen für die Specular und
Bump-Map sich alle 2m (Spec) bzw. alle 0,5m (Bump) wiederholen.
Noch klarer wird die Funktion des Multitexturings bei der Erstellung größerer Landschaftsareale. Dort wird es mit Hilfe verschiedene Mapping-ID´s möglich, große Areale
mit wenigen, kleinen Texturen optisch ansprechend zu gestalten.
6.4. Auswirkung der Materialnamen auf das
Fahrverhalten
rFactor hegt den Anspruch, eine waschechte Rennsimulation zu sein. Um diesem Anspruch gerecht zu werden, müssen die Fahrzeuge auf verschiedene Untergründe unterschiedlich reagieren. So hat ein Reifen, der den Kontakt zwischen Fahrzeug und Untergrund herstellt, auf einer Straße eine ganz andere Haftung als auf Schotter oder Gras.
Die im Anhang befindliche Tabelle A.1 listet alle von rFactor beachteten Materialien
auf. Diese gliedern sich dabei in die vier Kategorien Straßen, Gras, Curbs und Wände.
Es ist essenziell bei der Streckenerstellung, sich an die Namensgebung der Engine zu
halten, da die Strecke sonst nicht funktionstüchtig ist. Alle Wände und auch undefinierte
(Default) Materialien werden von der Engine als Kollisionsobjekte interpretiert und sind
nicht befahrbar.
38
7. Filestruktur
Das folgende Kapitel beschreibt die Filestruktur von rFactor. Diese ist strikt einzuhalten,
damit Inhalte von Drittanbietern in das Spiel eingebunden werden können.
Einen Streckenordner inklusive aller Dateien von Grund auf zu erstellen, ist eine sehr
fehlerträchtige Angelegenheit und erfreulicherweise nicht notwendig.
Die Einfachste und auch beim Alemannenring-Projekt angewendete Methode, um neue
Inhalte hinzuzufügen ist es, einen vorhandenen Streckenordner zu kopieren und dann
die entsprechenden Dateien zu ändern. In den weiteren Ausführungen geht der Verfasser davon aus, dass die Dateien einer anderen Strecke übernommen und entsprechend
umbenannt wurden.
Abbildung 7.1.: Screenshot: Hauptordner Alemannenring
Vom rFactor-Hauptverzeichnis aus gesehen befindet sich der Streckenordner im Unterordner /GameData/Locations (siehe Abbildung 7.1). Im Fall des Alemannenrings heißt
der Streckenordner schlicht „Alemannenring“. In diesem Hauptstreckenordner befinden
sich zwei Dateien und zwei Unterordner. Die beiden Dateien sind die Alemannenring.mas
und die AlemannenringMaps.mas. Es hat sich als eine Art „Standard“ herausgebildet,
die 3d-Dateien (.gmt) in einer .mas-Datei und die Texturdateien (.dds, .bmp, tga) in
einer weiteren Datei abzuspeichern.
In rFactor ist es möglich, nach einer Art Vererbungsprinzip mehrere Streckenlayouts für
eine Rennstrecke zu erstellen. Die Filestruktur eines solchen Layouts ist in Abbildung
39
7. Filestruktur
7.2 sichtbar. Bei einer solchen Vorgehensweise besteht die Möglichkeit, dass die verschiedenen Layouts auf die selben .mas-Dateien zugreifen, die sich im Hauptordner befinden.
Darüber hinaus ist es natürlich auch möglich, speziell für ein Layout eine eigene .masDatei zu erstellen, auf welche die anderen Layouts keinen Zugriff haben.
Abbildung 7.2.: Screenshot: Unterordner Streckenvariante Alemannenring
Im Unterordner des Layouts befinden sich verschiedene Dateien. Trivial sind die Bilddateien. Die „Alemannenringloading.jpg“ ist der Ladescreen, der beim Starten der Strecke
in rFactor angezeigt wird und die anderen beiden .tga-Dateien sind kleine Bilder, die bei
der Streckenauswahl in rFactor angezeigt werden.
Die Funktion der verbleibenden Dateien wird folgend kurz beschrieben. Auf eine vollständige Dokumentation aller Files wurde im Rahmen dieser Arbeit verzichtet. Zur Vertiefung der Kenntnisse über die Filestruktur wird auf das Literaturverzeichnis verwiesen
(siehe Anhang B).
7.1. .gdb Datei - Informationen über die Strecke
Die .gdb-Datei 1 enthält Informationen über das Streckenlayout, Boxengeschwindigkeiten, den geografischen Standort der Strecke, die Beleuchtungseigenschaften der Umgebung die Standardbezeichnungen für die Setups der Fahrzeuge.2
1
2
gdb steht für Game DataBase
vgl. http://www.modding.frracers.ultramoron.com/Overview.shtml
40
7. Filestruktur
7.2. .scn Datei - Objekte
Die .scn-Datei 3 ist die wichtigste Datei für die Darstellung im Spiel. In ihr wird festgelegt, welche Streckenobjekte beim Start der Strecke geladen werden. Am Anfang der
Datei werden sowohl die Ordner definiert als auch die zu durchsuchenden .mas-Dateien
angegeben. Folgend ein Auszug aus der „Alemannenring.SCN“:
1
2
3
4
5
6
7
8
SearchPath=.
SearchPath=Alemannenring
SearchPath=Alemannenring/Alemannenring
//------------------------------------------------------MASFile=Alemannenring.mas
MASFile=AlemannenringMaps.mas
MASFile=CommonMaps.MAS
[...]
Die einzelnen Objekte, welche im Spiel geladen werden sollen, werden in der .scn als
Instanzen angegeben. Folgend wiederum ein Auszug aus dem Quelltext:
1
2
3
4
Instance=Curbs
{
MeshFile=Curbs.gmt CollTarget=True HATTarget=True ShadowReceiver=True
}
Diese Zeilen sind werden wie folgt von der Enginge interpretiert. Die Instanz Curbs soll
geladen werden, deren MeshFile Curbs.gmt ist.
Nun werden die im oberen Auszug angegebenen Ordner und .mas-Dateien auf die Datei
Curbs.gmt durchsucht. Diese enthält Informationen über die Geometrie, Materialien
und Texturen des Objektes, welche direkt im Anschluss von der Engine geladen werden.
Tritt beim Ladevorgang ein Fehler auf 4 , so gibt es einen einen sogenannten ctd (crash
to desktop). Der Ladevorgang der Strecke wird abgebrochen, das Spiel stürzt ab und der
Nutzer findet sich auf seinem Desktop wieder.
Weiterhin bekommt die Engine aus den oberen Zeilen die Information, dass die Instanz
„Curbs“ ein befahrbares Objekt (HATTarget) ist und auf selbigem Schatten von Fahrzeugen oder anderen Objekten berechnet werden sollen (ShadowReceiver).
3
4
scn steht für Scenery
Wenn eine gesuchte .gmt-Datei oder Textur nicht aufzufinden ist.
41
7. Filestruktur
Jeder Instance-Name darf nur einmalig vorkommen, da sonst Fehler auftreten können.
Analog zu diesem Beispiel sind alle weiteren Objekte in der .scn-Datei definiert, die in
der Simulation zu sehen sind.
7.3. .aiw Datei - KI-Linien
In der .aiw-Datei werden hauptsächlich die Wegpunkte für die KI definiert. Des weiteren enthält sie die Standorte der Startaufstellung und der Boxenplätze der einzelnen
Fahrzeuge. Überdies enthält die .aiw-Datei Informationen über den geschätzten Benzinverbrauch auf der Strecke und Parameter zur Nebelfarbe und -dichte auf der Strecke.
Der Alemannenring besitzt rund 750 Waypoints. Im Anhang (siehe Anhang A.3 findet
sich ein Auszug der „Alemannenring.AIW“, in dem der Quellcode eines solchen Waypoints zu finden ist.
7.4. .cam Datei - Kameras
Sowohl für die Änderung der Kameras als auch die Änderung der im vorigen Kapitel
beschriebenen KI Linien kann der „rFactor AIWCAM Editor“ verwendet werden.
Die .cam-Datei enthält Informationen zum Standort und den Bewegungen der Streckenkameras. rFactor stellt dem Entwickler 2 unterschiedliche Kameratypen zur Verfügung.
Während statische Kameras ein „Standbild“ der Strecke einfangen, fokussieren Verfolgerkameras das gerade aktivierte Fahrzeug an, bis die nächste Kamera aktiviert wird.
Sie schwenken dementsprechend auf das jeweils aktivierte Fahrzeug.
Kameras können zu Präsentationszwecken verwendet werden.
Eine viel wichtigere Funktion der Streckenkameras ist es allerdings, das Renngeschehen
möglichst spannend und effektvoll einfzuangen, damit die Verfolgung eines Rennens über
die TV-Kamera zu einem unvergesslichen Erlebnis wird.
42
8. Abschließende Bemerkungen
Im Rahmen der Bachelorarbeit konnte nur auf grundlegende Sachverhalte der Rennstreckenerstellung in Form einer Modifikation eingegangen werden. Die Modellierung
von Strecke und Umgebung, die Zuweisung der Materialien und die Bearbeitung der
Filestruktur stellen die absoluten Grundlagen der Konvertierung realer Umgebungen zu
virtuellen Rennstrecken dar und decken nur einen Bruchteil der Möglichkeiten ab, die
eine Rennsimulation wie rFactor den Moddern bietet.
Wichtige Begleiterscheinungen bei der Erstellung virtueller Realitäten wie eine strikte Verfolgung des Performace-Gedankens durch vielfache Optimierungen1 konnten im
Rahmen der Arbeit nur kurz angerissen werden bzw. fanden gar keine Erwähnung.
In der Einleitung der Bachelorarbeit wurde der Anspruch erhoben, dem Leser einen Einblick zu geben, wie aus einer realen Umgebung eine virtuelle Rennstrecke entsteht.
Über diesen Gedanken hinaus sollte dem Leser ein Überblick über aktuelle Rennsimulationen gegeben und ein Vorgehensmodell entwickelt werden.
Dieses Vorgehensmodell sollte dem geneigten Leser die einzelnen Schritte eines solches
Prozesses aufzeigen und letztendlich mit dem Rest der Arbeit dazu Befähigen, ein solches Vorhaben, die Integration einer realen Umgebung in eine Rennsimulation, auch
tatsächlich umzusetzen.
Der Überblick über aktuelle Rennsimulationen sowie das Vorgehensmodell findet sich in
der vorliegenden Arbeit wieder.
Weiterhin sollte es möglich sein, mit Hilfe der Arbeit und der im Literaturverzeichnis
angegebenen Quellen eine solide Rennstrecke für eine Rennsimulation zu erstellen.
1
Beispiele für derartige Optimierungen sind Visgroups oder die Erstellung mehrerer LOD-Level
43
A. Anhang
A.1. Gedanken und Vorgehensweise einen Profis
Im Rahmen der Bachelorarbeit hat der Verfasser mehrere Entwickler der Modding-Scene
angeschrieben und nach ihrer Vorgehensweise bei der Kreation von Rennstrecken gefragt.
Ein Entwickler, der in diesem Bereich schon viele Erfahrungen sammeln konnte und
einige qualitativ hochwertige Strecken erstellt hat, ist Alexander Hummler, in der Scene
unter dem Nickname Com8 bekannt. Von diesem stammt die folgende E-Mail.
„Hallo Ricardo,
Erstmal zu den Fragen:
Wie kommst du bzw. nach welchen Kriterien wählst du das Projekt bzw. die Strecke aus,
die du entwickelst?
Tritt ein Unternehmen mit einem speziellen Wunsch an mich heran, ist das Projekt also vorgegeben meine Aufgabe ist dann einfach die Umsetzung nach den Wünschen der Kunden. Möchte ich einfach für
die Community ein Projekt starten, schaue ich mir vorher an welche Strecken bereits in hoher Qualität
verfügbar sind (plattformunabhängig). Vorranging suche ich Strecken aus dem europäischen Raum, die
ein gewisses Feeling erzeugen - dieses Feeling für Tiefe zum Beispiel kommt gut bei naturnahen Anlagen auf. Beispiel Spa, Nordschleife, Sachsenring, Salzburgring - alles wunderschöne Naturrennstrecken
... die Verbindung von Motorsport und Natur muss also nicht unbedingt in einem Gegensatz stehen.
Naturtribünen, die Anpassung der Strecke an das Gelände mit seinen Steigungen, Gefällen und topografischen Besonderheiten machen dann einfach den Reiz beim Layout aus. So entstehen faszinierende
Streckenverläufe. Mit bemalten Parkplätzen ala Tilke kann ich zum Beispiel überhaupt nichts anfangen,
die haben weder Charakter noch eine besondere Atmosphäre, wie ich finde. Auch Strecken die eventuell
nicht sehr bekannt sind reizen mich immer wieder, so entstand zum Beispiel die Autocross Strecke am
Matschenberg in meiner Heimat für rFactor. Oder das Bergrennen in Lückendorf, ich suche da einfach
immer eine neue Herausforderung um die Qualität meiner Arbeit zu pushen.
Wie und wo findest du Referenzen?
Bei einem Kundenauftrag bekomme ich wenn vorhanden CAD-Zeichnungen mit Bau-Lage-und Geländeplänen oder ähnliches Material. Referenzfotos sind ebenfalls ein wichtiger Bestandteil für die möglichst
genaue Umsetzung wenn es um das Modelling und Texturing geht. Bei einem Eigenprojekt nutze ich oft
Google Earth um plane Aufnahmen zu bekommen. Die nutze ich dann für das grobe Layout und teilweise auch als Geländetexturen. Manchmal reise ich dann selber zu Strecken um Referenzfotos zu machen,
44
A. Anhang
oft helfen mir auch Leute aus der Community die in der Nähe der Strecke wohnen (so geschehen bei
Mainz-Finthen und Norisring 2009). Onboardvideos sind ebenfalls eine gute Quelle um Anhaltspunkte
für Feinheiten im Layout oder der Fahrbahn zu haben. Auch erkennt man in den Videos, die für den
Fahrer wichtigen Details am Streckenrand - da die Strecke mal in einer Rennsimulation landen soll, ist
das also ein extrem wichtiger Punkt.
Für welche Rennsimulationen entwickelst du deine Strecken? Warum gerade diese?
Im Moment hauptsächlich für rFactor, manchmal konvertiere ich die Strecken dann auch nach GTREvo
bzw. RaceOn - also ausschließlich die gmotor2 Engine. Das liegt einfach daran, das die Engine leicht
zugänglich ist, sich einfach Modden lässt und sehr gut mit 3D Studio Max zusammenarbeitet. Zudem
kenne ich die Engine seit fast fünf Jahren - kenne also alle Tricks und Kniffe um die bestmögliche
Qualität rauszuholen.
Welche Software verwendest du für die Umsetzung?
Für das Modeling, Mapping und Texturing verwende ich 3D Studio Max 8. Dort entsteht das Layout,
die Objekte und die komplette Vegetation. Sind einfache Objekte in Masse zu platzieren oder kurz was
nachzuprüfen nutze ich auch 3D Simed ergänzend.
Jetzt was zum Ablauf eines Projektes.
Als erstes steht natürlich die Idee. Nachdem die Auswahl getroffen ist geht es zuerst an den Research.
Ich versuche so viel Information wie nur möglich über die Strecke zu bekommen - sammle Alles was
im Entferntesten mit dem Projekt zu tun hat. Fotos, Videos, Pläne, Zeichnungen, Geschichten oder
Homepages - einfach Alles. Dann geht es an den Streckenverlauf. Habe ich nur topografische Unterlagen
zur Verfügung (z.Bsp. Google Earth) lege ich mir den Verlauf in der richtigen Größe als Grundlage für
das Modelling. Ich arbeite beim Erstellen des Layouts mit dem Lofting-Verfahren. Im nächsten Schritt
erstelle ich das Terrain innerhalb, sowie außerhalb der Strecke bis zu einer bestimmten Entfernung. Dann
werden Kiesbetten, Curbs und Auslaufzonen eingearbeitet. Ist das getan werden die Leitplanken und
Mauern gestellt, danach versuche ich bereits die grobe Vegetation um die Strecke zu gestalten - mit Hilfe
von einfachen "Treewalls"werden Wälder oder Wiesen begrenzt. Es folgen das Stellen der Fangzäune und
das Modelling der Gebäude und Boxenanlagen. Die Objekte werden meist direkt nach dem Modelling
gemappt und erstmal einfach texturiert - zwischendruch werden immer wieder Ingame-Tests gefahren.
Die Vegetation wird verfeinert und es folgen immer mehr Details die eingearbeitet werden. Nach Sichtung
von Fotos und Videos weiß man, welche Details für die Strecke wichtig sind - eine gewisse Grenze ist
ja doch immer gegeben, schließlich soll die Strecke später auf vielen unterschiedlichen Rechnersystem
gleich gut laufen. Da ist das abwägen von Detailgrad und Performance manchmal sehr schwierig.
Ist dann Alles soweit, zusammengesetzt und texturiert werden die Shader für DX9 und DX8 eingestellt
- Spec-, Bump- und Multimapping, Alpha für Bäume und Zäune sowie das Environment Mapping. Alles
exportieren und die Struktur von rFactor einbinden. Zum Schluss das Erstellen der Kameras und die
Waypoints für die AI, das Grid, Garagen- und Boxenplätze. Dann muss getestet werden - verschiedene
DX Versionen, Textur- und Detailgrade. Mit oder ohne Antialiasing bzw. Anisotropen Filter um spätere
Fehler bei den Usern auszuschließen. Ist die Strecke auf Herz und Nieren geprüft kann sie als v1.0 released
werden!
So, mehr fällt mir grad nich ein .. wenn noch was unklar ist melde Dich einfach!
Gruß, Alex - www.com8-rennsim.de.vu“
45
A. Anhang
A.2. Tabelle zu Materialien in rFactor
Die Tabelle A.1 beschreibt die verschiedenen Materialien, die von rFactor zur Verfügung gestellt werden. Die Tabelle wurde mit Hilfe der „terrain.tdf“ erstellt. Diese Datei
befindet sich im Streckenordner von rFactor und legt Gripverhältnisse der Materialien
und die Effekte bei Berührung 1 fest. Die Spalte Grip ind der Tabelle zeigt die Haftung
auf den verschiedenen Oberflächen an und die Resistance könnte mit Widerspenstigkeit
übersetzt werden. Desto höher sie ausfällt, desto weniger steuerbar ist das Auto auf dem
Untergrund.
A.3. Waypoint
Folgender Auszug beschreibt einen einzelnen Wegpunkt der .aiw-Datei. Darin enthalten
sind Daten wie die aktuelle Position des Punktes, ein Verweis auf den nachfolgenden
Punkt, die Breite der befahrbaren Strecke links- und rechtsseitig des Punktes und viele
weitere Informationen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
wp_pos=(140.9035,5.5950,2.8839)
wp_perp=(-0.0119,-0.0005,-0.9999)
wp_normal=(0.0000,1.0000,-0.0005)
wp_vect=(4.9510,-0.0000,-0.0602)
wp_width=(9.025,8.100,14.025,13.100)
wp_dwidth=(23.636,22.647,0.000,0.000)
wp_path=(-6.1143,0.0000)
wp_lockedAlpha=(0)
wp_galpha=(0.0000)
wp_groove_lat=(0.893367)
wp_test_speed=(50.725101)
wp_score=(2,3559.389)
wp_cheat=(50.7251)
wp_wpse=(0,0)
wp_branchID=(0)
wp_bitfields=(0)
wp_lockedLats=(0)
wp_multipathlat=(0.0000, 4.5000)
wp_pitlane=(1)
WP_PTRS=(0,2,-1,0)
1
Beispiele für solche Effekte sind ein Ruckeln des Lenkrades bei Fahten über Kopfsteinpflaster oder
diverse Reifenspuren bei Fahrten über Gras etc.
46
A. Anhang
Kürzel
Beschreibung
Grip
Resistance
ROADS
road
ovalrd
rdax
rdta
rdcp
Road
Oval Roads
Roads Bumps LVL1
Roads Bumps LVL2
Road Cement Patchs
1.00
1.00
1.00
1.00
0.95
0
0
0
0
0
rged
gras
grxs
grvl
dstg
GRASS AND DIRT
Dusty Berms
1.00
Grass
0.65
Rough Grass
0.65
Gravel
0.52
Dusty Grass
0.65
0
100
1500
5000
100
rmbl
RUMBLE STRIPS
Rumblestrips
1.00
0
twal
cmwl
grdr
grvl
*
Tirewalls
Cementwalls
Guardrails
Safer
Default
WALLS
-
Tabelle A.1.: rFactor Materialien
47
-
B. Literaturverzeichnis
Adobe: Homepage Photoshop
http://www.adobe.com/de/products/photoshop/photoshop/whatisphotoshop,
08.09.2010
Autodesk: Homepage 3dsMax
http://www.autodesk.de/adsk/servlet/pc/index?id=14642267&siteID=403786,
02.09.2010
Benoit, Gilles (ISI): Basic track editing information. Notes from the field
http://www.rfactor.net/developers/notes_basic_track_editing.cfm, 08.09.2010
Chalker, Ewan: rFactor Track Making Tutorial Wiki
Foley, J.; v. Dam, A.; Feiner, S.; Hughes, J.; Phillips, R.:
Grundlagen der Computergrafik, 1. Auflage, 1994
Häßler, U.:
3D-Imaging, 1996
ISI: Developer´s Corner
http://www.rfactor.net/developers, 02.09.2010
ISI: gMotor 2.0 MAS Utility Help
ISI: gMotor 2.0 Plugin and Viewer Tools
ISI: Official rFactor modding tutorial
http://www.modding.frracers.ultramoron.com, 08.09.2010
ISI: Webseite der Rennsimulation rFactor
http://www.rfactor.net, 02.09.2010
Mach, R.:
3d-Visualisierung, 1. Auflage, 2000
48
B. Literaturverzeichnis
nVidea; dds-Tools
http://developer.nvidia.com/object/nv_texture_tools.html, 02.09.2010
Wilhelmi, Mike: Homepage des Projekt Alemannenring
http://alemannenring.de, 02.09.2010
o.V.: gMotor Manual,
http://wikiwiki.jp/simbin/?gMotor Manual, 02.09.2010
o.V.: Loft-Tutorial
http://pixel81k.abstract-design.ch/tutorials/3dsmax/racetrack/index.html,
27.08.2010
o.V.: Wikipedia: Mod(Computerspiel)
http://de.wikipedia.org/wiki/Mod_(Computerspiel), 09.09.2010
o.V.: Wikipedia: Rennsimulation
http://de.wikipedia.org/wiki/Rennsimulation, 09.09.2010
o.V.: Wikipedia: Rennsimulation
http://de.wikipedia.org/wiki/Shader, 09.09.2010
49