Ackerman Geometrisi Diplomarbeit

J O HA NN E S K E P L E R
U N I V E R S I T Ä T LI N Z
Ne tzwe r k f ür F or s c h u ng , L eh r e un d Pr a x is
Ein 3-dimensionales Modell zur Simulation von

Kraftfahrzeugen in Echtzeitanwendungen
DIPLOMARBEIT
zur Erlangung des akademischen Grades
DIPLOMINGENIEUR
in der Studienrichtung
INFORMATIK
Angefertigt an der Abteilung für Graphische und Parallele Datenverarbeitung des Instituts für
Technische Informatik und Telematik
Betreuung:
o. Univ.-Prof. Dr. Jens Volkert

Dipl.-Ing. Dr. Gerhard Kurka
Eingereicht von:
Stephan Gsöllpointner
Linz, September 2002
Johannes Kepler Universität

A-4040 Linz · Altenbergerstraße 69 · Internet: http://www.uni-linz.ac.at · DVR 0093696
Kurzfassung
Die physikalische Modellierung beweglicher Objekte spielt in vielen Anwendungsgebie-

ten eine wichtige Rolle. Im Maschinen- und Fahrzeugbau können durch die Simulation
von komplexen mechanischen Systemen Messdaten gewonnen, und dadurch Rück-
schlüße auf das Laufzeitverhalten von Realsystemen gezogen werden. In der Simulation
und in der Darstellung virtueller Welten wird durch eine angemessene physikalische
Modellierung beim Benutzer ein Gefühl der Vertrautheit geschaffen: Die Szenenobjekte
verhalten sich bei der Interaktion mit ihrer virtuellen Umgebung so, wie man es von
ihnen in der Realität erwarten würde.
Ziel dieser Arbeit ist es, ein Modell für die Simulation eines Fahrzeuges zu finden, das
durch sein realistisches, physikalisches Laufzeitverhalten überzeugt, ohne dabei den
Anspruch auf eine technisch exakte Modellbildung zu erheben. Primäres Anwendungs-
gebiet ist der Einsatz in Computerspielen. Es sind aber auch andere Anwendungsgebiete
für das Fahrzeugmodell denkbar.
Da in der Literatur nur sehr komplexe oder nur sehr triviale Modellierungsansätze für
Fahrzeuge zu finden sind, habe ich versucht, bestehende Beschreibungen von Mehrkör-
permodellen in mehreren Punkten zu vereinfachen. Das Ergebnis ist ein Modell in 14
Freiheitsgraden. Neben der rein mechanischen Umsetzung des Fahrzeugkörpers, wird
aber auch auf die Modellierung des Reifen-Boden Kontaktes, auf die Modellierung des
Antriebes, und auf die Findung geeigneter Simulationsparameter eingegangen.
Ein weiterer Aspekt der Arbeit ist die Visualisierung des Fahrzeuges und des umgeben-
den Terrains. Es werden unterschiedliche Ansätze in der Terrainvisualisierung vorge-
stellt. Besonderes Augenmerk erfährt dabei die Visualisierungsgeschwindigkeit: Auf
heute üblicher Hardware (P3-800, 3D-Graphikkarte) sollen Frameraten von 50 Hz und
mehr erzielt werden.
i
Abstract
Physical modelling of moving objects is a crucial task in many application areas. The
simulation of the complex behaviour of mechanical systems is often an inevitable part of
the whole construction process. Another example is the simulation of virtual environ-
ments. To provide confidence in the simulation, the objectcs within the scene are expec-
ted to behave in a realistic way. This goal can only be achieved by using an appropriate
physical modeling.
The primary objective of this work is to find a model for the simulation of a vehicle able
to convincingly simulate the dynamical behavior of the vehicle without the claim for
physical correctness. The system mainly aims on support for computer games, but can
also be used for other areas with similar requirements. Contrary to the literature, this
work focuses on the simplification of multi-body systems by replacing them with a set of
mass-points. As a result we get a model that shows 14 degrees of freedom. In addition,
apart from the purely mechanical conversion of the the vehicle body, this work deals also
with the simulation of the tires and the identification of suitable simulation parameters
for the vehicle’s drive train.
A further aspect of the work is the visualization of the vehicle on a height-field based
fully textured terrain. Various approaches to terrain visualization appropriate for this pur-
pose are described and evaluated. Special attention is paid to the achieveable rendering
speed. Taking into account commodity hardware (P3-800Mhz, 3D-Accelerator) the ter-
rain engine aims on a minimum framerate of about 50 frames per second.
ii
Danksagung
An dieser Stelle möchte ich all jenen danken, die mir durch ihre Unterstützung das
Schreiben dieser Diplomarbeit ermöglicht haben. Mein besonderer Dank geht an o.
Univ.-Prof. Dr. Jens Volkert und an Dipl.-Ing. Dr. Gerhard Kurka für die Betreuung mei-
ner Diplomarbeit.
iii
Lebenslauf
Geboren am 12.10.1976 in Ried i. I.
1995: Abschluß des Bundesrealgymnasiums Ried
1995-1997: Colleg für Graphik Design (Kommunikationsdesign) in Linz
1997: Beginn des Informatik Studiums an der Johannes Kepler Universität in Linz
iv
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt
bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht
habe.
Linz, Oktober 2002 Gsöllpointner Stephan
v
Verwendete Formelzeichen
µ [–] = Reibkoeffizient
µk [–] = kinetischer Reibkoeffizient
µs [–] = statischer Reibkoeffizient
τ [Nm] = Drehmoment
ω [rad/s] = Winkelgeschwindigkeit
2
a [m/ s ] = Beschleunigung
d [Ns/m] = Dämpferkonstante
fs [N] = statische Reibkraft
fk [N] = kinetische Reibkraft
F [N] = Kraft
I [–] = Trägheitstensor
Ibody [–] = Trägheitstensor des Starrkörpers in Normallage
J [Ns] = Stoß
k [N/m] = Federkonstante
L [Ns/m] = Drehimpuls
m, M [kg] = Masse
P [Ns] = Impuls
R [–] = Orientierung des Starrkörpers
v [m/s] = Geschwindigkeit
x [m] = Position
Für die erste Ableitung einer Größe x verwende ich die Schreibweise x· , für die zweite
Ableitung die Schreibweise x·· .
vi
Inhaltsverzeichnis
1 Einführung 1
1.1 Motivation und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aufbau der Arbeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Koordinatensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Physikalische Grundlagen 5
2.1 Diskret-kontinuierliche Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Kontinuierliche Simulation von physikalischen Systemen. . . . . . . . . . . . 6
2.1.2 Integrationsverfahren nach Euler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Masse-Feder-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Drall (Impulsmoment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Starrkörperdynamik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Position und Orientierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Lineare und angulare Geschwindigkeit . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Kraft und Moment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Trägheitsmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.5 Bewegungsgleichungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.6 Quaternions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Verteilung der Auflagekräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Herleitung der statischen Verteilung. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 Geometrische Interpretation und Anwendung . . . . . . . . . . . . . . . . . . . . 18
2.6 Übertragung der Horizontalkräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Stoßübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.1 Stoßberechnung für den Starrkörper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.2 Kollisionsabfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Reibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
vii
viii
3 Das Fahrzeugmodell 29
3.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Kopplung der Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Kraftübertragungszyklus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Bodenkontakt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.3 Kollisionsabfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.4 Starrkörper-Feder-Kopplung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Rad-Straße-Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.1 Bodenhaftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Rollwiderstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Lenkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.1 Ackerman-Lenkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2 Lenkkräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Antrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6.1 Drehmomentkurve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6.2 Getriebe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.3 Rückkopplung von Motor und Antriebsreifen . . . . . . . . . . . . . . . . . . . . 42
3.7 Bremse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8 Simulationszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.9 Physikalisches Modell und Geometrie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Visualisierung des Terrains 47

4.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Quadtree-Verfahren nach Röttger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Geometrical Mipmapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.1 Das Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 Repräsentation der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.3 Erzeugung des Quadtrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.4 Auswahl der Detailstufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.5 Realisierung von Detailstufen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Texturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1 Texturkacheln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.2 Distanzbasierte Detailüberblendungen . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.3 Maskierungsverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.4 Polygonale Repräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.5 Polygonale Zuordnung mit Maskierung in den Übergängen . . . . . . . . . 62
4.4.6 Multitexturing: Überblendungsmechanismen. . . . . . . . . . . . . . . . . . . . . 63
ix
5 Systemarchitektur 65
5.1 Konzeptuelle Überlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Verwendete Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.1 Eindimensionale, gerichtete Größen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.2 Orientierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.3 Masseträgheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Überblick über die verwendeten Klassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1 Implementierung des Fahrzeuges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.2 Graphikschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.3 Terrainvisualisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Die Klassen im Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.1 Relevante Klassen für den Entwickler . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.2 Intern verwendete Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4.3 Weitere Klassen und Include-Dateien. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Implementierungsaspekte 75
6.1 Physikalisches Fahrzeugmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1.1 Kräfteberechnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1.2 Stoßberechnungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.3 Abstimmung der Radaufhängung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.1.4 Berechnung der Teillastkurven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.1.5 Getriebeabstimmung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1.6 Luftwiderstand und Rollwiderstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1.7 Rückkopplung von Motor und Antriebsrädern. . . . . . . . . . . . . . . . . . . . 85
6.1.8 Bremse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.9 Lenkgeometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.10 Fahrzeugkontrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2 Graphik Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.1 Matritzenoperationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.2 Das DirectX Dateiformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2.3 Beleuchtung und Nebel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3 Terrain Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.1 Repräsentation der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.2 Bestimmung des Höhenwertes für einen beliebigen Geländepunkt . . . . 94
6.3.3 Reifen-Boden Kollision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.4 Initialisierung des Quadtrees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3.5 Der Render-Durchlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.3.6 Texturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.3.7 Wahl der Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
x
6.4 Szenenaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7 Laufzeitmessungen 103
7.1 Fall aus einem Meter Höhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.2 Beschleunigung auf der Geraden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.3 Kurvenverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.4 Freie Fahrt im Gelände. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A Quaternions 121
A.1 Rechenoperationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
A.1.1 Addition und Subtraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
A.1.2 Multiplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
A.2 Umrechnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.2.1 Rotationsmatrix in Quaternion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.2.2 Quaternion in Rotationsmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.2.3 Rotationsachse und -winkel in Quaternion . . . . . . . . . . . . . . . . . . . . . . 124
A.2.4 Quaternion in Rotationsachse und -winkel . . . . . . . . . . . . . . . . . . . . . . 124
B Frustum Culling 125
C DirectX Render-Framework 129

C.1 Das Nachrichtenkonzept unter Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
C.1.1 Hauptnachrichtenschleife (Windows Message Loop) . . . . . . . . . . . . . 129
C.1.2 Nachrichtenverarbeitung des Hauptfensters . . . . . . . . . . . . . . . . . . . . . 130
C.2 Einbindung der Graphikausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
C.2.1 Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
C.2.2 Graphikausgabe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
D Blit Funktion 133
E Das Terrain Dateiformat 137
F Tastaturbelegung 139
Abbildungsverzeichnis
1.1 Bezugskoordinatensysteme des Fahrzeuges. . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Kräftediagramm: 2-Weg-Federsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Blockschaltbild für das Masse-Feder-System . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Transformation eines Punktes vom Objektkoordinatensystem ins Weltkoor-
dinatensystem11
2.4 Geschwindigkeit des i-ten Partikels im Strarrkörper . . . . . . . . . . . . . . . . 13
2.5 Herleitung der vertikalen Kräfteverteilung über Momente . . . . . . . . . . . 18
2.6 Geometrische Interpretation der vertikalten Kräfteverteilung: Tragkraft und
Drehmoment19
2.7 Rückführung der Antriebs- und der Seitenkräfte auf den Schwerpunkt des
Starrkörpers20
2.8 Position der Starrkörper A und B vor dem Zeitpunkt der Kollision (links),
und zum Kollisionszeitpunkt (rechts)22
2.9 Annäherungsgeschwindigkeit der Starrkörper A und B (Punkt-Fläche-Kon-
takt)23
2.10 Anwendung des Stoßes auf die Körper A und B . . . . . . . . . . . . . . . . . . . 24
2.11 Reibkraft in der Kontaktfläche eines Quaders . . . . . . . . . . . . . . . . . . . . . 25
2.12 Zusammenhang zwischen horizontaler Kraft und Reibkraft . . . . . . . . . . 26
3.1 Frhrzeugmodell schematisch (Seitenansicht). . . . . . . . . . . . . . . . . . . . . . 31
3.2 Kräfteentwicklung durch Boden-Reifen-Kontakt . . . . . . . . . . . . . . . . . . 33
3.3 Kamm’scher Kreis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Lenkprinzip nach Ackerman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Aufspaltung des Geschwindigkeitsvektors am Reifen. . . . . . . . . . . . . . . 38
3.6 Beispiel für eine Drehmomentkurve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Skalierung der Drehmomentkurve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Simulationszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Verwendung des Starrkörpers im Fahrzeugmodell . . . . . . . . . . . . . . . . . 45
4.1 Gelände-Triangulierung unter Verwendung des Quadtree Algorithmus mit
Distanz-basiertem LOD49
4.2 Exemplarische Flächenaufteilung mit Hilfe des Quadtree-Algorithmus . 52
4.3 Höhenprofil in unterschiedlichen Detailstufen . . . . . . . . . . . . . . . . . . . . 54
4.4 Höhenfehler (durch Detailreduktion bedingt) . . . . . . . . . . . . . . . . . . . . . 54
4.5 Messung des Höhenfehlers in einem Polygon . . . . . . . . . . . . . . . . . . . . . 55
xi
xii
4.6 Gitterstruktur eines Terrainblocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.7 Enstehung von Löchern in bei Detailübergängen . . . . . . . . . . . . . . . . . . 57
4.8 Realisierung der T-Verbindungen zwischen Terrainblöcken unterschiedli-
cher Auflösung58
4.9 Gelände-Triangulierung unter Verwendung des Geometrical Mipmapping
58
4.10 Zuordnung der Daten aus der Featuremap . . . . . . . . . . . . . . . . . . . . . . . . 60
4.11 Bestimmung des Übergangsbereiches zwischen den Landschaftsregionen.
62
4.12 Texturstufen unter DirectX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 UML Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.1 Bestimmung des Kraftanteiles, der in die Radaufhängung überführt wird .
76
6.2 Aufspaltung der Gewichtskraft in Normalkraft und Hangabtriebskraft. . 76
6.3 Drei Formen eines gedämpften Schwingungsverlaufes . . . . . . . . . . . . . . 79
6.4 Skalierung der Vollastkurve am Beispiel eines Kurvenpunktes . . . . . . . 80
6.5 Berechnete Teillastkurven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.6 Vollastkurve bei unterschiedlichen Getriebeübersetzungen . . . . . . . . . . 83
6.7 Traktions- und Fahrtwiderstandskräfte . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.8 Bestimmung der Lenkwinkel nach Ackerman . . . . . . . . . . . . . . . . . . . . . 88
6.9 Eingriffsmöglichkeiten des Fahreres auf die Steuerung des Fahrzeuges. 89
6.10 Modellierung des von Gas und Kupplung beim Schaltvorgang . . . . . . . 89
6.11 Interpolation eines Höhenwertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.12 Auswahl der Polygone für die Schnittberechnung mit dem Reifen . . . . . 96
6.13 Bestimmung der Laufrichtung des Reifens . . . . . . . . . . . . . . . . . . . . . . . 97
6.14 Zuordnung der Texturkoordinaten auf ein qudratisches Polygon . . . . . 101
6.15 Szenengraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.1 Starrkörpergeschwindigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.2 Auflagekräfte in den Reifen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.3 Radaufhängung vorne links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.4 Radaufhängung vorne rechts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.5 Radaufhängung hinten links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.6 Radaufhängung hinten rechts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.7 Drehmomentkurve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.8 Antriebs- und Widerstandskräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.9 Fahrzeuggeschwindigkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.10 Auflagekräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.11 Fahrzeug in Kurvenlage (Linkskurve) . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.12 Fahrspur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.13 Geschwindigkeitsmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.14 Auflagekräfte in den Reifen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.19 Fahrspur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.20 Fahrzeug im Gelände (erste Rechtskurve) . . . . . . . . . . . . . . . . . . . . . . . 116
7.21 Geschwindigkeitsmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
xiii
7.22 Auflagekräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

B.1 Mögliche Fehlentscheidung beim Frustum Culling . . . . . . . . . . . . . . . . 130
D.1 Darstellung eines rechteckigen Bildes mit Hilfe der Blit-Funktion. . . . 137
Kapitel 1
Einführung
1.1 Motivation und Zielsetzung

Die Simulation von physikalischen Vorgängen spielt in vielen Anwendungsgebieten eine
wichtige Rolle. Bei einigen technischen Berufen ist sie nicht mehr wegzudenken. Im
Maschinen- und Fahrzeugbau können durch die Simulation von komplexen mechani-
schen Systemen Messdaten gewonnen, und dadurch Rückschlüße auf das Laufzeitver-
halten von Realsystemen gezogen werden.
Auch in der Unterhaltungsindustrie, insbesondere bei der Erstellung von Filmen und
Computerspielen, wird dem Bedürfnis nach realistischer 3D-Graphik nicht nur in Form
von möglichst fotorealistischen Darstellungen genüge getan. In bewegten Szenen trägt
zu einem großen Teil die Qualität einer Animation zum Realismus der Darstellung bei.
Um möglichst realistische Bewegungsabläufe zu erzeugen, werden deshalb vielfach phy-
sikalische Modelle verwendet. Vernachlässigt man die Gesetzte der Physik, so wirken
die Bewegungsabläufe oft künstlich und unecht.
Da ein physikalisches Modell in Abhängigkeit von seinem Detaillierungsgrad schnell

sehr komplex werden kann, ist es sinnvoll, sich im Vorfeld genau zu überlegen, welche
Aspekte für die Simluation von beweglichen Szenenobjekten relevant sind. Es stellen
sich folgende Fragen:
1. Durch welche externen Kräfte wird das Modell beeinflußt?
2. Welche Kräfte treten im inneren des Modelles auf und wie hoch ist ihr Einfluß auf das
Laufzeitverhalten des Systems?
Wiegt man den Einfluß des Detaillierungsgrades gegen die Auswirkungen auf das Lauf-
zeitverhalten ab, so kann das Modell den Bedürfnissen und Anforderungen der Anwen-
1
Aufbau der Arbeit 2
dung möglichst gut angepasst werden. Im Speziellen bei Echtzeitanwendungen wird

dadurch kostbare Rechenzeit eingespart.
Im Rahmen der hier vorliegenden Arbeit wird ein physikalisches Modell beschrieben,
das für die Echtzeitsimulation von Fahrzeugen verwendet werden kann. Als Anwen-
dungsgebiet ist der Einsatz in Computerspielen und vergleichbaren Anwendungen vor-
gesehen. Dh., bei der Umstezung des Modells steht nicht so sehr die technisch exakte
Modelierung im Vordergrund, als weitmehr eine möglichst gute Annäherung an das
Realverhalten eines Fahrzeuges. Das Ergebnis ist ein Modell in 14 Freiheitsgraden, das
in erster Linie durch sein Laufzeitverhalten überzeugen soll. Neben der rein mechani-
schen Umsetzung des Fahrzeugkörpers, wird zudem auf die Modellierung des Reifen-
Boden Kontaktes eingegangen, auf die Modellierung des Antriebes, und auf die Findung
geeigneter Simulations-parameter.
Ein weiterer Aspekt der Arbeit ist die Visualisierung des Fahrzeuges und des umgeben-
den Terrains. Es werden unterschiedliche Ansätze in der Terrainvisualisierung vorge-
stellt. Besonderes Augenmerk erfährt dabei die Visualisierungsgeschwindigkeit: Auf
heute üblicher Hardware (P3-800, 3D-Graphikkarte) sollen Frameraten von 50 Hz und
mehr erzielt werden. Die Graphikausgabe basiert auf der Schnitstelle DirectX 8.1
[DX8 00].
1.2 Aufbau der Arbeit
In den Kapiteln werden folgende Themen besprochen:
• Kapitel 2, „Physikalische Grundlagen“, stellt die physikalischen und mathematischen

Modelle vor, auf denen die Umsetzung des Fahrzeugmodelles beruht. Außerdem wer-
den wichtige Begriffe erklärt, die im Zusammenhang mit physikalischen Simulatio-
nen gebräuchlich sind.
• Kapitel 3, „Das Fahrzeugmodell“, beschreibt den Aufbau des Fahrzeuges und seiner
Komponenten. Dazu werden die in Kapitel 2 vorgestellten Konzepte herangezogen.
Zusätzlich wird auf die Modellierung des Reifen-Boden-Kontaktes, auf die Modellie-
rung des Antriebes, und auf die Übertragung von Kräften und Stößen zwischen den
Komponenten eingegangen. Der Simulationszyklus wird erläutert.
• Kapitel 4, „Visualisierung des Terrains“, beschäftigt sich mit der Darstellung der
Landschaft, die als Umgebung für das Fahrzeug dienen soll. Dabei wird ein Visuali-
sierungsverfahren näher vorgestellt. Weitere Ansätze in der Triangulierung und in der
Texturierung werden kurz beschrieben.
• Kapitel 5, „Systemarchitektur“, gibt einen Überblick über die vorliegende Implemen-

tierung. Es handelt sich dabei im Wesentlichen um eine Auflistung der Klassen, und
eine Beschreibung von deren Funktionalität. Einleitend wird auf allgemeine Design-
kriterien eingegangen.
3 Einführung
• Kapitel 6, „Implementierungsaspekte“, behandelt wichtige Aspekte in der Umsetzung

der Simulation. Gemeint sind jene Aspekte, die für die Umsetzung des Fahrzeugmo-
delles relevant sind, aber auch solche, die zum Verständnis des Quellcodes beitragen
sollen.
• Kapitel 7, „Laufzeitmessungen“, präsentiert die Ergebnisse, die in der Simulation

erzielt werden konnten. Es wurden jene Daten ausgewertet, die dem Modell zur Lauf-
zeit entnommen und aufgezeichnet wurden.
1.3 Koordinatensysteme
Für die Berechnung und Zuführung von Kräften werden drei unterschiedliche Koordina-
tensysteme betrachtet:
1. Das Weltkoordinatensystem
2. Das Objektkoordinatensystem des Fahrzeuges
3. Die Objektkoordinatensysteme der Räder
Abbildung 1.1: Bezugskoordinatensysteme des Fahrzeuges
Wird in den folgenden Kapiteln von Longitudinal- oder Lateralkräften gesprochen, so

beziehen sich diese auf das jeweilige Koordinatensystem. Die Longitudinalkräfte der
Reifen sind in X-Richtung des Objektkoordinatensystems „Reifen“ abzutragen. Ist die
Koordinatensysteme 4
Rede von Lateralkräften auf das Fahrzeug, so sind jene Kräfte gemeint, die in X-Rich-
tung des Objektkoordinatensystems „Fahrzeug“ verlaufen (siehe Abb. 1.1).
Die Y-Achse verläuft normal zur X- und zur Z-Achse. Positive Werte werden „oberhalb“
der XZ-Ebene aufgetragen.
Kapitel 2
Physikalische Grundlagen
In weiterer Folge wird an manchen Stellen von der Kinematik oder von der Kinetik
gesprochen. Deshalb möchte ich dem Kapitel folgende Begriffsdefinitionen voranstellen.
Sie wurden aus [Dubb 90] entnommen.
Kinematik (Kinematics)
Die Kinematik ist die Lehre von der geometrischen und analytischen Beschreibung der
Bewegungszustände von Punkten und Körpern. Sie berücksichtigt nicht die Kräfte und
Momente als Ursachen für die Bewegung.
Kinetik (Dynamics)
Die Kinetik untersucht die Bewegung von Massepunkten, Massepunktsystemen, Kör-

pern und Körpersystemen als Folge der auf sie wirkenden Kräfte und Momente unter
Berücksichtigung der Gesetze der Kinematik
2.1 Diskret-kontinuierliche Simulation

Unter kontinuierlicher Simulation versteht man die Nachbildung und schrittweise
Berechnung von kontinuierlichen Prozessen durch Systeme von Differentialgleichungen.
Um die Kinetik eines Fahrzeuges nachzubilden, müssen Differntialgleichungen gefun-
den werden, die das Verhalten von Massekörper, Federelementen, Dämpfern und Rädern
beschreiben. Die Mechanik bietet hierfür eine Reihe von mathematischen Gleichungen.
In Abschnitt 2.2 bis Abschnitt 2.4 wird darauf näher eingegangen. Außerdem wird ein
geeignetes numerisches Integrationsverfahren benötigt, um die Zustandsänderung des
Systems in Abhängigkeit von der Zeit beschreiben zu können. Der Systemzustand wird
5
Diskret-kontinuierliche Simulation 6
durch schrittweise Integration der abgeleiteten Systemgrößen über die Simulationszeit

bestimmt.
Da der kontinuierliche Prozess von diskreten Ereignissen unterbrochen werden kann,

spricht man von einer kombiniert diskret-kontinuierlichen Simulation. Die unterbrechen-
den Ereignisse nennt man Kollisionen. Durch das Auftreten von Kollisionen können sich
die Simulationsvariable sprunghaft ändern und die Integration der Systemgrößen muß ab
diesem Zeitpunkt neu angesetzt werden. Das passiert dann, wenn Stöße auf Karosserie
oder Räder übertragen werden. Die eigentliche Simulation liegt allerdings in der
Beschreibung der kontinuierlichen Prozesse. Durch das Eintreten eines Ereignisses
ändern sich nur die Zustandsgrößen innerhalb des Systems. Auf die Berechnung von Stö-
ßen und deren Auswirkung auf die Kontinuität der Simulation wird in Abschnitt 2.7
näher eingegangen. Vorerst ist es notwendig, die Grundlagen der kontinuierlichen Simu-
lation zu erläutern.
2.1.1 Kontinuierliche Simulation von physikalischen Systemen

In physikalischen Systemen werden Objekte durch kennzeichnende physikalische Grö-
ßen wie Geschwindigkeit, Beschleunigung, Energie, Impuls, usw. beschrieben. Manche
dieser Größen sind mittels Gleichung aus den bekannten Werten anderer Größen unmit-
telbar errechenbar – man nennt solche Größen funktionale Größen. Andere Größen las-
sen sich durch Hinzukommen eines kleinen Teilbetrages zu ihrem aktuellen Wert inner-
halb eines gewissen Zeitintervalls ermitteln – solche Größen nennt man Zustandsgrößen.
Ziel der kontinuierlichen Simulation ist es, den Funktionsverlauf der veränderlichen
Zustandsgrößen über die Zeit möglichst exakt zu beschreiben. Sie werden durch Ände-
rungsgrößen (wie beispielsweise durch die Erdbeschleunigung) beeinflußt. [Gold 99]
Da der Funktionsverlauf nur an bestimmten Stützpunkten exakt gegeben ist, muß er in

den dazwischenliegenden Zeitspannen durch eine Funktion angenähert werden. Diese
Funktion erlaubt es, kontinuierlich über die Systemgrößen zu integrieren und damit den
Zustand des Systems, ausgehend von einem definierten Startzustand, für jeden Folgezeit-
punkt zu beschreiben. Die Änderungsgrößen (äußere und innere Kräfe), auf denen die
Veränderung des Systemzustandes basiert, werden jeweils für einen Zeitschritt konstant
angenommen. Zumeist lassen sie sich nicht genauer bestimmten.
2.1.2 Integrationsverfahren nach Euler

Das einfachste numerische Integrationsverfahren ist das Euler-Verfahren. Dabei wird,
von den vorhandenen Startwerten ausgehend, mit Hilfe der bekannten zeitlichen Verzö-
gerung über ein hinreichend kleines Zeitintervall linear hochgerechnet [Gold 99]. So
erhält man neue Werte für die Systemgrößen. Diese neuen Werte sind zwar nur Näherun-
gen. Bei ausreichend kleiner Schrittweite liegen sie jedoch sehr nahe an den Werten des
nachgebildeten Realsystems.
7 Physikalische Grundlagen
Beispiel:
Einem Partikel mit Masse m, Position x(t) und Geschwindigkeit v(t) wird eine Kraft F(t)
zugeführt. Das bewirkt eine Beschleunigung des Partikels von a(t) = F(t) / m. In Abhän-
gigkeit von der Geschwindigkeit v(t) und der Beschleunigung a(t) ist die Geschwindig-
keit des Partikels zum Simultaionszeitpunkt t + ∆t exakt durch die Gleichung (2.1)
bestimmt. Ebenso läßt sich die Position des Partikels zum Zeitpunkt t + ∆t durch die
Gleichung (2.2) ausdrücken.
t + ∆t
v ( t + ∆t ) = v ( t ) + ∫ a ( t ) dt (2.1)
t
t + ∆t
x ( t + ∆t ) = x ( t ) + ∫ v ( t ) dt (2.2)
t
Da der Funktionsverlauf von a(t) über den Simulationszeitschritt ∆t ist nicht bekannt ist,
lassen sich diese Integrale meistens nicht exakt bestimmen. Der Wert von a(t) ist ledig-
lich im Simulationszeitpunkt t (und in den zuvor berechneten Stützpunkten) bekannt.
Ziel des Integrationsverfahrens ist es, den „realen“ Verlauf von a(t) möglichst gut anzu-
nähern. Dazu gibt es einige numerische Verfahren. Das einfachste davon ist das Euler-
Verfahren. Dabei wird ein durch eine Differentialgleichung gegebenes Modell durch eine
Differenzengleichung angenähert. Im Grunde bedeutet das nichts anderes, als daß der
Verlauf von a(t) linear interpoliert wird. Siehe Gleichungen (2.3) und (2.4).
a ( t + ∆t ) – a ( t )
a ( t ) + -------------------------------------
2
v ( t + ∆t ) = v ( t ) + ------------------------------------------------------ (2.3)
∆t
v ( t + ∆t ) – v ( t )
v ( t ) + ------------------------------------
2
x ( t + ∆t ) = x ( t ) + ----------------------------------------------------- (2.4)
∆t
Die Qualität der Simulationsergebnisse hängt vom Modell und von der gewählten
Schrittweite ∆t ab.
Masse-Feder-Systeme 8
2.2 Masse-Feder-Systeme
Für die Radaufhängungen des Fahrzeuges werden Masse-Feder-Systeme benötigt. Diese

bestehen aus einem Massepunkt und einer Feder-Dämpfer-Einheit. Ein weiteres Feder-
element befindet sich zwischen Radaufhängung und Straße (siehe Abb. 2.1). Die Feder-
kraft F ergibt sich durch Multiplikation der Federkonstante k mit der Auslenkung der
Feder x, F = –k ⋅ x . Der Dämpfer wird durch die Gleichung F = – d ⋅ v beschrieben,
wobei der Dämpfungskoeffizient d die Stärke der Dämpfung angibt. Auf die Masse in
der Position x – ich nenne sie M – wirken folgende Kräfte:
1. Erdanziehungskraft (Gravitation) – Die Gravitationskraft F ist gleich dem Produkt

aus Masse m und der Erdbeschleunigung g, F = m ⋅ g .
2. Federkraft
3. Dämpferkraft
Abbildung 2.1: Kräftediagramm: 2-Weg-Federsystem
Aus den Kräften lassen sich mit Hilfe des d’Alembertschen Prinzips die Systemglei-
chungen aufstellen. Das Prinzip von d’Alembert [StSG 88] besagt, daß die äußeren
Kräfte und die Trägheitskraft (negative Massebeschleunigung) in einem Massepunkt
einen Gleichgewichtszustand bilden. Die Summe der im Punkt M wirkenden Kräfte kann
gleich Null gesetzt werden. Das führt zu der Gleichung (2.5). Fkr bezeichnet die Feder-
kraft aus dem Reifen.
2
m --------2- = – ( m ⋅ g ) + ( k ⋅ ∆x ) +  d ⋅ ---------- – Fkr
d x d∆x
(2.5)
 dt 
dt
Durch Umformung (Division durch die Masse) erhält man die Beschleunigung des Mas-
sepunktes. Das Integral der Beschleunigung über die Zeit ergibt die Geschwindigkeit.
Das Integral der Geschwindigkeit über die Zeit ergibt die Auslenkung des Punktes.
Abbildung 2.2: Blockschaltbild für das Masse-Feder-System
In dem Blockschaltbild (siehe Abb. 2.2) läßt sich die Rückkopplung des Systems durch
die Positionsdifferenz und die Geschwindigkeitsdifferenz zwischen Massepunkt und
Befestigungspunkt erkennen.
2.3 Drall (Impulsmoment)

Der Drehimpuls eines Reifens ist durch die Winkelgeschwindigkeit ω und das Träg-
heitsmoment I charakterisiert. Siehe Gleichung (2.6). Für den Autoreifen kann I durch
1 ⁄ 2 ⋅ m ⋅ r 2 genähert werden. m ist die Masse des Reifens, r sein Radius. Dieser Aus-
druck beschreibt die Masseträgheit eines Zylinders mit gleicher Masseverteilung (kon-
stante Dichte in jedem Punkt des Zylinders). In Gleichung (2.7) wurde I durch den ent-
sprechenden Ausdruck ersetzt.
L = I⋅ω (2.6)
1 2
L = --- ⋅ m ⋅ r ⋅ ω (2.7)
2
Das Anlegen eines Momentes bewirkt eine Änderung im Drall. Der Zusammenhang zwi-
schen dem Moment und dem Drehimpuls ist wie folgt:
Starrkörperdynamik 10
t + ∆t
L ( t + ∆t ) = L ( t ) + ∫ τ ( t ) dt (2.8)
Die Ableitung von L nach der Zeit entspricht dem Moment.
2.4 Starrkörperdynamik
Unter einem Starrkörper versteht man einen Körper, der eine räumliche Ausdehnung
besitzt aber nicht deformierbar ist. Er wird in dem später vorgestellten Automodell für
die Beschreibung des „Fahrzeugkörpers“ verwendet.
In diesem Abschnitt möchte ich grob auf die Konzepte der Starrkörperdynamik einge-
hen. Die Beschreibungen bauen auf den Unterlagen und auf den Skizzen aus [BWAK 99]
auf.
2.4.1 Position und Orientierung

Die geometrische Beschreibung des Körpers erfolgt in einem relativ zum Körper fix
gelagerten Koordinatensystem, dem Objektkoordinatensystem. Innerhalb dieses Koordi-
natensystems behalten alle nicht beweglichen Teile ihre Lage und Orientierung über die
Simulationszeit hinweg bei. Was sich im Laufe der Simulation ändert, ist die Lage des
Körpers innerhalb des Weltkoordinatensystems. Um Position und Orientierung zum
Simulationszeitpunkt t zu beschreiben, werden der Positionsvektor x(t) und die Rotati-
onsmatrix R(t) verwendet. Als Bezugspunkt für Rotation und Translation dient der
Schwerpunkt des Körpers. Da sich die meisten Starrkörper-Berechnungen damit wesent-
lich vereinfachen lassen, wird der Schwerpunkt im Nullpunkt des Objektkoordinatensy-
stemes angenommen.
Um die Position eines Punktes von Objektkoordinaten in Weltkoordinaten zu transfor-

mieren, wird die Gleichung (2.9) verwendet (siehe dazu auch Abb. 2.3). Die Rotations-
matrix R(t) gibt die Orientierung des Körpers an, x(t) seine Position. p 0 ist ein Punkt
innerhalb des Objektkoordinatensystems.
p( t) = R( t ) ⋅ p0 + x ( t ) (2.9)
Aus der Rotationsmatrix R(t) läßt sich ein sehr nützlicher Zusammenhang zwischen
Objektkoordinatensystem und Weltkoordinatensystem entnehmen: Die Spaltenvektoren
der Rotationsmatrix (2.10) entsprechen den vom Objektkoordinatensystem ins Weltkoor-
dinatensystem transformierten Koordinatenachsen des Starrkörpers. Der erste Spalten-
 r xx r yx r zx 
 
R ( t ) =  r xy r yy r zy  (2.10)
 
 r xz r yz r zz 
vektor verläuft in Richtung der transformierten x-Achse (x’), der zweite Spaltenvektor in
Richtung der transformierten y-Achse (y’) und der dritte Spaltenvektor in Richtung der
transformierten z-Achse (z’). Diese Achsen werden in Abb. 2.3 dargestellt.
Abbildung 2.3: Transformation eines Punktes vom Objektkoordinatensystem

ins Weltkoordinatensystem
2.4.2 Lineare und angulare Geschwindigkeit
Unter linearer und angularer Geschwindigkeit versteht man die Änderung von Position
und Orientierung des Körpers mit der Zeit. Die lineare Geschwindigkeit beschreibt eine
Translation des Körpers und wird wie folgt definiert:
d
v ( t ) = ----- x ( t ) = x· ( t ) (2.11)
dt
Die angulare Geschwindigkeit beschreibt die Änderung der Orientierung, R· ( t ) . Die

Rotation wird um den Masseschwerpunkt des Körpers durchgeführt. (Ansonsten würde
sich der Schwerpunkt selbst bewegen). Die Rotationsachse verläuft immer durch den
Koordinatenursprung.
Die Rotation des Körpers ist durch den Vektor ω ( t ) gegeben. Die Richtung von ω ( t )
liefert die Richtung der Rotationsachse. Die Länge des Vektors gibt seine Winkelge-
schwindigkeit an. Für die Simulation ist der Zusammenhang zwischen ω ( t ) und R· ( t )
gesucht. Er wird durch die Gleichungen (2.12) beschrieben.
R· ( t ) = ω ( t )* ⋅ R ( t ) (2.12)
* bezeichnet eine Operation auf den Vektor ω ( t ) . Diese Operation ist in (2.13) definiert.
Bei gegebenem a erhält man durch Anwendung von * die folgende Matrix:
 ax   0 – az a y 
   
a =  ay  ⇒ a* =  a z 0 – a x  (2.13)
   
 az   –ay ax 0 
Löst man Gleichung (2.12) auf, so erkennt man, daß es sich dabei um die Bildung des
Kreuzproduktes von ω ( t ) mit den drei Spaltenvektoren aus R(t) handelt. Die drei Ergeb-
·
nisvektoren bilden die Spalten der Matrix R ( t ) .
2.4.2.1 Geschwindigkeit eines Partikels im Starrkörper
Baraff et al. [BWAK 99] verwendet für die Herleitung einiger Gleichungen ein konzep-
tuelles Modell, nachdem man sich einen Starrkörper aus vielen einzelnen, dicht gepack-
ten Partikeln vorstellen kann. Für die Berechnung von Stößen ist es wichtig, die
Geschwindigkeit eines dieser Partikel berechnen zu können. Die Position des i-ten Parti-
kels im Starrkörper wird als r i ( t ) bezeichnet. Sie ist in Weltkoordinaten gegeben. Die
Verwendung von Weltkoordinaten liegt hier nahe, da die Geschwindigkeitsberechnungen
meist auf Kollisionen zurückzuführen sind. Diese werden üblicherweise in Weltkoordi-
naten berechnet. Die Geschwindigkeit des Partikels r i ( t ) wird durch Gleichgung (2.14)
beschrieben.
r· i ( t ) = ω ( t ) × ( r i ( t ) – x ( t ) ) + v ( t ) (2.14)
Man beachte, daß die Geschwindigkeit in zwei Komponenten aufgespalten ist: eine
lineare Komponente v(t) und eine angulare Komponente ω ( t ) × ( r i ( t ) – x ( t ) ) . Siehe
dazu auch Abb. 2.4.
Abbildung 2.4: Geschwindigkeit des i-ten Partikels im Strarrkörper
2.4.3 Kraft und Moment
Das im vorangegangenen Abschnitt beschriebene Partikelmodell läßt sich auch für die
Berechnung der Kräfte verwenden, die auf den Schwerpunkt des Körper wirken. Ist der
Körper Feldkräften ausgesetzt (wie z.B. Gravitation oder Wind), so wirken diese Kräfte
zu gleichen Maßen auf alle Partikel des Körpers. Greift die Kraft in einem bestimmten
Punkt des Körpers an, so wird die Kraft auf ein einziges Partikel ausgeübt. Sei Fi ( t ) die
Kraft, die zum Zeitpunkt t auf das i-te Partikel einwirkt, so kann das externe Moment auf
dieses Partikel mit Hilfe der Gleichung (2.15) bestimmt werden. Das Moment ist von
von der Position des Partikels r i ( t ) relativ zum Masseschwerpunkt x(t) abhängig.
τ i ( t ) = ( ri ( t ) – x ( t ) ) × Fi ( t ) (2.15)
Das gesamte äußere Moment ist gleich der Summe der Momente auf die Partikel. Ebenso
ist die gesamte äußere Kraft auf den Körper gleich der Summe aller Kräfte, die auf die
Partikel des Körpers ausgeübt werden. Siehe dazu Gleichungen (2.16) und (2.17). Wäh-
rend F(t) keinerlei Information darüber enthält, an welcher Stelle eine Kraft auf den Kör-
per ausgeübt wird, gibt das Moment τ ( t ) Aufschluß über die Verteilung der Kräfte über
den Körper.
F( t) = ∑ Fi ( t ) (2.16)
τ(t ) = ∑ τi ( t ) = ∑ ( r i ( t ) – x ( t) ) × Fi ( t ) (2.17)
Für die Simulation bedeutet das, daß alle angreifende Feldkräfte aufsummiert werden
können. Ebenso die Momente, die aus den Kräften in den Angriffspunkten resultieren.
Feldkräfte wie die Gravitation bewirken keinen Drall. Sie wirken direkt auf den Masse-
schwerpunkt des Körpers.
In dieser Betrachtung von [BWAK 99] wird allerdings eines vernachlässigt: Während
das i-te Partikel die gesamte Kraft zugeführt bekommt, kann auf den Schwerpunkt nur
ein bestimmter Anteil der Kraft übertragen werden. Dieser Anteil ist vom Angriffspunkt
und von der Richtung der einwirkenden Kraft abhängig. Verläuft der Kraftvektor durch
den Schwerpunkt des Körpers, so wird die gesamte Kraft auf den Schwerpunkt des Kör-
pers ausgeübt. Andernfalls muß jener Anteil abgespalten werden, der in Richtung des
Schwerpunktes verläuft. Nur dieser Anteil wird tatsächlich an den Schwerpunkt übertra-
gen. Er kann mit Hilfe der Gleichung (2.18) berechnet werden. Ich bezeichne den Kraft-
anteil, der vom i-ten Partikel auf den Schwerpunkt ausgeübt wird, als Fx i .
( x ( t ) – ri ( t ) )
Fx i = Fi ( t ) ⋅ ---------------------------------
- (2.18)
( x ( t ) – ri ( t ) )
2.4.3.1 Linearer Impuls
Aus mehreren Gründen verwendet Baraff als Zustandsvariable anstatt der Geschwindig-
keit den sogenannten linearen Impuls (engl. linear momentum) des Körpers. P(t) ist im
Grunde nichts anderes als die Masse des Körpers M mal dessen Geschwindigkeit v(t).
2.4.3.2 Angularer Impuls
Der totale angulare Impuls des Körpers ist L ( t ) = I ( t ) ⋅ ω ( t ) . I(t) ist eine 3x3-Matrix,
der Trägheitstensor. Dazu aber mehr im nächsten Abschnitt. Der Zusammenhang zwi-
schen L(t) und τ ( t ) wird durch die Gleichung (2.19) beschrieben (siehe dazu auch
Abschnitt 2.3).
L· ( t ) = τ ( t ) (2.19)
2.4.4 Trägheitsmatrix
Die Trägheitsmatrix beschreibt das Trägheitsverhalten des Körpers. Sie ist ein Skalie-
rungsfaktor zwischen angularem Impuls und Winkelgeschwindigkeit. Die Herleitung der
Trägheitsmatrix wird in [BWAK 99] näher beschrieben. Damit möchte ich mich hier
nicht auseinandersetzen. Wichtig hingegen erscheint mir die Bildung der Matrix für
einen symmetrischen Quader mit gleicher Dichteverteilung. Mit einem solchen Quader
läßt sich das Trägheitsverhalten des Fahrzeuges ausreichend genau annähern.
Der Trägheitstensor I(t) ist eine symmetrische 3x3-Matrix. Er bildet sich aus dem Inte-
gral über das Körpervolumen mit Hilfe einer Dichtefunktion ρ ( x, y, z ) . Da sich die
Trägheitsmatrix zur Simulationszeit mit der Orientierung R(t) des Körpers ändert, muß
sie in jedem Simulationsschritt neu berechnet werden. Dies wäre relativ rechenaufwen-
dig, könnte man die Trägheitsmatrix nicht zumindest für das Objektkoordinatensystem
vorberechnen. Siehe dazu Gleichung (2.20). Diese Matrix bleibt zur Laufzeit konstant.
Mit Hilfe der Gleichung (2.21) kann daraus zur Laufzeit effizient I(t) berechnet werden.
M ist die Masse des Quaders. x 0 , y 0 und z 0 sind seine Abmessungen.
 2 2 
 y0 + z0 0 0 
M  
Ibody = ------ ⋅  0
2 2
x0 + z0 0  (2.20)
12  
 2 2 
 0 0 x0 + y0 
T
I ( t ) = R ( t ) ⋅ I body ⋅ R ( t ) (2.21)
2.4.5 Bewegungsgleichungen
Der Zustand des Starrkörpers zum Zeitpunkt t wird durch räumliche Information (Posi-
tion und Orientierung) und durch Geschwindigkeitsinformation (linearer Impuls und
angularer Impuls) wiedergegeben. Der Zustandsvektors Y(t) sei definiert als (2.22).
Die Masse des Körpers und der Trägheitstensor Ibody sind Konstante. Sie sind zu Simu-
lationsbeginn bekannt. Die Hilfsvariable I(t), ω ( t ) und v(t) können mit Hilfe der Glei-
chungen (2.23) bis (2.25) aus den Zustandsgrößen berechnet werden.
P(t)
v ( t ) = ---------- (2.23)
M
 x(t) 
 
Y ( t ) =  R(t) 
P(t)  (2.22)
 
 L( t) 
T
I ( t ) = R ( t ) ⋅ I body ⋅ R ( t ) (2.24)
ω ( t ) = I ( t ) –1 ⋅ L ( t ) (2.25)
Zur Bestimmung des neuen Systemzustandes wird die Ableitung von Y(t) nach dt benö-
tigt. Das numerische Integrationsverfahren berechnet – ausgehend von einem definierten
Startzustand Y(0) – mit Hilfe der abgeleiteten Systemgrößen die neuen Systemzustände.
Diese Ableitung kann der Gleichung (2.26) entnommen werden.
 x(t )   v(t ) 
   
d-
---- Y ( t ) = ----- 
d R( t )  =  ω(t ) ⋅ R(t)  (2.26)
dt dt P( t )   F( t ) 
   
 L(t)   τ(t) 
2.4.6 Quaternions
Wenn die Rotationsmatrix R(t) im Laufe der Simulation unter Verwendung der Formel
(2.12) immer wieder erhöht wird, machen sich nach mehreren Simulationsschritten
Rechenungenauigkeiten bemerkbar. In den Koeffizienten von R(t) baut sich unwiderruf-
lich ein numerischer Fehler auf, sodaß R(t) keine präzise Rotationsmatrix mehr darstellt.
Graphisch führt die Anwendung dieser Matrix zu einer zunehmenden Verzerrung des
Körpers (skewing effect). Diese Verzerrung ist bereits nach einigen Hunderten Simulati-
onsschritten so stark, daß die Simulation nicht mehr sinnvoll fortgesetzt werden kann.
Anstelle der 3x3-Rotationsmatrix gibt es eine andere Darstellungsform für die Orientie-
rung des Starrkörpers. Und zwar Quaternions [PeWe 82]. Für ihre Darstellung reicht ein
Vektor mit vier Elementen. Dh., im Vergleich zur Orientierungsmatrix wird nur ein
zusätzlicher Parameter für die Beschreibung der drei Freiheitsgrade einer Rotation benö-
tigt. Diese geringe Redundanz in der Repräsentation führt dazu, daß der numerische Feh-
ler fast zur Gänze verschwindet. Die geringfügigen Abweichungen werden durch regel-
mäßiges Normalisieren des Quaternions ausgeglichen.
Die Darstellung der angularen Geschwindigkeit durch den Vektor ω ( t ) wird trotz Ver-
wendung der Quaternions beibehalten. Die Orientierungsmatrix R(t) wird allerdings nur
noch zu Hilfszwecken aus q(t) berechnet. Die Aktualisierung der Starrkörperorientierung
erfolgt mit Hilfe der Quaternions. Gleichung (2.27) zeigt die Ableitung eines Quaterni-
ons nach der Zeit. Die Multiplikation ω ( t ) ⋅ q ( t ) entspricht einer Multiplikation der
Quaternions [0, ω ( t ) ] und q(t). Die Definition dieser Rechenoperation ist in Anhang A
zu finden.
1
q· ( t ) = --- ω ( t ) ⋅ q ( t ) (2.27)
2
2.5 Verteilung der Auflagekräfte
Liegt der Starrkörper am Boden auf, so verteilt sich seine Gewichtskraft auf die Auflage-
fläche. Da der Körper auf vier Radaufhängungen gelagert ist, sind es vier Punkte, die das
Gewicht des Körpers tragen (oder auch weniger, wenn das Fahrzeug nicht mit allen
Rädern am Boden aufliegt). Die Punkte entsprechen den Befestigunspunkten der Rad-
aufhängung. In den Radaufhängungen werden dem Körper jene Kräfte entgegengesetzt,
die ihn am Eindringen in den Boden hindern (Tragkräfte). Sie verlaufen vertikal zum
Fahrzeug (vertikal in Objektkoordinaten), und stehen im Wechselspiel mit den Feder-
und Dämpferelementen der Radaufhängung.
2.5.1 Herleitung der statischen Verteilung
Die Verteilung der Gewichtskraft erfolgt über Momente. Unter Kenntnis der Geometrie
(Radstand, Spurweite), des Gewichtes, und der Auflagepunkte des Körpers, kann man
die Momente um den Masseschwerpunkt (bzw. um eventuell benötigte Hilfspunkte)
ansetzen. Daraus ergeben sich in weiterer Folge die Kräfte in den Auflagepunkten. Dies
funktioniert jedoch nur, wenn sich der Schwerpunkt innerhalb des von den Auflagepunk-
ten aufgespannten Polygons befindet. Andernfalls wird sein Gewicht nicht vollständig
getragen und der Körper kippt zur Seite. Für diese speziellen Fälle (eigentlich ist dies in
den meisten Auflagekonfigurationen der Fall) nähere ich die Gewichtskraft, die in der
Federung getragen wird.
Verteilung der Auflagekräfte 18
Abbildung 2.5: Herleitung der vertikalen Kräfteverteilung über Momente
Abb. 2.5 zeigt eine Konfiguration, in der der Körper getragen wird und nicht zur Seite
kippt. Die Punkte P0, P2 und P3 liegen am Boden auf. Der Punkt P1 hängt in der Luft.
Man beachte, daß der Schwerpunkt CG innerhalb des Dreiecks P0-P2-P3 liegt. CG steht
für center of gravity.
Es werden folgende Momente angesetzt:
– ( u ⋅ Fg ) = ( d2 + u ) ⋅ F2
– ( d2 ⋅ Fg ) = ( d2 + u ) ⋅ Fx
– ( x3 ⋅ Fx ) = ( x0 + x3 ) ⋅ F0
– ( x0 ⋅ Fx ) = ( x0 + x3 ) ⋅ F3 (2.28)
F0 bis F3 sind die Vertikalkräfte in den Punkten P0 bis P3, Fg ist die Gravitationskraft
im Masseschwerpunkt CG und Fx ist die Vertikalkraft im Hilfspunkt X. So lassen sich
schrittweise alle Kräfteanteile in den Auflagepunkten berechnen.
Da sich die Lage der Radaufhängungen nicht ändert, bleiben die Gewichtsverteilungen
zur Laufzeit konstant. Sie können vor Simulationsbeginn für alle möglichen Auflage-
Konfigurationen vorberechnet und in einer Tabelle abgelegt werden. So spart man sich
die Berechnungen während der Simulation. Für die Fälle, in denen der Körper getragen
wird (und nicht zur Seite kippt), müssen sich die Anteile auf 100% ergänzen. Für alle
anderen Fälle habe ich geometrisch plausible Gewichtsanteile verwendet.
2.5.2 Geometrische Interpretation und Anwendung

Im Simulationszyklus müssen nicht die Auflagekräfte berechnet werden, die sich aus der
Gewichtskraft des Körpers in den Auflagepunkten ergeben. Stattdessen muß aus den
Kräften in den Federbeinen auf eine maximale Tragkraft im Schwerpunkt des Körpers
rückgeschlossen werden. Diese maximale Tragkraft kann mit Hilfe der berechneten
Gewichtsverteilung bestimmt werden.
Angenommen, in jedem der Federbeine liegt genau jene Kraft an, die sich aus der
berechneten Verteilung ergibt (siehe Abb. 2.6, links), so wird der Körper zur Gänze
getragen. Die Summe der Momente um den Masseschwerpunkt ist gleich Null
( ∑ d i × Fi = 0 ). Der Körper befindet sich im Gleichgewicht.
Abbildung 2.6: Geometrische Interpretation der vertikalten Kräfteverteilung:

Tragkraft und Drehmoment
Liegt an nur an einer (oder mehreren) der Aufhängungen eine größere Kraft an, als jene,
die dem berechneten Anteil entspricht, so resultiert daraus ein Drehmoment um den
Schwerpunkt des Körpers (siehe Abb. 2.6, rechts). Die Tragkraft im Schwerpunkt erhöht
sich nur, wenn die Kraft in allen(!) Auflagepunkten verstärkt wird.
Um die maximale Tragkraft zu ermitteln, muß zunächst die Kraft in jedem der vier Auf-
lagepunkte ermittlet werden. Sie kann aus den Feder- und Dämpferelementen der Rad-
aufhängung ausgelesen werden. Betrachtet man einen der Auflagepunkte, so kann die
Kraft in diesem Punkt auf eine theoretische Gewichtskraft im Schwerpunkt des Starrkör-
pers zurückgeführt werden. Dazu wird die Auflagekraft durch den jeweiligen Anteil der
Gewichtsverteilung dividiert. Als Ergebnis erhält man einen theoretischen Wert, der als
Ursache für die Kraft in dem Federbein betrachtet werden kann. Liegt der Körper an vier
Punkten auf, werden auf diese Weise vier unterschiedliche Werte ermittelt.
Da für jeden der Punkte die selbe Gewichtsverteilung gilt, kann sichergestellt werden,
daß das Minimum der ermittelten Gewichtskräfte in jedem der aufliegenden Punkte
getragen wird. Dh., die Tragkraft, die aus den Anteilen in den Auflagepunkten resultiert,
ist gleich dem Minimum aller Fg i , wobei Fg i gleich Fi , dividiert durch den vorberechne-
ten Kraftanteil im Aufhängungspunkt Pi . i ∈ { 0, 1, 2, 3 } .
Da der Körper auf Federn gelagert ist, und die Federbeine während der Fahrt nicht gleich
weit einfedern (Bodenunebenheiten, Beschleunigung durch Antrib/Bremse/Kurvenlage,
etc.), wird üblicherweise in jedem Simulationsschritt ein Drall erzeugt. Ohne äußere
Krafteinwirkung sollte sich der Drall – aufgrund der Dämpfungseigenschaften der Rad-
aufhängung – auf Null einpendeln.
Übertragung der Horizontalkräfte 20
2.6 Übertragung der Horizontalkräfte

So, wie die Rückführung der Auflagekräfte, ist auch die Rückführung der horizontalen
Kräfte von der Geometrie des Fahrzeuges abhängig. Die horizontalen Kräfte können nur
zu jenen Teilen an den Schwerpunkt übertragen werden, die durch die geometrische
Anordnung der Räder vorgegeben sind.
Für die Berechnung der Kraft auf den Schwerpunkt werden je zwei Geraden betrachtet:
zwei in Längsrichtung des Fahrzeuges, und zwei in Querrichtung des Fahrzeuges. In
Längsrichtung werden die Longitudinalkräfte der beiden linken und der beiden rechten
Reifen aufsummiert. In Querrichtung sind es die Lateralkräfte der beiden Vorderreifen
und der beiden Hinterreifen (siehe Abb. 2.7). Die Kräfteverteilung ergibt sich aus dem
Teilungsverhältnis, in dem der Schwerpunkt das Fahrzeug in Längsrichtung und in Quer-
richtung teilt. Der Kraftanteil im Schwerpunkt des Fahrzeuges wird analog zu
Abschnitt 2.5.2 ermittelt.
Liegt der Schwerpunkt auf halber Breite des Fahrzeuges, so resultiert eine Kraft von
Fl = Fr = 1000 N in einer Längskraft von 2000 N auf den Schwerpunkt des Fahrzeuges.
Sind es auf der rechten Seite 1100 N, so ist die Gesamtkraft ebenfalls nur 2000 N. Die
„überschüssigen“ 100 N bewirken einen Drehimpuls des Fahrzeuges.
Abbildung 2.7: Rückführung der Antriebs- und der Seitenkräfte auf den
Schwerpunkt des Starrkörpers
Zur Bestimmung der Kräfteverteilung werden folgende Momente angesetzt:
–( lb ⋅ Flong ) = ( lb + lf ) ⋅ Ff
– ( bl ⋅ Flat ) = ( bl + br ) ⋅ Fr (2.29)
Die Lage (die Höhe) des Schwerpunktes wird aufgrund der geringen Höhendifferenz in
der Übertragung der Horizontalkräfte der Einfachheit halber vernachlässigt.
2.7 Stoßübertragung
Wenn zwei Körper aufeinanderprallen kommt es zur Übertragung eines Stoßes. Klassi-
sche Beispiel hierfür sind zwei Billiardkugeln. Prallen die Kugeln aufeinander kommt es
zu einer plötzlichen Geschwindigkeitsänderung der beiden Massekörper. Je nach Bewe-
gungsrichtung, Geschwindigkeit und Materialbeschaffenheit der Kugeln ergeben sich bei
einem solchen Zusammenprall unterschiedliche Abprallwinkel und -geschwindigkeiten.
In Bezug auf die Simulation spricht man auch von einer Diskontinuität in der Geschwin-
digkeit der Körper. Während sich lineare und angulare Geschwindigkeit bei der Aus-
übung von Kräften immer nur kontinuiertlich verändern können (aufgrund der Masse-
trägheit sind keine Geschwindigkeitssprünge möglich!) kommt es bei der Übertragung
von Stößen zu genau diesen Sprüngen in der Geschwindigkeit. Mit den bisher vorgestell-
ten Konzepten von Kraft und Masse kommt das der Zuführung einer unendlich großen
Kraft über einen unendlich kleinen Zeitraum hinweg gleich.
Die Integration muß zum genauen Zeitpunkt der Kollision angehalten werden. Dieser
Zeitpunkt ist genau dann eingetreten, wenn sich die Oberflächen der beiden Körper
berühren. Er kann numerisch bis zu einer gewissen Genauigkeit angenähert werden.
Anschließend wird der Stoß berechnet. Dies geschieht unter Verwendung der Systemgrö-
ßen, die zum Zeitpunkt der Kollision anliegen. Aufgrund der Zuführung des Stoßes muß
schließelich die Simulation neu gestartet werden. Der Startzustand wird durch die neu
ermittelten Geschwindigkeiten und Positionen festgelegt.
Für die Beschreibung des Sprungverhaltens in der Geschwindigkeit wird die Größe J
eingeführt. J wird auch als Stoß bezeichnet. Er erzeugt eine abrupte Geschwindigkeitsän-
derung eines Körpers. Der Stoß ist eine Vektorgröße, so wie die Kraft F. Nur wird er in
der selben Einheit wie der Impuls angegeben. Bei einem Körper mit Masse M läßt sich
die Änderung der Geschwindigkeit durch folgenden Zusammenhang darstellen:
J
∆v = ----- (2.30)
M
Die Änderung des linearen Impulses ∆P drückt sich aus durch ∆P = J .
Verläuft die Linie der Stoßübertragung durch die Masseschwerpunkte der beiden betei-
ligten Körper (wie beispielsweise bei zwei Kugeln) kann man den Stoß mit Hilfe von
Gleichung (2.31) berechnen. Hierbei wird – unter Vernachlässigung der Reibung – kein
Drehimpuls übertragen.
– ( 1 + ε ) ⋅ v rel
J = --------------------------------- (2.31)
1 - ------ 1
------ + -
Ma M b
Stoßübertragung 22
ε ist der Stoßübertragungskoeffizient, v rel ist die relative Annäherungsgeschwindigkeit

der beiden Körper. Ma und Mb sind die beiden beteiligten Massen. Je nach Materialbe-
schaffenheit wird ein Teil des Stoßes von den Körpern absorbiert. ε = 0 würde bedeu-
ten, daß die gesamte kinetische Energie des Stoßes beim Zusammenstoß der beiden Kör-
per umgewandelt wird. Die relative Annäherungsgeschwindigkeit der beiden Körper
nach dem Aufprall ist gleich null. Bei ε = 1 hingegen bleibt die Geschwindigkeitsdiffe-
– die relative Annähe-
renz in Stoßrichtung nach der Kollision zur Gänze erhalten. Sei v rel
rungsgeschwindigkeit vor dem Zusammenstoß und v rel + die Geschwindigkeit unmittel-
bar nach dem Stoß, so kann man den Zusammenhang wie folgt ausdrücken:
+ = –ε ⋅ v –
v rel (2.32)
rel
2.7.1 Stoßberechnung für den Starrkörper

Wird der Stoß auf einen beliebigen Punkt p eines Körpers ausgeübt (und nicht in gerader
Linie durch den Masseschwerpunkt), so bewirkt der Stoß neben der Geschwindigkeits-
änderung auch eine Änderung des Drehimpulses.
Betrachten wir zunächst den allgemeinen Fall: die Kollsision von zwei Starrkörpern. Ich
nenne sie Körper A und Körper B (siehe Abb. 2.8). Die vorgestellten Konzepte basieren
auf dem zweiten Teil der Ausarbeitungen von Baraff [BWAK 99]. Die Skizzen sind dem
Paper entnommen.
Um die Geschwindigkeit der Kollisionspunkte p a ( t 0 ) und pb ( t 0 ) der Körper A und B

zum Kollisionszeitpunkt t 0 zu bestimmen, werden die Zustandsgrößen der beiden Kör-
per in die Gleichung (2.14) aus Abschnitt 2.4.2.1 auf Seite 12 eingesetzt. Man erhält die
Ausdrücke (2.33) und (2.34). Die Punkte p a ( t 0 ) und p b ( t 0 ) – die zum Zeitpunkt t 0 dek-
kungsgleich im Punkt p liegen – werden in Weltkoordinaten angegeben.
Abbildung 2.8: Position der Starrkörper A und B vor dem Zeitpunkt der Kollision
(links), und zum Kollisionszeitpunkt t 0 (rechts)
p· a ( t0 ) = v a ( t 0 ) + ω a ( t 0 ) × ( p a ( t 0 ) – x a ( t 0 ) ) (2.33)
p· b ( t0 ) = v b ( t 0 ) + ω b ( t 0 ) × ( p b ( t 0 ) – x b ( t 0 ) ) (2.34)
Bei der Kollision der beiden Körper ist zwischen drei Formen des Kontaktes zu unter-
scheiden: dem Punkt-Fläche-Kontakt, dem Kante-Fläche-Kontakt und dem Fläche-Flä-
che-Kontakt. Je nach vorliegender Kontaktform wird der Impuls zu unterschiedlichen
Teilen in die beiden Körper zugeführt. Für die Simulation ist jedoch ausschließelich der
Punkt-Fläche-Kontakt relevant.
Abbildung 2.9: Annäherungsgeschwindigkeit der Starrkörper A und B

(Punkt-Fläche-Kontakt)
Kollidiert ein Punkt des Körpers A mit einem Punkt in der Fläche des Körpers B (siehe
Abb. 2.9), so kann man die Normale n̂ auf die Oberfläche von B als Stoßübertragungs-
achse betrachten. Der Stoß pflanzt sich ausschließlich entlang dieser Achse fort. Normal
dazu (in der Normalebene auf n̂ ) findet keine Stoßübertragung statt. Hier kann es ledig-
lich aufgrund von Reibungskräften zu einer zusätzlichen Beeinflussung der Körper kom-
men. Die Reibung möchte ich in diesen Betrachtungen jedoch ausklammern.
Da der Impuls in Richtung der Normalen n̂ ( t 0 ) übertragen wird, kann man J umschrei-
ben als:
J = j ⋅ n̂ ( t 0 ) (2.35)
Die Herleitung für j ist nicht ganz trivial. Ich werde daher nur den feritgen Ausdruck
anführen. Näheres ist bei [BWAK 99] nachzulesen. Die Gleichung (2.36) zeigt den Term
Stoßübertragung 24
für die Berechnung von j. Die Entfernungen r a und r b seien definiert als p – x a ( t 0 ) und
p – x b ( t 0 ) . In Abb. 2.10 wird die Anwendung des Stoßes auf die beiden Körper gra-
phisch veranschaulicht.
–
– ( 1 + ε ) ⋅ v rel
j = -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- (2.36)
1 1
------- + ------- + n̂ ( t 0 ) ⋅ ( I a–1 ( t 0 ) ⋅ ( r a × n̂ ( t 0 ) ) ) × r a + n̂ ( t 0 ) ⋅ ( I b– 1 ( t 0 ) ⋅ ( r b × n̂ ( t 0 ) ) ) × r b
Ma M b
Abbildung 2.10: Anwendung des Stoßes auf die Körper A und B
Angenommen, A ist kein Starrkörper, sondern eine punktförmige Masse, dann läßt sich
der Ausdruck (2.36) auf (2.37) reduzieren ( r a = p – x a ( t0 ) = 0 ). Im Modell besitzen
die Massen der Radaufhängung keine räumliche Ausdehnung. Aus diesem Grund kann
die Übetragung von Stößen auf diese Weise berechnet werden. Körper-Körper-Kollisio-
nen müssen nur bei der Kollision von zwei Fahrzeugen zu berechnet werden.
–
– ( 1 + ε ) ⋅ v rel
j = -------------------------------------------------------------------------------------------------------------- (2.37)
1 - ------ 1
------ + - + n̂ ( t 0 ) ⋅ ( I b–1 ( t 0 ) ⋅ ( r b × n̂ ( t 0 ) ) ) × r b
Ma M b
2.7.2 Kollisionsabfragen
Die Berechnung von Kollisionen und Kollisionspunkten zwischen zwei frei beweglichen
Körpern ist relativ aufwendig. Für eine effektive Berechnung werden Bounding-Boxes
und andere geometrische Abstraktionsverfahren eingesetzt. Außerdem gilt es – wie
bereits erwähnt –, zwischen unterschiedlichen Formen des Kollisionskontaktes zu unter-
scheiden. In [BWAK 99] wird ein relativ effizientes Konzept für die Kollisionsabfrage
zwischen mehreren Starrkörpern vorgestellt. Da ich es für meine Modellierung des Auto-
Boden-Verhaltens jedoch nicht benötige (die bisweilen einzige Kollisionsabfrage findet
zwischen Reifen und Straße statt) möchte ich mich damit nicht näher beschäftigen.
2.8 Reibung
Wenn sich zwei Objekte in einer Kontaktstelle (oder in mehreren Kontaktstellen) berüh-
ren und eine horizontale Kraft auf diese Kontaktstelle ausgeübt wird, treten Reibkräfte
auf. Nehmen wir als Beispiel einen Quader, der auf ebenem Untergrund aufliegt (siehe
Abb. 2.11). Dieser Quader wird durch die Kraft N auf den Boden gedrückt. N ist der
Anteil der Gewichtskraft, der normal zur Bodenoberfläche verläuft. Beim Anlegen einer
Kraft F bildet sich in der Auflagefläche die Reibkraft f, die der Kraft F entgegenwirkt.
Sie vehindert, daß der Körper über die Oberfläche zu rutschen beginnt (Haftreibung).
Vergrößert man F, so erreicht die Gegenkraft f irgendwann eine Schwelle, die sie nicht
überschreiten kann. Ab dem Zeitpunkt beginnt der Quader über die Oberfläche zu gleit-
gen (Gleitreibung). Er wird durch die Reibkraft f gebremst.
Abbildung 2.11: Reibkraft in der Kontaktfläche eines Quaders
In welchem Zustand der Reibung sich ein Körper gerade befindet (Haftreibung oder
Gleitreibung) kann man mit Hilfe der Relation (2.38) feststellen. µs ist der statische
Reibkoeffizient. Er beschreibt das Reibverhalten zwischen zwei unterschiedlichen Mate-
rialien im Zustand der Haftreibung.
F ≤ µs ⋅ N (2.38)
Reibung 26
Bis zu dem Grenzwert F = µs ⋅ N halten sich die horizontale Kraft und die Reibkraft
die Waage ( f = fs = F ). Der Körper wird in seiner Position gehalten. Übersteigt F den
Grenzwert, so beginnt der Körper zu rutschen. Die Reibkraft f k für die kinetische Rei-
bung (oder Gleitreibung) ist bei gleichem Auflagegewicht N konstant:
f k = µk ⋅ N (2.39)
Abb. 2.12 zeigt den idealisierten Zusammenhang zwischen horizontaler Kraft F und
Reibkraft f bei konstanter Auflagekraft N. In der Realität verläuft diese Kennlinie nicht
linear. Für die Modellierung des Reibverhaltens reicht der lineare Zusammenhang aller-
dings aus.
Abbildung 2.12: Zusammenhang zwischen horizontaler Kraft und Reibkraft
Eine Auflistung von Reibwerten findet man beispielsweise in [Dubb 90], B 15, Tabelle
4, oder in [Bosc 97]. Die folgende Tabelle wurde aus unterschiedlichen Quellen zusam-
mengestellt.
Material µs µk
Stahl auf Stahl 0,7 0,6
Messing auf Stahl 0,5 0,4
Kupfer auf Gußeisen 1,1 0,3
Glas auf Glas 0,9 0,4
Tabelle 2.1: Reibwerte
Material µs µk
Teflon auf Teflon 0,04 0,04
Teflon auf Stahl 0,04 0,04
Gummi auf Beton (trocken) 1,0 0,8
Gummi auf Beton (naß) 0,30 0,25
Formel-1 Reifen auf trockenem 1,7 —
Asphalt
Guter Autoreifen auf trockenem 1,1 1,0
Asphalt
Durchschnittlicher Autoreifen 0,9 0,8
auf trockenem Asphalt
Gekerbter Autoreifen auf naßem 0,8 0,7
Asphalt
Glatziger Reifen auf naßem 0,5 0,4
Asphalt
Tabelle 2.1: Reibwerte
Reibung 28
Kapitel 3
Das Fahrzeugmodell
3.1 Allgemeines
Für die Simulation von Fahrzeugen werden üblicherweise Mehrkörper-Modelle verwen-
det. Bei diesen Modellen ist jede bewegliche Masse durch einen Starrkörper nachgebil-
det. Durch das Hinzufügen unterschiedlicher Verbindungen (Federn, Dämpfer, Gelenke,
...) werden die Körper zu einem System zusammengefügt. Die kinematischen Eigen-
schaften des Systems werden durch die Eigenschaften der Körper (Masse, Geometrie,
Trägheit, Bewegungseinschränkungen), durch die Verbindung der Körper untereinander,
und durch deren geometrische Anordnung bestimmt.
Die Bewegungsfreiheit des Modells wird in Freiheitsgraden (engl. Degrees of Freedom,
kurz DOF) gemessen. Jede Achse im orthogonalen Koordinatensystem, entlang der ein
Körper transliert werden kann, wird als ein Freiheitsgrad gezählt. Ebenso jede Achse, um
die der Körper rotiert werden kann. Ein frei im Raum beweglicher Körper besitzt sechs
Freiheitsgrade.
In [SaHa 95] wird ein generisches Mehrkörper-Modell in 18 Freiheitsgraden beschrie-

ben. Es besteht aus einem Hauptkörper mit sechs Freiheitsgraden. Vier weitere Körper
beschreiben die vertikale Bewegung der Radaufhängungen (je ein Freiheitsgrad). Die
Räder sind an die Aufhängung gekoppelt, können aber durch das Einfedern seitlich weg-
gedrückt werden. Sie besitzen je zwei Freiheitsgrade.
Die Anordnung der Komponenten habe ich aus [SaHa 95] übernommen. Um die Imple-
mentierung weitgehend zu vereinfachen, verwende ich jedoch nur einen einzigen Starr-
körper. Dieser beschreibt die Masse des Autos als Verbund von Karosserie, Motorblock,
Radaufhängung und Rädern. Die anderen Starrkörper werden als punktförmige Massen
betrachtet. Sie sind in ihrer Bewegungsfreiheit auf eine Dimension beschränkt. Ihre Posi-
tion kann in einer Dimension widergegeben werden. (Ebenso die Ableitungen der Posi-
29
Aufbau 30
tion nach der Zeit.) Die dreidimensionale Interpretation wird über den Zustand des
Modells hergeleitet. Die Reifen besitzen nur einen Freiheitsgrad (Rotation).
Obwohl die Starrkörperdefinition alle Teilkomponenten zu einer einzigen Masse zusam-

menfaßt, müssen für Räder und Radaufhängungen eigene Massen definiert werden. Für
die Modellierung der Masse-Feder-Systeme, und für die Berechnung von Stoßübertra-
gungen ist dies unverzichtbar. Geht man davon aus, daß Radaufhängung und Räder einen
Bruchteil der gesamten Fahrzeugmasse ausmachen, so lassen sich die aus der Vereinfa-
chung resultierenden Ungenauigkeiten in der Simulation vernachlässigen. Die Vereinfa-
chungen betreffen im Wesentlichen folgende Punkte:
• Die von Rädern und Aufhängung getragene Masse wird fälschlicherweise mit der
Gesamtmasse des Fahrzeuges angenommen (der Starrkörper umfaßt alle Masseteile
des Fahrzeuges!). Dadurch werden die Federn etwas mehr beansprucht, als vorgese-
hen. Die Dynamik des Fahrzeuges wird dadurch jedoch nur geringfügig beeinflußt.
• Die Auslenkung der Federbeine verursacht eine geringfügige Masse-Umverteilung

innerhalb des Starrkörpers. Diese Umverteilung würde eine Neuberechnung der Träg-
heitsmatrix erfordern, kann jedoch – aufgrund des verschwindend kleinen Einflußes
auf das Laufzeitverhalten des Fahrzeuges – ignoriert werden.
Im folgenden Abschnitt betrachte ich den schematischen Aufbau des Modelles. Die
Grundlagen für die physikalische Modellierung der Komponenten wurden in Abschnitt 2
gelegt. Abschnitt 3.3 beschreibt die Kopplung dieser Komponenten. Neben der Umset-
zung der Mechanik wird im Anschluß auf die Modellierung von Motor, Getriebe und
Reifen eingegangen.
3.2 Aufbau
Das Fahrzeugmodell setzt sich aus Karosserie, Radaufhängung und Reifen zusammen.
Zur Karosserie zähle ich den gesamten Fahrzeugaufbau. Die Radaufhängung wird durch
eine Masse (einfedernde Teile), ein Federelement und einen Stoßdämpfer beschrieben.
Die Reifen sind durch je eine Masse und ein Federelement modelliert. Die Feder
beschreibt den Widerstand bei der Verformung des luftgefüllten Gummireifens. Eine
genaue Anordnung der Komponentens ist Abb. 3.1 zu entnehmen. Die Darstellung lehnt
sich an [BeHa 78] an.
Durch die strichlierte Linie wird angedeutet, daß sich der „virtuelle“ Starrkörper nicht
mit dem Aufbau des Fahrzeuges deckt. Karosserie und Starrkörper unterscheiden sich
sowohl in ihrer Position, als auch in ihrer Ausdehnung. Ihre Lage zueinander bleibt
jedoch über die Simulationszeit hinweg konstant. Deshalb wird der Starrkörper von mir
der Einfachheit halber oft auch als Karosserie bezeichnet. Da Position und Orientierung
von Starrkörper und Karosserie fix miteinander gekoppelt sind, macht es keinen Unter-
schied, welche der beiden Bezeichnungen ich zukünftig verwende. Die Radaufhängun-
gen sind an vordefinierten Positionen an der Karosserie (am Starrkörper) montiert.
31 Das Fahrzeugmodell
Abbildung 3.1: Frhrzeugmodell schematisch (Seitenansicht)
3.3 Kopplung der Komponenten

Die Komponenten sind über Bezugspunkte aneinander gekoppelt. In der Karosserie gibt
es vier Punkte, an denen die Federn und Dämpfer der Radaufhängung mit der Karosserie
verbunden sind. Die Aufhängungspunkte ändern sich im Laufe der Simulation nicht. Sie
können weder nachgeben, noch bei zu starker Belastung brechen. Es handelt sich um
eine starre, undurchtrennbare Verbindung. Die Verbindung der Räder mit dem Masse-
punkt der Aufhängung ist ebenfalls untrennbar. Die Position eines Rades wird durch die
Auslenkung der Radaufhängung vorgegeben.
Eine eventuelle Abhängigkeit zwischen zwei Rädern durch die Geometrie der Radauf-
hängung wird nicht berücksichtigt. Es gibt keine Aspekte, welche die Lage der Räder
zueinander beeinflussen (starre Vorder- und/oder Hinterradachse). Die Räder sind ein-
zeln aufgehängt. Sie können sich innerhalb des Federweges frei nach oben und unten
bewegen. Der Weg, der vom Rad beim Einfedern der Aufhängung beschrieben wird, ver-
läuft entlang einer Geraden.
Kopplung der Komponenten 32
3.3.1 Kraftübertragungszyklus
Zur Laufzeit werden zwischen den Fahrzeugkomponenten Kräfte ausgetauscht: Liegen

die Räder am Boden auf, so kommt es zur Stauchung der Feder im Reifenmodell. Es ent-
steht eine Kraft, die proportional zur Auslenkung der Feder ist. Diese Kraft wird entlang
der Federungsachse abgetragen und der Radaufhängung zugeführt. Die Federn und
Dämpferelemente werden beansprucht. Die Stauchung der Federn im Reifen und in der
Aufhängung erzeugt eine Kraft, die auf die Karosserie ausgeübt wird.
Aufgrund der Gravitation wird der Starrkörper (inklusive aller Federmassen und Reifen)
nach unten beschleunigt. Liegt das Fahrzeug mit seinen vier Rädern am Boden auf, muß
die Gravitationskraft von einer Gegenkraft in der Waage gehalten werden. Ansonsten
würde das Fahrzeug im Boden versinken oder – bei zu großer Gegenkraft – abheben.
Diese Gegenkraft (engl. Liftforce) wird durch die darunterliegenden Federkomponenten
(Luftreifen, Radaufhängung) erzeugt. Durch die Kompression der Luft im Reifen (=
Federstauchung) und durch die Auslenkung der Radaufhängung wird eine Kraft auf den
Starrkörper ausgeübt. Die Summe der Kräfte, die sich in Reifen und Radaufhängung
gebildet haben, hindert das Fahrzeug am Eindringen in den Boden.
Betrachtet man Abb. 3.1, so richtet sich diese Kraft korrekterweise auf die Karosserie.
Da das Modell keine Unterscheidung zwischen Karosserie und Verbundkörper vorsieht,
ergeben sich daraus gewisse Ungenauigkeiten. Die Masse, die von Radaufhängung und
Reifen getragen werden muß, ist zu hoch. Das kann jedoch durch die Verwendung einer
größeren Federkonstante kompensiert werden.
3.3.2 Bodenkontakt
Wird von einem Simulationszeitpunkt zum nächsten eine Eindringung der Räder in den
Boden festgestellt, so hat zwischen diesen Zeitpunkten ein Bodenkontakt stattgefunden.
Für die Simulation ist das insofern von Bedeutung, als ab dem Zeitpunkt der Kollision
neben der Schwerkraft eine weitere Kraft auf das Auto wirkt. Sie ist der Schwerkraft
(korrekterweise der Auflagekraft) engegengerichtet und hält das Fahrzeug auf der
Bodenoberfläche.
Um eine Bodenkollision rechnerisch korrekt aufzulösen, muß das numerische Integrati-

onsverfahren zum genauen Zeitpunkt der Kollision abgesetzt und – mit neuen Initialwer-
ten – erneut gestartet werden (siehe Abschnitt 2.7). Der exakte Kollisionszeitpunkt läßt
sich durch ein Bisektionsverfahren annähern – eine exakte Bestimmung ist nicht mög-
lich. Das Akzeptanz-Intervall für einen gefundenen Kollisionszeitpunkt kann frei
gewählt werden.
Ich verwende in meiner Simulation 2500 Simulationsschritte pro Sekunde. Das bedeutet,
daß ein Simulationszeitpunkt nie weiter als 1 ⁄ 2500 sec von einem exakten Kollisions-
zeitpunkt abweichen kann. Auf eine zusätzliche mathematische Annäherung kann –
zugunsten der Laufzeiteffizienz – verzichtet werden. Eine feinere Bestimmung des Kol-
lisionszeitpunktes würde keine wesentlichen Auswirkungen auf das Simulationsverhal-
ten haben.
3.3.2.1 Geometrische Interpretation des Reifen-Boden-Kontaktes
Das Einfedern des Reifens im Modell wird auf eine einzige Federachse zurückgeführt.
Diese Federachse kann – je nach Art des Bodenkontaktes – unterschiedlich ausgerichtet
sein (siehe Abb. 3.2).
Betrachten wir vorerst die zweidimensionale Situation: Beim Schnitt des Reifens mit
ebenem Boden verläuft die Federachse normal zur Bodenoberfläche (Abb. 3.2, links und
Mitte). Auf unebenem Boden können für einen Reifen auch mehrere Normaleindringun-
gen vorliegen (Abb. 3.2, rechts). Wurde mehr als eine Eindringung festgestellt, so müs-
sen die Eindringungsvektoren auf einen einzigen Vektor abgebildet werden. Dies
geschieht durch Mittelung aller vorliegenden Werte. Als Gewichtung wird die Teife der
Eindringungen verwendet. Die Federachse wird entlang des gemittelten Vektors ange-
nommen.
Da die Simulation nicht zweidimensional, sondern dreidimensional aufgebaut ist, bedeu-

tet die Berechnung aller Normaleindringungen, daß der Reifen als Kugel betrachtet wird.
Auch wenn dieser Ansatz auf den ersten Blick etwas befremdend wirkt, so liefert er doch
für die meisten Fälle recht gute Ergebnisse. Ein Reifen wird nur in wenigen Fällen so
schräg seitlich am Boden aufsetzen, daß die Kräfteentwicklung entlang der ermittelten
Achse nicht mit der Visualisierung des Fahrzeuges vereinbar ist.
Für eine differenzierte Betrachtung des Reifens ist eine genauere Annäherung an die Rei-
fengeometrie erforderlich. Folgende Möglichkeiten bieten sich an: Kugelschnitt, Torus,
Zylinder. Die Reifengeometrie muß gegen alle umliegenden Bodenpolygone getestet
werden.
Abbildung 3.2: Kräfteentwicklung durch den Boden-Reifen-Kontakt
3.3.3 Kollisionsabfragen
Bei der Interaktion des Fahrzeuges mit dessen Umgebung spielen Kollisinen eine wich-
tige Rolle. Kollisionen entstehen, wenn die (starre) Außenhülle des Fahrzeuges mit
einem anderen Massekörper kollidiert. Sowohl Reifen als auch Karosserie sind davon
betroffen und müssen in jedem Simulationsschritt auf Kollisionen überprüft werden.
Die häufigste Form der Kollision betrifft den Reifen-Boden-Kontakt: Jedesmal, wenn
der Reifen über den zulässigen Federweg hinaus in den Boden eindringt, wird ein Stoß
vom Boden an den Reifen übertragen. Federt die Radaufhängung bis zum Anschlag ein,
so pflanzt sich der Stoß bis in den Fahrzeugrahmen fort. Aber auch, wenn das Fahrzeug
seitlich mit dem Reifen den Randstein touchiert, wird dadurch ein Stoß auf den Fahr-
Rad-Straße-Verhalten 34
zeugrahmen ausgeübt. Gerät das Fahrzeug außer Kontrolle, so kann es passieren, daß es
sich überschlägt und mit den umliegenden Objekten kollidiert. Für diesen Fall sollte die
Kollision der Karosserie mit dem Boden (oder mit anderen Objekten) abgefragt werden.
Aus Zeitgründen beschränkt sich die vorliegende Implementierung auf die Abfrage und
die Berechnung des Reifen-Boden-Kontaktes und aller daraus resultierenden Kräfte und
Stöße. Sowohl Kräfte als auch Stöße pflanzen sich über die Radaufhängung bis hinauf
zur Karosserie des Fahrzeuges fort und verhindern ein Eindringen des Fahrzeuges in den
Boden.
3.3.4 Starrkörper-Feder-Kopplung
Die Lagerung des Starrkörpers stützt sich auf die Kräfteverteilung, die in Abschnitt 2.5
vorgstellt wurde. Durch die Auslenkung der (am Boden aufliegenden) Federbeine läßt
sich die Tragkraft im Schwerpunkt des Starrkörpers berechnen, und das Drehmoment um
den Schwerpunkt des Starrkörpers bestimmen.
Die Auflage auf den Federbeinen wird – analog zu der in [BWAK 99] getroffenen Unter-
scheidung zwischen „resting contact“ und „colliding contact“ – als resting contact
behandelt, – also als ruhender Kontakt. Die Federn üben keinen Stoß sondern eine konti-
nuierliche Kraft auf die Aufhängungspunkte aus. Erst, wenn aufgrund einer zu hohen
Aufprallgeschwindigkeit der Federweg in einer der Radaufhängungen überschritten
wird, und die Massen aufeinanderstoßen, kommt es zur Übertragung von Stößen. Stöße
bewirken eine Diskontinuität in der Simulation. Sie werden als Spezialfall behandelt.
3.4 Rad-Straße-Verhalten
In den Kontaktflächen zwischen Reifen und Boden (diese Kontaktfläche wird in der
Fachliteratur auch als „Latsch“ bezeichnet) ergeben sich zur Laufzeit Reibungskräfte,
die das Fahrverhalten des Fahrzeuges maßgeblich beeinflußen. Das Problem bei der
genauen Bestimmung der Reibkräfte liegt darin, daß der Reifen deformierbar ist. Ein
Luftreifen wird durch die Radlast eingedrückt. Dadurch verkleinert sich sein Abrollra-
dius. Das wiederum wirkt sich auf die Abrollgeschwindigkeit in der Kontaktfläche aus.
Sie ist kleiner als jene, die sich aus Reifenradius und Winkelgeschwindigkeit bei einem
gleich großen Holzrad ergeben würde. Zusätzlich zur vertikalen Verformung kann sich
der Reifen aber auch horizontal verformen (Kippmoment) oder eindrehen (Bohrmo-
ment). Um diese Deformationen und die daraus resultierenden Kräfteentwicklungen im
Modell zu beschreiben ist ein aufwendiger Modellierungsansatz nötig.
In dem vorliegenden Modell werden nur jene Kräfte betrachtet, die sich aufgrund der
horizontalen Beschleunigungen des Reifens ergeben. Der Reifenradius wird konstant
angenommen.
3.4.1 Bodenhaftung
Die Kraft, die der Autoreifen auf die Straße übertragen kann, ist proportional zur Radlast
und wird durch die Reibeigenschaften des Reifenmaterials begrenzt. Betrachtet man den
Reifen bei konstanter Radlast, so kann das Haftungsverhalten mit Hilfe des Kamm’schen
Kreises [DIN50323] veranschaulicht werden (siehe Abb. 3.3). Der Autoreifen hält einer
gewissen Kraft stand. Übersteigt die Kraft am Reifen das Haftungslimit, beginnt er aus-
zubrechen.
Nutzt man die gesamte Kraft für die Beschleunigung, kann der Reifen keine Seitenkräfte
übertragen. Beim leichtesten Lenkeinschlag würde der Reifen zu rutschen beginnen. In
maximaler Kurvenlage hingegen wird die gesamte Kraft für die Seitenführung benötigt.
Gasgeben oder Bremsen führt zum Ausbrechen des Reifens.
Abbildung 3.3: Kamm’scher Kreis
Um festzustellen, ob ein Reifen die volle Bodenhaftung hat oder nicht, muß die berech-
nete Kraft in der Bodenkontaktfläche gegen die maximal zulässige Reibkraft zwischen
Reifen und Untergrund getestet werden. Eine relativ realistische Modellierung der
Bodenhaftung liefert die sogenannten „Pacejka Magic Formula“. Sie gibt die horizontale
Belastbarkeit eines Reifens für unterschiedliche Schlupfwinkel1 und Radlasten wieder.
In Beckman’s The Physics of Racing-Serie [Beck 01], Teil 21 und Teil 22 findet man
dazu genauere Erläuterungen. Longitudinal- und Lateralkräfte werden getrennt betrach-
tet. Für die Longitudinalversion der Formel werden elf Kenngrößen des Reifens benö-
tigt. Für die Lateralversion der Formel vierzehn. [Beck 01] entnimmt diese Größen aus
[Gent 97]. Sie beziehen sich auf die Hafteigenschaften eines im Rennsport verwendeten
Reifen auf Asphalt.
Für die Geländesimulation können diese Kennlinien nicht direkt übernommen werden.
Zum einen hat ein Geländereifen andere Hafteigenschaften als der relativ klebrige Rei-
fen aus dem Beispiel von [Beck 01]. Zum anderen ist die Bodenhaftung des Reifens auf
jedem Untergrund verschieden. Möchte man die Formel anwenden, so müßten sämtliche
1. Winkel zwischen der Längsachse und der Beweungsrichtung des Reifen

Lenkung 36
Kenngrößen geschätzt werden. Aus diesem Grund wird die Bodenhaftung mit Hilfe der
in Abschnitt 2.8 vorgestellten Zusammenhänge modelliert: Bis zu einer gewissen
Schwelle (Kraftvektor innerhalb des Kreises, Abb. 3.3) ist die Reibkraft in der Boden-
kontaktfläche gleich der seitlichen Kraft. Übersteigt die Kraft am Reifen das Haftungsli-
mit ( F ≥ N ⋅ µ s ) geht der Reifen in den Zustand der Gleitreibung über. Die maximale
Kraft, die der Reifen in diesem Zustand auf die Straße übertragen kann, liegt bei
F = N ⋅ µk .
3.4.2 Rollwiderstand
Aufgrund der Verformung des Reifens, die während der Abrollbewegung beobachtet
werden kann, ergibt sich eine Widerstandskraft, die dem Drehimpuls des Reifens entge-
genwirkt. Mit zunehmender Geschwindigkeit steigt der Rollwiderstand annähernd linear
an und wirkt der Rollbewegung des Reifens entgegen. Er kann durch die Wahl eines
geeigneten Multiplikationsfaktors modelliert werden. Monster beschreibt die Herleitung
des Faktors auf der Internet-Seite Car Physics for Games [Mons 01].
Bei der Berechnung des Rollwiederstandes muß außerdem die Radlast miteinbezogen
werden. Der ermittelte Multiplikationsfaktor gilt bei ebener Auflage des Fahrzeuges.
Lastet auf einem Reifen eine größere Last, so steigt der Rollwiderstand in diesem Reifen
an.
Da die Antriebs- und Bremskräfte in den Reifen über Momente spezifiziert werden, ist es
naheliegend, den Rollwiderstand ebenfalls über ein Moment in das System zuzuführen.
Das Gesamtmoment am Reifen ergibt sich aus der Summe von Antriebsmoment, Brems-
moment und Rollwiderstandsmoment.
Im Skriptum der Fachhochschule Regensburg für Fahrzeugdynamik [Rill 01] ist die
Berechnung des Rollwiderstandsmomentes über Radlast, Reifenradius und Rollwider-
standsbeiwert zu finden. Der Zusammenhang der Größen wird in Gleichung (3.1) aufge-
zeigt. Der Rollwiderstandsbeiwert ist in einem Bereich von 0, 010 ≤ f R ≤ 0, 025 anzu-
nehmen. Fg ist die Radlast und r der Reifenradius. Skaliert man f R in Abhängigkeit von
der Geschwindigkeit des Reifens, so ergeben sich ähnliche Werte wie bei [Mons 01].
Fg ⋅ f R
MRW = --------------
- (3.1)
r
3.5 Lenkung
Um das Auto in eine Kurvenbahn zu lenken, müssen die Räder des Fahrzeuges in einem
geeigneten Winkel eingeschlagen werden. Dadurch kommt es zur Entwicklung von Sei-
tenführungskräften, die das Fahrzeug in eine Kurvenbahn zwingen.
Oftmals werden die Reifen aber nicht nur um die Höhenachse, sondern auch um die
Längsachse eingeschlagen. Die Schrägstellung des Reifens soll für eine bessere Kom-
pensation der Seitenkräfte sorgen. Solche Schrägstellungen werden hier nicht berück-
sichtigt.
Neben der Bestimmung eines geeigneten des Lenkwinkels in Abschnitt 3.5.1 werden in
Abschnitt 3.5.2 jene Kräfte behandelt, die beim Lenkvorgang zwischen Rädern und
Boden auftreten.
3.5.1 Ackerman-Lenkung
Wird das Fahrzeug in eine Kreisbahn gelenkt, so hat der Reifen auf der Kurveninnenseite
eine kleinere Kreisbahn zu beschreiben als der Reifen auf der Kurvenaußenseite. Des-
halb ist es sinnvoll, den Innenreifen beim Lenken stärker einzuschlagen. Der exakte
Lenkwinkel für jedes der Räder läßt sich mit Hilfe der Ackermann-Bedingung herleiten.
(siehe [Dubb 90], Q 21, „5.6 Lenkungen“). Sie besagt, daß sich die Achsen der vier
Räder beim Lenken in einem Schnittpunkt treffen müssen. Dadurch wird sichergestellt,
daß die Reifen konzentrischen Kreisbahnen um den Mittelpunkt des Wendekreises fol-
gen (siehe Abb. 3.4). Solange das Fahrzeug nicht aus seiner Spur ausbricht, wird damit
die bestmögliche Bodenhaftung erreicht.
Aus der Länge des Radstandes und dem Wendekreisradius können die Winkel der Räder
ausgerechnet werden. Eine detaillierte Herleitung der Winkel folgt in Abschnitt 6.1.9 auf
Seite 87.
Abbildung 3.4: Lenkprinzip nach Ackerman
3.5.2 Lenkkräfte
Durch den Lenkeinschlag der Reifen und die Vorwärtsbewegung des Autos ergeben sich
in den Kontaktflächen zwischen Reifen und Boden Reibungskräfte, die das Auto in eine
Kurvenbahn zwingen:
Angenommen, ein Auto bewegt sich entlang des Geschwindigkeitsvektors v, so können

nur jene Reifen diese Geschwindigkeit zur Gänze in eine Rollbewegung umsetzen, deren
Antrieb 38
Laufrichtung parallel zum Geschwindigkeitsvektor verläuft. Ein Rad, dessen Laufrich-

tung von der Bewegungsrichtung des Fahrzeuges abweicht, kann nur einen Teil der
Geschwindigkeit in eine Rollbewegung umsetzen. Den Geschwindigkeitsanteil, der vom
Reifen abgerollt wird, bezeichne ich als v long . Er wird in Longitudinalrichtung des Rei-
fens abgetragen. Normal dazu steht der laterale Geschwindigkeitsanteil v lat . Er verläuft
in der Bodenebene im Auflagepunkt des Reifens (siehe Abb. 3.5).
Abbildung 3.5: Aufspaltung des Geschwindigkeitsvektors am Reifen
Der laterale Geschwindigkeitsanteil kann einer seitlichen Beschleunigung des Reifens

gleichgesetzt werden. Bei Bewegung des Fahrzeuges entlang des Geschwindigkeitsvek-
tors baut sich von einem Simulationspunkt zum nächsten eine Positionsdifferenz von der
– durch den Lenkeinschlag vorgegebenen – Kreisbahn auf. (Aufgrund der Diskretisie-
rung der Zeit verläuft die Kreisbahn eigentlich nicht entlang eines Kreises, sondern ent-
lang eines Vielecks.) Die Positionsdifferenz wird durch Integration der Lateralgeschwin-
digkeit innerhalb des betrachteten Simulationszeitschrittes beschrieben. Da sich die
Lateralgeschwindigkeit in der Zeitspanne von 0 auf v lat erhöht, kommt v lat einer seitli-
chen Beschleuingung des Reifens gleich.
Aus der seitlichen Beschleunigung und aus der Auflagekraft wird die Kraft berechnet,
die lateral auf den Reifen wirkt. Zusammen mit der Kraft aus Antrieb, Bremse und Roll-
widerstand wird daraus der Kraftvektor in der Auflagefläche des Reifens ermittelt. Das
ist jener Vektor, der gegen die maximal zulässige Reibkraft getestet werden muß, um ein
Ausbrechen der Reifen feststellen zu können (siehe Abb. 3.3).
Die Auflagekraft ist gleich der Stauchung der Federn in Reifen und Radaufhängung.
Durch die Rückkopplung der Masse-Feder-Systeme mit dem Boden und mit dem Starr-
körper pendelt sich diese Kraft auf einen realistischen Wert ein.
3.6 Antrieb
Der Antieb des Fahrzeuges besteht aus dem Motor, der Getriebe-Übersetzung und den
Antriebsreifen. Das vom Motor produzierte Drehmoment ist von seiner Umdrehungszahl
abhängig. Es wird durch das Getriebe von der Kurbelwelle auf die Antriebsreifen über-
tragen. Die Antriebsreifen bringen das Moment auf die Straße und beschleunigen das
Fahrzeug.
Die Rückkopplung zwischen Motor und Antriebsreifen wird über die Drehzahl der Rei-
fen hergestellt. (Motor und Reifen sind im eingekuppelten Zustand fix miteinander ver-
bunden!) Wird das Fahrzeug beschleunigt, so ändert sich die Drehzahl der Räder. Der
Motor wird in einen neuen Drehzahlbereich versetzt und liefert ein neues Anstriebsmo-
ment.
Für die Simulation wäre es wünschenswert, den Zusammenhang zwischen Motordreh-

zahl und Drehmoment durch eine Funktion oder durch ein System zu beschreiben. Da
ein Verbrennungsmotor in seinem Aufbau relativ komplex ist, ist es jedoch nicht einfach,
geeignete Gleichungen zu finden. Neben der Mechanik spielt hier die Verbrennungstech-
nik eine wesentliche Rolle. Aus diesem Grund wird die sogenannte Drehmomentkurve
verwendet, um das Laufzeitverhalten des Motors zu beschreiben. Die Drehmomentkurve
gibt den Zusammenhang zwischen Drehzahl und Drehmoment bei einer bestimmten
Stellung des Gaspedals wieder. Sie ist eine charakteristische Kennlinie, die von Motor zu
Motor unterschiedlich aussieht.
Die Drehmomentkurven werden meist von den Automobil- und Motor-Herstellern veröf-
fentlicht. Mitsubishi stellt beispielsweise eine recht umfangreiche Broschüre als Pres-
seinformation zum Lancer Evolution VII zur Verfügung [Mits 02]. Sie enthält neben
zahlreichen technischen Details auch Informationen zur Motorisierung des Fahrzeuges.
3.6.1 Drehmomentkurve
Die Drehmomentkurve eines Motors gibt Aufschluß über das erzeugte Drehmoment bei
einer bestimmten Umdrehungszahl. Dieser Zusammenhang wird in einem zweidimen-
sionalen Diagramm als Kennlinie eingetragen (siehe Abb. 3.6). Da diese Kennlinie typi-
scherweise nur für den Vollast-Betrieb des Motors angegeben wird, ist es nötig, die
Drehmomentkurve für den Teillastbetrieb zu skalieren.
Abbildung 3.6: Beispiel für eine Drehmomentkurve

Antrieb 40
3.6.1.1 Skalierung der Drehmomentkurve
Kennt man die Kennlinien des Motors bei unterschiedlicher Treibstoffzufuhr nicht, so
kann man sich damit behelfen, die 100 %-Kennlinie für den Teillastbetrieb zu skalieren.
Bei geringerer Treibstoffzufuhr und gleicher Umdrehungszahl liefert der Motor ein nied-
rigeres Drehmoment. Es kann wie folgt berechnet werden: Um das Drehmoment für den
Teillastbetrieb anzupassen, muß die Vollastkurve gegen die X-Achse eines im Uhrzeiger-
sinn rotierten Koordinatensystems skaliert werden (siehe Abb. 3.7). Rotationsmittel-
punkt und Drehwinkel werden fix angenommen. Sie bestimmen die Ausprägung der
Teillastkurven. Diese Skalierung kann für jede beliegibe Gasstelung zwischen 0 und
100% durchgeführt werden. So lassen sich sehr realitätsnahe Kurven für den Motor
berechnen. Mit dem Winkel und dem Drehpunkt muß man etwas experimentieren. Die
maximale Motordrehzahl wird durch die Stellung des Gaspedals abgegrenzt.
Abbildung 3.7: Skalierung der Drehmomentkurve
In der Skizze wurde die Vollastkurve auf eine Teillast von 50% und auf eine Teillast von
0% skaliert. Dabei fällt auf, daß die Teillast-Kurven im höheren Drehzahlbereich stark in
den negativen Bereich fallen können. Dieser Effekt ist bis zu einem gewissen Grad
erwünscht, da sich damit die Motorbremswirkung beschreiben läßt. Da das negative
Moment mitunter sehr groß werden kann, muß eine Untergrenze für das Drehmoment
eingeführt werden.
Um zur Laufzeit CPU-Zeit zu sparen, kann man die Teillast-Kurven vorberechnen. Die
Betrachtung einiger Stützpunkte (zB alle 500 RPM) ist ausreichend. Während der Simu-
lation werden die Zwischenwerte linear interpoliert.
3.6.2 Getriebe
Ein Benzinmotor hat üblicherweise einen nutzbaren Drehzahlbereich von 1000 bis 6000
Umdrehungen pro Minute und liefert ein Drehmoment von etwa 150 bis 400 Nm. Durch
das Getriebe werden sowohl das Drehmoment als auch die Drehzahl des Motors skaliert.
Die Kombination aus Gang und Differential bewirkt, daß das Drehmoment von der Kur-
belwelle bis hin zu den Antriebsreifen vervielfacht wird. Gleichsam wird die Umdre-
hungszahl auf einen Bruchteil der Motordrehzahl herabgesetzt. Das Übersetzungsver-
hältnis läßt sich mit Hilfe der Gangschaltung auswählen.
Dazu ein kleines Rechenbeispiel:
Basierend auf den Angaben in Tab. 3.1 läßt sich für die Antriebsräder im ersten Gang ein
Übersetzungsfaktor von 3,5 * 3,6 = 12,6 bestimmen. Dh., für eine Umdrehung der Räder
muß der Motor 12,6 Umdrehungen leisten. Gleichsam erhöht sich das Drehmoment in
den Reifen auf das 12,6-fache dessen, was an der Kurbelwelle anliegt. Nehmen wir ein
Drehmoment von 190 Nm bei einer Umdrehungszahl von 3500 Umdrehungen pro
Minute an. Das Auto hat eine Masse von 1140 kg. Der Reifen hat einen Radius von
0,33 m. Außerdem wird der Übersetzungsfaktor für das Drehmoment durch Reibungs-
verlußte im Getriebe etwas abgeschwächt. Typischerweise kann man die Getriebe-Effizi-
enz mit etwa 70 bis 90 % annehmen. Das ergibt eine Antriebskraft von 190 * 3,5 * 3,6 *
0,7 / 0,33 = 5078,2 N in der Auflagefläche. Damit kann man eine Masse von 1140 kg mit
4,45 m/s beschleunigen. Das entspricht 0,45 g.
Gleichsam bewirkt das Getriebe eine Verminderung der Drehzahl. Bei 3500 Umdrehun-
gen pro Minute an der Kurbelwelle und einem Übersetzugsverhältnis von 12,6 : 1 erhält
man eine Reifendrehzahl von 3500 / 60 / 12,6 = 4,6 Umdrehungen pro Sekunde. Da die
Reifendrehzahl direkt mit der Fortbewegungsgeschwindigkeit des Autos gekoppelt ist,
kann man daraus die Geschwindigkeit des Autos ableiten (natürlich nur, soferne der Rei-
fen volle Bodenhaftung hat). Die Umdrehungszahl multipliziert mit dem Reifenumfang
ergibt eine Geschwindigkeit von 9,6 m/s. Das sind etwa 34,6 km/h.
Gang Übersetzung
1 3,50 : 1
2 2,20 : 1
3 1,50 : 1
4 1,10 : 1
5 0,94 : 1
Differential- 3,60 : 1
getriebe
Tabelle 3.1: Getriebeübersetzung eines Alpha Romeo. Quelle: [Mons 01]
3.6.2.1 Kupplung
Die Kupplung sorgt für die Verbindung zwischen Antrieb und Rädern. Bei voll durchge-
tretener Kupplung gibt es keine Verbindung zwischen Motor und Antriebsrädern. Bei
Antrieb 42
losgelassener Kupplung ist die Verbindung voll hergestellt. Für die Rückkopplung der
Antriebsräder mit dem Motor muß dieser Faktor berücksichtigt werden. Wird die
Geschwindigkeit des Autos (aufgrund von Masseträgheit, Rollwiderstand oder Luftwi-
derstand) verringert, verringert sich auch die Drehzahl der Reifen. Im eingekuppelten
Zustand füht dies zu einer direkten Veränderung der Motordrehzahl.
Jeder, der einmal die Fahrschule besucht hat, weiß, daß die Masseträgheit des Fahrzeu-
ges dem Motor zum Verhängnis werden kann: Kuppelt man zu rasch ein, stirbt der Motor
entweder ab, oder man produziert einen „Kavalier-Start“. Um zu verhindern, daß der
Motor in der Simulation absterben kann, wird die Drehmomentkurve entsprechend ange-
paßt. Setzt man das Drehmoment vor dem Beginn des nutzbaren Drehzahlbereiches auf
einen Wert größer Null, so kann die Drehzahl des Motor nie auf Null abfallen.
Die Kupplung ist als multiplikativer Faktor modelliert, der die Übertragung des Drehmo-
ments an die Reifen skaliert. 0 entspricht dem ausgekuppelten Zustand. 1 bedeutet, die
Verbindung zum Motor ist voll hergestellt. Neben der Übertragung des Antriebsmomen-
tes wird der Kupplungsfaktor auch bei der Rückführung der Reifendrehzahl berücksich-
tigt.
3.6.3 Rückkopplung von Motor und Antriebsreifen
Für die Berechnung der Traktionskräfte wird zwischen freilaufenden Rädern unterschie-
den, und Rädern, die an den Antrieb gekoppelt sind. Als freilaufend gelten alle Räder,
die permanent oder temporär vom Antriebsstrang entkoppelt sind. Im ausgekuppelten
Zustand, und im Leerlauf, sind das alle vier Räder.
Ist ein Gang eingelegt und die Verbindung zum Motor hergestellt, wird das Drehmoment
des Motors über die Reifen auf die Straße übertragen. Im Zustand der Haftreibung kann
die daraus resultierende Traktionskraft ohne Verlust auf die Straße übertragen werden.
Im Zustand der Gleitreibung nur ein Teil davon. In beiden Fällen bewirkt die Traktions-
kraft eine Beschleunigung des Fahrzeuges. Seine Geschwindikgeit verändert sich. Neben
der Geschwindigkeit des Fahrzeuges ändert sich (aufgrund des Bodenkontaktes) aber
auch die Drehzahl der Räder. Da die Reifen über das Getriebe mit dem Antrieb verbun-
den sind folgt daraus eine Änderung der Motordrehzahl. Der Motor liefert im nächsten
Simulationsschritt ein neues Drehmoment. Dieses wird über die Reifen auf die Straße
übertragen, bewirkt eine Beschleunigung des Fahrzeuges, und der Zyklus beginnt von
vorne.
Bei Bodenkontakt und voller Haftung der Antriebsreifen bereitet dieser Ansatz keine
nennenswerten Probleme. Anders sieht das im Zustand der Gleitreibung aus. Welche
Reifendrehzahl kann man hier für die Rückkopplung zum Motor verwenden? Es besteht
kein direkter Zusammenhang zwischen Rotationsgeschwindigkeit des Reifens und der
Geschwindigkeit des Autos. Nicht ganz ohne Probleme ist auch die Betrachtung des
Motors im entkoppelten Zustand. Die Reifendrehzahl hat hier keinerlei Einfluß auf das
Laufverhalten des Motors. Mögliche Lösungen für diese beiden Probleme möchte ich im
Folgenden kurz besprechen.
3.6.3.1 Verhalten im Leerlauf
Das Leerlaufverhalten des Motors läßt sich am besten Mittels einer Schwungmasse in
den Griff bekommen. Diese wird beim Gasgeben mit dem Drehmoment des Motors ver-
orgt und baut aufgrund dessen einen Drehimpuls auf. Ansonsten würde man beim Gas-
geben kein Hochdrehen des Motors beobachten können. Nimmt man das Gas weg, redu-
ziert sich die Umdrehungszahl (aufgrund der aus der Drehmomentkurve entnommenen
Motorbremswirkung) wieder.
3.6.3.2 Bestimmung der Drehzahl bei Gleitreibung
Da sich der Zustand der Gleitreibung irgendwo zwischen „keinem Bodenkontakt“ und
„statischer Reibung“ einordnen läßt, habe ich nach einem Ansatz gesucht, der diesen
Zustand wiederspiegelt. Befinden sich die Antriebsreifen in der Luft, dienen sie – so wie
die Schwungmasse des Motors, die ich zu Hilfszwecken eingeführt habe – zur Speiche-
rung des Motordrehmomentes. Bei vollem Bodenkontakt hingegen geben sie die exakte
Geschwindigkeit des Autos (entlang der Laufrichtung des Reifens) wieder.
Unter dieser Annahme erscheint es als sinnvoll, die Drehzahl der Reifen auf einen Wert
zu schätzen, der irgendwo zwischen der Drehzahl bei keinem Bodenkontakt und der
Drehzahl bei Haftreibung liegt. Als Skalierungsfaktor wird das Verhältnis von „angeleg-
tem Drehmoment“ zu „auf die Straße übertragenem Drehmoment“ verwendet. Damit
bewegt sich die Drehzahl eines durchdrehenden Reifens immer in einem plausiblen Wer-
tebereich.
3.7 Bremse
Die Bremse ist als Scheibenbremse modelliert. Durch das Andrücken der Bremsklötze
an die Bremsscheibe wird ein Moment erzeugt, das der Rotation des Reifens entgegen-
wirkt. Es berechnet sich aus dem Radius der Bremsscheibe mal der Reibkraft der Brems-
klötze. Die Reibkraft ist gleich der anliegenden Bremsdruck mal dem Reibkoeffizienten
µ.
Um eine Bremskraftverteilung vorzunehmen, kann man unterschiedlich große Brems-

scheiben verwenden. In der Autoindustrie ist diese technische Realisierung üblich. Da
man im Modell nicht auf technische Umsetzbarkeit achten muß, ist es einfacher, den
Bremsdruck prozentuell auf die vier Radbremsen zu verteilen.
3.8 Simulationszyklus
Aufgrund von Datenabhängigkeiten bei der Berechnung von Zustandsvariablen und
Hilfsgrößen muß darauf geachtet werden, die einzelnen Simulationsschritte in richtiger
Reihenfolge auszuführen. Dabei müssen gewisse Abfolgen eingehalten werden:
1. Unmittelbar nach der Zustandsüberführung des Starrkörpers werden mit Hilfe von
Kollisionsabfragen die Angriffspunkte von Kräften und Stößen ermittelt.
Simulationszyklus 44
2. Die Berechung und Übertragung von Kräften beginnt in den Reifen und setzt sich
über die Federung bis hinauf zum Starrkörper fort.
3. Die Modellierung des Motors verlangt es, zuerst das Antriebsmoment des Motors auf
die Straße zu übertragen. Dann folgt die Zustandsüberführung des Starrkörpers. Das
Auslesen der Reifendrehzahl und dessen Rückkopplung mit der Motordrehzahl kann
erst unter Kenntnis der neu berechneten Starrkörper-Geschwindigkeit erfolgen.
Der daraus resultierende Simulationszyklus ist in Abb. 3.8 dargestellt.
Abbildung 3.8: Simulationszyklus

3.9 Physikalisches Modell und Geometrie
Während die Geometrie die Form des Fahrzeuges beschreibt, die Form der einzelnen
Teilkomponenten und deren Anordnung zueinander, ist das physikalische Modell für die
Dynamik des Fahrzeuges verantwortlich. Dynamik und Geometrie stehen in enger
Beziehung zueinander, da die Dynamik maßgeblich von Form und Anordnung der Kom-
ponenten beeinflußt wird.
Zur Visualisierung des Fahrzeuges werden Visualisierungsdaten benötigt. Diese können

die Geometrie des Fahrzeuges mehr oder weniger genau wiedergeben. Die Rundung
eines Reifens wird meist durch ein Vieleck beschrieben, die Karosserie durch ein Gitter,
das sich zwischen Oberflächenpunkten des Fahrzeuges aufspannt und dessen Form
approximiert. Liegt keine genauere Geometriebeschreibung vor, werden die Visualisie-
rungsdaten mit den Geometriedaten des Fahrzeuges gleichgesetzt. Bei Polygonmodellen
ist der Körper durch die Polygone und durch deren Normalvektoren ausreichend spezifi-
ziert.
Für Kollisionsabfragen mit der Karosserie werden die Normalen an die Oberfläche des
Fahrzeugkörpers benötigt. Liegen mehrere Detailstufen der Visualisierungsdaten vor,
lassen sich genaue Schnittberechnungen nur in der höchsten verfügbaren Auflösung
berechnen. Für eine effiziente Abfrage der Kollisionen ist es jedoch ratsam eine mög-
lichst niedrige geometrische Auflösung zu verwenden. Sie muß nur den groben Umriß
des Fahrzeuges wiedergeben. Auf diese Weise läßt sich einiges an CPU-Zeit einsparen.
Das physikalische Modell beschränkt sich auf wenige Koordinatenpunkte. Das sind die
Verbindungspunkte der einzelnen (beweglichen) Komponenten. Für die Statik des Fahr-
zeuges ist die relative Lage der Aufhängungspunkte zum Masseschwerpunkt des Kör-
pers von Bedeutung. Zudem wird durch die Lage des Schwerpunktes das Fahrverhalten
maßgeblich beeinflußt. Die Gewichtsverteilung zwischen Vorder- und Hinterrädern beim
Beschleunigen und beim Bremsen hängt von der Lage des Schwerpunktes ab. Auch das
Kurvenverhalten des Fahrzeuges. Da der Masseschwerpunkt üblicherweise nicht im geo-
metrischen Mittelpunkt der Karosserie liegt, deckt sich die Ausdehnung des Starrkörpers
nicht mit der Ausdehnung der Karosserie (siehe Abb. 3.9). Das ist aber nicht von Bedeu-
tung. Wichtig ist, daß das Trägheitsverhalten des Fahrzeuges durch den Quader reali-
stisch angenähert wird.
Abbildung 3.9: Verwendung des Starrkörpers im Fahrzeugmodell

Physikalisches Modell und Geometrie 46
Durch geeignete Wahl von Lage und Größe des Starrkörpers kann das gewünschte Träg-
heitsverhalten gut nachgebildet werden. Die Verbindungspunkte von Karosserie und
Radaufhängung, bzw. von Radaufhängung und Reifen (in der Abbildung als schwarze
Punkte dargestellt) stehen mit dem Starrkörper nur insofern in Verbindung, als durch
dessen Lage die Gewichtsverteilung auf die Auflagepunkte bestimmt wird. Im oben
abgebildeten Fall wäre es ratsam, die Hinterachse stärker zu federn, als die Vorderachse,
da dort das größte Gewicht getragen wird.
Kapitel 4
Visualisierung des Terrains
4.1 Allgemeines
Für die effiziente Echtzeitdarstellung von Geländedaten gibt es eine Vielzahl von Algo-
rithmen. Das Quadtree-basierte Verfahren von Röttger et al. [RHSS 97], der ROAM
Algorithmus [DWSM 97], oder das Verfahren zum Real-Time Continous Level of Detail
Rendering of Height Fields von Lindstrom et al. [LCRH 96] (auch kurz CLOD genannt)
sind nur ein paar der bekanntesten. Diese Algorithmen basieren auf regulären Gitter-
strukturen. Das heißt, die Triangulierung der Geländedaten folgt einem vorgegebenem
Grundraster. Daneben gibt es auch Verfahren zur Generierung von irregulären Netzen.
Diese möchte ich hier aber nur der Vollständigkeit halber erwähnen. Sie sind – aufgrund
des Implementierungsaufwandes – für meine Zwecke als Overkill zu betrachten.
Ziel der unterschiedlichen Visualisierungsverfahren ist es, die Anzahl der Dreiecke, die
durch die Render Pipeline [D3DP 98] geschickt werden, auf ein Minimum zu reduzieren.
Eine erste Reduktion der Daten wird durch die Triangulierung des Geländes erreicht.
Durch die Verwendung unterschiedlicher Detailstufen kann die Anzahl der Dreiecke
stark herabgesetzt werden. Die Algorithmen versuchen genau das zu erreichen, ohne
dabei gröbere Qualitätseinbußen in der Darstellung zu verbüßen. Das primäre Entschei-
dungskriterium für die Detailreduktion ist üblicherweise die Entfernung der Gelände-
punkte zum Betrachter. Da die „Pixelgröße“ eines Dreiecks mit zunehmender Distanz
von der Kamera abnimmt, können weiter entfernte Regionen mit geringerem Detailgrad
wiedergegeben werden, ohne daß die Qualität der Darstellung merklich darunter leidet.
Ein weiteres Kriterium stellen die Unebenheiten im Gelände dar. Eine ebene Fläche kann
mit weniger Polygonen dargestellt werden, als eine stark zerklüftete Region. Um ein
augenfälliges Umschalten zwischen zwei Detailstufen während des Durchwanderns der
Landschaft zu vermeiden, sollte man die Höhenabweichungen, die bei der Detailreduk-
47
Quadtree-Verfahren nach Röttger 48
tion unebener Geländeregionen entstehen können, in die Level of Detail1 (LOD)-Ent-

scheidung miteinbeziehen.
Im Idealfall werden nur jene Dreiecke an die Pipeline übergeben, die im betrachteten
Landschaftsausschnitt auch tatsächlich zu sehen sind. Deshalb ist es sinnvoll, weitere
Techniken zur Minimierung der Datenmenge einzusetzen. Durch die Entfernung aller
Dreiecke, deren Oberfläche von der Kamera wegzeigt (Backface Culling), durch den
Test der Dreiecke gegen die Blickpyramide (Frustum Culling) und die Entfernung von
verdeckten Dreiecken (Occlusion Culling) lassen sich einige weitere Dreiecke einsparen,
die für die Darstellung der Szene nicht benötigt werden. Auf diese Weise nähert man sich
einer minimalen Menge von Dreiecken, die zur Darstellung des Terrains benötigt wird.
Im Folgenden werden zwei Quadtree-basierte Algorithmen zur Visualisierung von

Geländedaten vorgestellt: Das Quadtree-Verfahren nach Röttger, und das Verfahren von
Boer unter Verwendung von „Geometrischem Mipmapping“. Letzteres wird ausführli-
cher behandelt, da es in der vorliegenden Implementierung eingesetzt wird.
4.2 Quadtree-Verfahren nach Röttger

Röttger [RHSS 97] beschäftigt sich im wesentlichen mit der Triangulierung des Gelän-
des und dem Aufbau eines Quadtrees, nach dem die Triangulierung vorgenommen wer-
den kann. Da jede Verfeinerung des Quadtrees gleichbedeutend einer Verfeinerung des
Geländedetails ist, und sich zwei benachbarte Quadtree-Zellen maximal um eine Detail-
stufe unterscheiden dürfen, legt Röttger sein Hauptaugenmerk auf die Findung eines
geeigneten Verfeinerungskriteriums. Zwei Aspekte fließen in das Kriterium mit ein: Der
Abstand der Gelände-Zellen zum Betrachter und die Unebenheiten im Gelände. In einem
ersten Durchlauf wird das Gelände analysiert und der Quadtree aufgebaut. In einem
zweiten Durchlauf werden die Geländedaten mit Hilfe des Quadtrees auf dem Bild-
schirm ausgegeben.
In einer unvollständigen Implementierung, in der die LOD-Entscheidung für die Trian-

gulierung ausschließlich aufgrund der Distanz zum Betrachter erfolgt, arbeitet dieses
Verfahren relativ laufzeiteffizient. Abb. 4.1 zeigt den Algorithmus im Einsatz. Dort aller-
dings, wo größere Unebenheiten in der Landschaft auftreten, können die Hügel etwas
kantig aussehen. Auch ist ein leichter Gelände-“Popping“ Effekt (also ein wahrnehmbars
Hüpfen zwischen zwei LOD-Zuständen einer Geländeregion) bemerkbar. Röttger führt
aus diesem Grund die sogenannten „d2-Werte“ als Maß für Oberflächenunebenheiten
ein. Sie repräsentieren den maximalen Höhenfehler, der aufgrund einer Detailänderung
passieren kann.
Leider bringt die Hinzunahme der d2-Werte in meiner Implementierung Geschwindig-

keitseinbußen von bis zu 40% mit sich. Deshalb verwende ich statt des Algorithmus von
1. Die geometrische Detailreduktion von 3-dimensionalen Objekten wird erstmals in [Clar 76] erwähnt.
Clark verwendet für die einzelnen Versionen der Objekte die Bezeichnung Levels Of Detail. Dieser
Terminus wird seither häufig im Zusammenhang mit unterschiedlichen Geometrie-Auflösungen
verwendet.
49 Visualisierung des Terrains
Röttger ein anderes Verfahren, das im Grunde relativ ähnlich funktioniert. Es nennt sich
Geometrical Mipmapping und ist im Hinblick auf heute verwendete Render-Hardware
dem Verfahren von Röttger vorzuziehen.
Abbildung 4.1: Gelände-Triangulierung unter Verwendung des Quadtree

Algorithmus mit Distanz-basiertem LOD
4.3 Geometrical Mipmapping

Auf älteren Computersystemen (die noch keine Hardware Transformationen unterstüt-
zen) kann man durch die Auswahl einer möglichst minimalen Menge an Visualisierungs-
daten kostbare CPU Zeit einsparen. Mit der Verlagerung der rechenintensiven Vertex-
Transformationen von der CPU auf die GPUs heutiger Graphikkarten (NVidia bietet
Hardware Transform and Lighting ab der GeForce2) ist es nicht mehr so wichig, eine
möglichst optimale Menge an Dreiecken an die Hardware zu schicken. Wichtiger
erscheint es, ein möglichst schnelles Verfahren zur Sichtbarkeitsentscheidung und zur
Triangulierung der Geländedaten zu finden, und damit die CPU zu entlasten. So werden
zwar einige „überflüssige“ Dreiecke an die Hardware geschickt. In Anbetracht der Lei-
stungsfähigkeit heutiger Graphikkarten lassen sich damit aber dennoch höhere Bildwie-
derholfrequenzen erzielen.
Der Algorithmus von Boer [Boer 00] versucht genau diese Aspekte zu berücksichtigen.
Ihm liegt, so wie auch dem Verfahren von Röttger et al., die Verwendung einer Quadtree-
Struktur zugrunde. Diese hat sich für schnelle Sichtbarkeitsentscheidungen bewährt.
4.3.1 Das Prinzip
Beim Geometrical Mipmapping wird die Landschaft in sogenannte „Terrainblöcke“

unterteilt. Ein Terrainblock ist nichts anderes, als eine Untermenge der Vertexdaten, die
aus einem quadratischen Ausschnitt des Grundrasters entnommen wird. Die Terrain-
Geometrical Mipmapping 50
blöcke besitzen alle die gleiche Auflösung. Sie überlappen sich nicht. Abb. 4.6 auf Seite
57 zeigt einen Terrainblock mit einer Auflösung von 5x5 Vertices. Die Auflösung kann
frei gewählt werden. Man sollte jedoch darauf achten, daß die Seitenlänge des Terrain-
blocks ein ganzzahliger Teiler der Seitenlänge des Grundrasters ist. Dadurch wird eine
komplette Flächendeckung garantiert. Bei einer Landschaftsgröße von 257x257 Vertices
hat sich eine Auflösung von 17x17 Vertices bewährt. Die Wahl der richtigen Auflösung
kann die Ausgabegeschwindigkeit maßgeblich beeinflußen.
Ein kleiner Nachteil bei der Verwendung von Geomipmaps liegt in der Aufteilung der
Daten. Da die Vertices in den vier Kanten eines Terrainblocks mit den umliegenden
Blöcken geteilt werden, werden sie mehrmals transformiert. Der Anteil der Vertices, die
die Transformationsstufen mehrmals durchlaufen müssen, ist von der Kantenlänge und
damit von Größe der Terrainblöcke abhängig.
Jeder der Terrainblöcke kann in unterschiedlichen Detailstufen dargestellt werden. In

Analogie zum Texture Mipmapping Verfahren ist es Aufgabe des Algorithmus, eine
geeignete Detailstufe für jeden einzelnen der zu zeichnenden Blöcke zu finden. Um den
Datendurchsatz an die Hardware möglichst gering zu halten, sollte dies eine möglichst
niedrige Detailstufe sein. Auf der anderen Seite sollte aber auch die Qualität der Darstel-
lung nicht zu stark unter der Reduktion der Dreiecke leiden. Die Auswahl des Geo-
Mipmap Levels für einen Terrainblock wird in Abschnitt 4.3.4 beschrieben. Die Reali-
sierung der Detailstufen wird in Abschnitt 4.3.5 erläutert.
4.3.2 Repräsentation der Daten
Die Geländedaten können auf unterschiedliche Weise repräsentiert werden. Eine sehr
gängige Methode ist es, das Terrain durch ein uniformes, 2-dimensionales, orthogonales
Gitter anzulegen. So lassen sich die Geländedaten nicht nur platzsparend im Speicher
ablegen, sondern auch einfach indizieren (Matrixdarstellung). Im Hinblick auf die hier-
archische Unterteilung des Gitters durch den Quadtree muß das Gitter eine horizontale
und eine vertikale Auflösung von 2 n + 1 Vertices aufweisen, wobei n ∈ [ 1, ∞ [ . Dadurch
erhält man ein Gitter mit 2 n x 2n Feldern.
4.3.2.1 Höhendaten
Das Höhenfeld enthält für jeden der Gitterpunke eine Höheninformation. Diese Informa-
tion bestimmt die Höhenauslenkung der Vertices, zwischen denen das Terrain aufge-
spannt wird.
Zum Editieren der Höhendaten können spezielle Werkzeuge, wie z.B. Leveller oder Ter-
ragen1 verwendet werden. Aber auch mit einem Malprogramm lassen sich die Land-
schaftsausformungen editieren. Die Verwendung von Satellitendaten ist in den wenigsten
Fällen sinnvoll, da sie nur sehr grob auflösend sind. (Typische Rasterweiten sind 10 bzw.
30 m.)
1. Diese beiden Program werden im Internet angeboten. Leveller is ein kommerzielles Produkt der Firma
Daylon Graphics. Terragen wird von der Firma Planetside Software für den nicht-kommerziellen
Gebrauch zum kostenlosen Download bereitgestellt.
Für die Bearbeitung mit einem Malprogramm eignet sich besonders die Graustufendar-
stellung. Schwarz entspricht der geringsten Höhenauslenkung, Weiß der größten. Da das
Auge nur etwa 64 Graustufen unterscheiden kann, können damit keine sehr detaillierten
Höhenfelder geschaffen werden. Eine Codierung der Höhenwerte mit 8 Bit reicht maxi-
mal für eine grobe Formgebung. Für das Gelände der Fahrzeugsimulation ist das jedoch
ausreichend.
Um einen „Treppen-Effekt“ in der Darstellung der Geländeoberfläche zu vermeiden, ist

es ratsam, das Höhenfeld mit Hilfe einer Faltung zu glätten. Diese Glättung kann zur
Laufzeit – beim Auslesen der Höheninformation – durchgeführt werden. Möchete man
die CPU entlasten, kann die Glättung aber auch bereits vorab im Speicher durchgeführt
werden. Dadurch steigt der Speicherplatzbedarf um ein Vielfaches.
4.3.2.2 Featuremap
Die Feature Map dient dazu, unterschiedliche Eigenschaften innerhalb des Geländes zu
vergeben. So können beispielsweise unterschiedliche Bodenbeschaffenheiten definiert
werden, die das Fahrverhalten des Fahrzeuges beeinflussen. Denkbare Bodeneigenschaf-
ten sind der Reibwert zwischen Reifen und Untergrund, oder auch die Festigkeit des
Bodens. (Ein Körper wird auf lockerer Erde ungleich stark vom Boden zurückprallen als
auf hartem Beton.)
Die Zuordnung der Information erfolgt entweder direkt, oder über die Indizierung vorde-
finierter Bodentypen. Legt man unterschiedliche Eigenschaften für Asphalt, Rasen und
Schotter an, so kann die Featuremap sehr platzsparend im Speicher untergebracht wer-
den. Ein Byte pro Vertex sollte für die meisten Anwendungen ausreichen.
4.3.2.3 Quadtree
Aufgrund des geringen Speicherplatzbedarfs kann der Quadtree in bestehenden Daten-

strukturen abgelegt werden, wie beispielsweise in den nicht verwendeten Bits der Featu-
remap. Für den Entscheidungsbaum (in die Tiefe verzweigen oder nicht?) wird nur ein
einziges Bit pro Knoten benötigt. Für den Geomipmapping-Algorithmus muß zusätzlich
noch die Information gespeichert werden, in welcher Detailstufe die Terrainblöcke aus-
gegeben werden. Das geschieht in den Blättern des Baumes und nimmt – abhängig von
der Größe der Terrainblocks – 0 bis n Bits in Anspruch. (n ist gleich dem Logarithmus
Dualis der Seitenlänge eines Terrainblocks). Da der Baum nicht so weit in die Teife
reicht, wie bei einem vollständigen Quadtree, sondern bereits in geringerer Tiefe endet,
ist für die Speicherung aller benötigten Daten weniger als ein Bit pro Vertex nötig.
4.3.3 Erzeugung des Quadtrees
Der Quadtree Algorithmus dient dazu, eine quadratische Fläche hierarchisch in viele
kleine Quadrate zu unterteilen. Ziel des Algorithmus ist aber keine gleichmäßige Unter-
teilung. Die Fläche soll nur in ausgewählten Bereichen weiter verfeinert werden. Die
Unterteilung eines Quadrates wird von einer Bedingung abhängig gemacht (zB. alle
Quadrate, die sich in einer gewissen Distanz zur Kamera befinden, usw.). Auf diese
Weise erhält man unterschiedliche Flächenaufteilungen. Abb. 4.2 zeigt die Partitionie-
rung eines Quadrates mit der Seitenlänge 16. Die Zahlen geben Auskunft über die Ver-
zweigunstiefe des Baumes in den Teilflächen.
Abbildung 4.2: Exemplarische Flächenaufteilung mit Hilfe des Quadtree-

Algorithmus
Der einfachste Weg zur Erzeugung des Quadtrees führt über eine Rekursion:
01 setup_quadtree( int x, int z, int width )

02 {
03 calculate_subdivision_criterion();
04 if( subdivision_criterion == true )
05 {
06 set_qt_flag( x, z );
07
08 width /= 2;
09 if( width > 0 )
10 {
11 setup_quadtree( x-width, z-width, width );
12 setup_quadtree( x+width, z-width, width );
13 setup_quadtree( x-width, z+width, width );
14 setup_quadtree( x+width, z+width, width );
15 }
16 }
17 else
18 {
19 clear_qt_flag( x, z );
20 }
21 }
Wird der Quadtree im Algorithmus von Röttger bis zum untersten Level verfeinert, so
bricht die Rekursion beim Geometrical Mipmapping bereits in einer geringeren Teife ab.
Je nachdem, welche Auflösung für die Terrainblöcke gewählt wird, lassen sich dadurch
mehr oder weniger Rekursionsstufen einsparen.
4.3.3.1 Frustum Culling
Das Vieweing-Frustum ist jener Pyramidenstumpf, mit dem der Sichtbereich der Kamera
angenähert wird. Da zur Laufzeit große Teile des Terrains außerhalb des Sichtbereiches
liegen, brauchen sie nicht trianguliert und an die Render Pipeline übergeben zu werden.
Das Verfahren, mit dem die Sichbarkeitsentscheidung getroffen wird, nennt sich Frustum
Culling. Es besteht aus dem Test einzelner Punkte (oder Primitive) gegen das Vieweing-
Frustum. Befindet sich ein Teil des Geländes außerhalb des Frustums, so liegt er nicht im
Sichbereich, und muß auch nicht gezeichnet werden. Alle Geländeteile, die innerhalb des
Frustums liegen, sind Teil der dargestellten Szene.
In Verbindung mit dem Quadtree-Algorithmus kann dieses Verfahren sehr laufzeiteffizi-

ent eingesetzt werden: Der Quadtree muß nur an jenen Stellen in die Tiefe verzweigen,
die dem Test gegen das Viewing-Frustum standhalten, – die also teilweise oder zur
Gänze innerhalb des Sichtkegels liegen. Um sicherzustellen, daß das Kriterium alle
sichtbaren Bereiche als solche erkennt, sollte man das umschließende Würfelvolumen
(Bounding-Box) des jeweiligen Quadtree-Knoten gegen das Frustum testen. Der Test
eines einzelnen Punktes – wie beispielsweise des Flächenmittelpunktes – liefert unzurei-
chende Ergebnisse.
Die Implementierung des Frustum-Tests wird in einem Paper von Mark Morley
[Morl 00] beschrieben. Bei diesem Test werden die sechs Ebenen der Blickpyramide aus
der Sicht-Matrix extrahiert. Aufgrund der Lage einzelner Punkte zu den Ebenen lässt
sich die Sichbarkeitsentscheidung treffen. Die genaue Anwendung des Verfahrens wird
in Anhang B beschrieben.
4.3.4 Auswahl der Detailstufe

Ein geometrische Reduktion des Details wird durch das Auslassen von Rasterpunkten
erreicht. Daraus ergeben sich Ungenauigkeiten in der Visualisierung des Geländes (siehe
Abb. 4.3). Um – trotz der Detailreduktion – eine möglichst geringe Abweichung von
einer „optimalen Darstellung“ zu erhalten, wird beim Geomipmapping darauf geachtet,
daß die Ungenauigkeiten stets unterhalb einer festgelegten Toleranzschwelle liegen. Die
Toleranzschwelle wird in Pixel-Koordinaten gemessen. Ihr Maß ist die die Höhenver-
schiebung, die durch das Auslassen der Rasterpunkte entsteht. Je mehr Rasterpunkte in
der Darstellung ausgelassen werden, detso größer ist der Darstellungsfehler.
Abbildung 4.3: Höhenprofil in unterschiedlichen Detailstufen
Aufgrund des Strahlensatzes wirkt sich ein Fehler in der Darstellung weiter entfernter
Bereiche nicht so stark aus, wie in der Darstellung näher gelegener Regionen. Deshalb
darf eine geringere Detailstufe erst ab einer gewissen Distanz zur Kamera ausgewählt
werden. Boer beschreibt die Berechnung dieser Distanz. Sie kann für jeden Terrainblock
in jeder Detailstufe ermittelt werden.
4.3.4.1 Höhenfehler
Betrachtet man den Höhenverlauf von der Seite (siehe Abb. 4.4), so ergibt sich durch das
Weglassen des weiß eingefärbten Vertex eine geometrische Abweichung. Sie wird durch
die strichlierte Linie angedeutet. Im Vergleich zur nächsthöheren Detailstufe tritt der
Höhenfehler δ auf. Das Entfernen des Vertex kommt einem Absenken des weißen Punk-
tes auf Höhe des grau eingefärbten Punktes gleich.
Abbildung 4.4: Höhenfehler (durch Detailreduktion bedingt)
Für die Bestimmung eines geeigneten Mipmap-Levels wird dieser Höhenfehler δ auf
seine äquivalente Länge in Pixelkoordinaten projiziert. Die projizierte Länge bezeichne
ich als ε . Es ist genau jener Fehler, der vom Betrachter wahrgenommen wird. Über-
schreitet ε einen Grenzwert τ (von beispielsweise 4 Pixeln), so darf für den betrachteten
Terrainblock kein geringerer Mipmap-Level ausgewählt werden. Der Darstellungsfehler
würde den Grenzwert überschreiten. Das Detail darf nur solange reduziert werden,
solange ε kleiner als τ ist. So kann eine zuvor festgelegte Qualität in der Darstellung
garantiert werden.
Bei einem Polygon werden insgesamt sechs Werte für den Höhenfehler δ gemessen.
Zwei enlang der beiden Diagonalen, zwei entlang der beiden horizontalen Kanten, und
zwei entlang der beiden vertikalen Kanten (siehe Abb. 4.5). Die weiß eingefärbten
Punkte stellen die Vertices dar, die beim Übergang auf das nächstgeringere Detaillevel
ausgelassen werden.
Da sich ein Terrainblock aus mehreren dieser Polygone zusammensetzt, können in dem
Block etliche Höhenfehler gemessen werden. Relevant ist jedoch nur der größte dieser
Werte. Für ihn wird die Distanz D n ermittelt, ab der der Terrainblock im Detaillevel n
dargestellt werden darf.
Abbildung 4.5: Messung des Höhenfehlers in einem Polygon
Der größte Darstellungsfehler läßt bei waagrecht ausgerichteter Kamera messen. Bei
steigendem Blickwinkel nimmt der Fehler ab. Bei absoluter Draufsicht ist er gleich Null.
Geht man davon aus, daß die Kamera immer waagrecht auf das Gelände gerichtet wird
(Worst Case), so bleiben die Höhenfehler und die daraus resultierenden Kameradistan-
zen konstant. Die D n können für jeden Terrainblock in jeder Detail-Stufe vorberechnet
werden. Dadurch beschränkt sich die LOD-Entscheidung zur Laufzeit auf wenige Ver-
gleichsoperationen.
4.3.4.2 Vorberechnung von d
Die Berechnung der minimalen Darstellungsdistanz D n für einen Terrainblock kann der
Gleichung (4.1) entnommen werden. Der Höhenfehler δ wird als bekannt vorausgesetzt.
Die Konstante C wird in den Gleichungen (4.2) bis (4.4) hergeleitet. δ ist bei jeder
Detailreduktion gleich dem Maximum aus dem vorherigen Mipmap-Level und dem
aktuellen Höhenfehler zu setzen. Auf diese Weise werden aufsteigende Werte für D n
garantiert.
Dn = δ ⋅ C (4.1)
A (4.2)
C = ---
T
n
A = ---- (4.3)
t
n ist die Distanz zur near clipping plane. t entspricht der obersten Koordinate des mit
Hilfe der Parameter (l, r, b, t, n, f) beschriebenen Viewing-Frustums. Die Variable v res
in Gleichung (4.4) beschreibt die vertikale Auflösung des Ausgabefensters in Pixeln.
2⋅τ
T = ---------- (4.4)
v res
2 2 2
Dn = δ ⋅ C (4.5)
Die Quadrierung von Gleichung (4.1) erspart die Quadratwurzel-Funktion zur Berech-
nung der minimalen Kamera-Distanz. Siehe Gleichung (4.6).
4.3.4.3 Auswahl des Mipmap-Levels zur Laufzeit
Sind die D n -Werte vorberechnet, läßt sich die Auswahl des Mipmap-Levels auf wenige
Vergleichsoperationen zurückführen. Das folgenden Pseudocodestück veranschaulicht
die Vorgehensweise: Beginnend mit dem höchsten Mipmap-Level wird in einer Schleife
das Detail solange verkleinert, bis die Kameradistanz für das Umschalten auf die nächst-
geringere Mipmap-Stufe zu gering ist:
For Each GeoMipmap Level N

Compare L to Dn
if (L > Dn) store to RESULT
End For
return RESULT
4.3.5 Realisierung der Detailstufen
Eine geringere Detailstufe erhält man, indem man zum Zeichnen eines Terrain-Blocks
nur jeden zweiten, vierten, achten Vertex usw. verwendet (siehe Abb. 4.6). Bei einem
Terrainblock der Auflösung 5x5 Vertices sind nach dieser Vorgehensweise drei Detail-
stufen möglich. Bei einer Auflösung von 17x17 Vertices sind es bereits fünf Detailstu-
fen.
Für die höchste darstellbare Auflösung eines Terrainblocks verwende ich zukünftig die
Bezeichnung Detailstufe 0. Detailstufe 1 ist gleichbedeutend mit der nächstgeringeren
Auflösung. Eine weitere Reduktion in der Auflösung wird mit Detailstufe 2 bezeichnet.
Triangullierung des Gitters Terrainblock in niedrigerer

in höchster Detailstufe Auflösung
Abbildung 4.6: Gitterstruktur eines Terrainblocks
Grenzen zwei Terrainblöcke mit unterschiedlicher Auflösung aneinander, können an den

Übergängen Löcher in der Darstellung entstehen (siehe Abb. 4.7). Um diese Löcher zu
vermeiden, muß eine Detail-Anpassung vorgenommen werden. Dazu gibt es zwei Mög-
lichkeiten: Es können zusätzliche Vertices in der Randregion des Blockes mit der niedri-
gen Auflösung hinzugefügt werden. Und es können Vertices in der Kante des Blockes
mit der höheren Auflösung eingespart werden. Letztere dieser beiden Vorgehensweisen
hat sich als effizienter erwiesen.
Abbildung 4.7: Enstehung von Löchern in bei Detailübergängen
Durch das Auslassen der grau eingefärbten Vertices in Abb. 4.8 wird der Übergang zwi-
schen einem Terrainblock der Detailstufe 0 zu einem Block der Detailsufe 1 geschaffen
(links). Ein solcher Übergang (er wird auch als T-Übergang bezeichnet) kann sich über
mehrere Kanten erstrecken. Die rechte Abbildung zeigt die geometrische Anpassung von
Detailstufe 0 an Detailstufe 2 entlang zweier aneinandergrenzender Kanten.
Abbildung 4.8: Realisierung der T-Verbindungen zwischen Terrainblöcken

unterschiedlicher Auflösung
Da sich die Detailübergänge über mehrere Kanten erstrecken können, ergeben sich etli-
che Variationen in der Triangulierung eines Terrainblocks. Diese müssen bei der Erzeu-
gung der Vertexdaten berücksichtigt werden. Im inneren Bereich des Terrainblocks kön-
nen Triangle-Lists verwendet werden. Die Übergangsregionen übergibt man am besten
mit Hilfe von Triangle-Fans an die Graphikkarte. So lassen sich Verbindungen zwischen
Terrainblöcken unterschiedlicher Auflösungen schaffen.
Abbildung 4.9: Gelände-Triangulierung unter Verwendung des Geometrical

Mipmapping
Abb. 4.9 zeigt die Triangulierung des Terrains unter Verwendung des Geomipmapping
Algorithmus. In der Mitte der Abbildung sind die Detailübergänge zwischen Terrain-
blöcken unterschiedlicher Auflösung erkennbar.
4.4 Texturierung
Für der Texturierung von Landschaften gibt es unterschiedliche Ansätze. In den folgen-
den Abschnitten werde ich einige davon vorstellen. Es handelt sich dabei um theoreti-
sche Ausführungen, die die Aspekte unterscheidlicher Texturierungsverfahren aufzeigen,
und allgemeine Lösungsansätze beschreiben sollen. Ich habe die beschriebenen Verfah-
ren nicht implementiert. Als Quelle diente unter anderem das Virtual Terrain Project
[VTP 01]. Die Homepage bietet weiterführende Links zu unterschiedlichen Triangulie-
rungs- und Texturierungsverfahren.
Grundsätzlich unterscheidet man zwischen einer geospezifischen und einer geotypischen

Zuordnung der Texturinformation. Bei der geospezifischen Datenzuordnung wird jedem
Texel in der Landschaft ein eigener Farbwert zugewiesen. Dh., das gesamte Polygonnetz
wird mit einer einzigen, großen Textur überzogen. Auf diese Weise können fotobasierte
Darstellungen von Landschaftsformationen erzeugt werden. Der Nachteil liegt im enorm
hohen Speicherbedarf, der für die Unterbringung der Textur benötigt wird. Für weitläu-
fige Landschaften werden daher meist geotypische Ansätze verwendet. Dh., das Gelände
in unterschiedliche Regionen (Wiese, Asphalt, Schotter, ...) unterteilt. Die Farbzuord-
nung für einen Geländepunkt erfolgt über die regionsspezifische Textur, die dem jeweili-
gen Bereich der Landschaft entnommen wird. Die Texturspeicherauslastung wird auf
diese Weise relativ niedrig gehalten.
In Abschnitt 4.4.1 wird ein Verfahren vorgestellt, das auf rein geospezifischer Texturzu-
ordnung basiert. Die Verfahren in Abschnitt 4.4.3 bis Abschnitt 4.4.4.1 verwenden eine
geotypischer Zuordnung der Texturinformation. Das Verfahren in Abschnitt 4.4.2 ist eine
Mischung der beiden Vorgehensweisen.
Verwendung der Featuremap
Unabhängig von der Art der Texturzuordnung kann in der Featuremap die Verteilung
unterschiedlicher Bodentypen gespeichert werden. Ob diese Information gleichzeitig für
die Auswahl der Texturen verwendet wird, hängt vom Texturierungsverfahren ab. Ver-
sieht man die Bodentypen mit unterschiedlichen Eigenschaften (Reibwert, Stoßdämp-
fung, ...), so kann damit das Laufzeitverhalten des Fahrzeuges beeinflußt werden.
Die Auflösung der Featurmap sollte in etwa der Auflösung der Höhenmap entsprechen.
Eine Zuordnung der Features pro Vertex oder pro Polygon erscheint völlig ausreichend
(siehe Abb. 4.10).
Texturierung 60
Abbildung 4.10: Zuordnung der Daten aus der Featuremap
4.4.1 Texturkacheln
Da die Landschaft durch das Geo-Mipmapping Verfahren in gleich große, quadratische

„Geländekacheln“ aufgeteilt ist (in die Terrainblöcke), besteht die Möglichkeit, einem
jeden dieser Terrainblöcke eine eigene Textur zuzuordnen. Dadurch muß die Graphik-
karte nicht permanent alle „Texturkacheln“ im Speicher resident halten. Überschreitet
die Datenmenge das Volumen des Texturspeichers, wird ein Paging-Verfahren zum Ein-
und Auslagern der Texturen benötigt. Dh., alle zur Ausgabe eines Frames benötigten
Texturen müssen in den Texturspeicher nachgeladen werden. Nicht mehr benötigte Tex-
turen werden dabei überschrieben.
Die Featuremap muß händisch (oder mittels eines Algorithmus) an die Texturen ange-
passt werden.
Innerhalb der Landschaft können gewisse Texturkacheln auch mehrmals verwendet wer-
den. Beispiel: Überall dort, wo die Landschaft mit Gras überzogen ist, wird der Terrain-
block mit einer „Rasen-Kachel“ überzogen. In den meisten Fällen läßt sich dadurch
jedoch nur eine geringfügige Reduktion der Texturdaten erzielen.
4.4.2 Distanzbasierte Detailüberblendungen
Eine oft verwendete Technik ist das „Distance Based Blending“. Hierbei wird die ganze
Landschaft mit einer relativ grob auflösenden Textur zu überzogen. Nur in den Kamera-
nahen Bereichen wird das Terrain mit einer Detail-Textur überblendet. Dadurch entsteht
beim Betrachter der Eindruck einer relativ feinen Auflösung. Um die Detail-Textur dem
darunterliegenden Bodentyp anzupassen, kann die Information aus der Featuremap
genutzt werden.
Verwendet man für die Überblendung nur einen einzigen Farbkanal, so kann damit die
Helligkeit der Grundtextur variiert werden. Dadurch wird dem Boden eine Struktur ver-
liehen.
4.4.3 Maskierungsverfahren
Bei den Maskierungsverfahren wird mit Hilfe einer Maske festgelegt, welche Region des
Terrains mit welcher Textur überzogen wird. Als Maske wird üblicherweise eine Bitmap
(Alpha-Textur) verwendet. Sie gibt für jeden Bodentyp flächendeckend einen Deckungs-
wert von 0 bis 255 (entsprechend 0 bis 100%) an. Diese Bitmap ist relativ groß und muß
im Speicher untergebracht werden.
Möchte man mehr als zwei Texturen überblenden, so werden dafür mehrere Render-
durchläufe benötigt. Das Terrain muß mit jeder Textur einmal gezeichnet werden.
Texture-Splatting
Um dennoch eine einigermaßen effiziente Ausgabe zu erzielen, kann das „Texture-Splat-

ting“-Verfahren [Bloo 00] eingesetzt werden. Dabei wird die Landschaft in mehrere,
gleich große Blöcke unterteilt. (Die Verwendung der Terrainblöcke eignet sich hierfür
ausgezeichnet.) Anschließend wird jeder der Blöcke mehrmals in den Framebuffer
gerendert. Bei jedem Durchgang wird eine neue Textur aufgetragen. Die Transparenzin-
formation für jede der Texturen ist in einer seperaten Alphamap gespeichert.
Da für die mehrmalige Ausgabe des Terrainblocks die selbe Triangulierung verwendet
werden kann, müssen die Vertexdaten nur einmal (pro Frame) an die Hardware gesendet
werden. Auf diese Weise läßt sich eine beträchtliche Geschwindigkeitssteigerung erzie-
len. Für die wiederholte Ausgabe des Dreiecksnetzes müssen nur die gewünschten Tex-
turen ausgewählt werden.
Als Auflösung für die Alphamap schlägt Charles Bloom 2x2 Pixel pro Rasterquadrat vor.
Für einen Terrainblock der Auflösung 17x17 Vertices wären das 32x32 Pixel.
4.4.4 Polygonale Repräsentation
Bei der polygonalen Repräsentation wird die Landschaft in mehrere Subnetze unterteilt.
Jedes dieser Netze repräsentiert eine eigene Geländeregion, bzw. einen eigenen Boden-
typ. Die Zuordnung der Texturen erfolgt zu den jeweiligen Subnetzen. Auf diese Weise
lassen sich sehr scharfkantige Übergänge schaffen, ohne daß eine große Maskierungs-
Bitmap im Speicher untergebracht werden muß.
Um beliebig ausgeformte Regionen zu erzeugen, ist allerdings die Verwendung irregulä-
rer Netze erforderlich. Da die Triangulierung des Geländes im vorliegenden Fall einem
rechtwinkeligen Grundraster folgt, würden die Übergänge zwischen den Regionen ent-
lang der rechtwinkeligen Kanten verlaufen.
4.4.4.1 Polygonale Zuordnung mit Maskierung in den Übergängen
Da die Textur bei der polygonalen Repräsentation in einem Durchgang aufgebracht wer-
den kann, lassen sich relativ hohe Ausgabegeschwindigkeiten erzielen. Die rechtwinkeli-
gen Übergänge zwischen den Regionen sind allerdings unerwünscht.
Texturierung 62
Läßt man zwischen den Regionen etwas Freiraum (zB. durch die Verwendung einer Fea-
turemap, die per Vertex zugeordnet ist – siehe Abb. 4.10, links), so können diese Zwi-
schenräume verwendet werden, um einen Übergang zwischen zwei (oder mehreren)
Regionen zu schaffen (siehe Abb. 4.11). Durch Überblendung der Texturen können
beliebige Verläufe geschaffen werden.
Abbildung 4.11: Bestimmung des Übergangsbereiches zwischen den

Landschaftsregionen
4.4.5 Multitexturing: Überblendungsmechanismen
4.4.5.1 Vertex- versus Bitmap-Alpha
Läßt sich die Textur in einem Durchgang aufbringen (Überblendung von zwei Texturen),
empfiehlt es sich, den Überblendungswert als Vertex-Alpha anzugeben. Damit läßt sich
der Datendurchsatz zur Graphikarte möglichst gering halten. Sollen mehr als zwei Textu-
ren überblendet werden, so empfiehlt sich die Verwendung einer Alphamap für jede der
Texturen. Wie das Texture-Splatting Verfahren zeigt, ist es empfehlenswert, für mehrere
Zeichendurchgänge ein und desselben Polygonnetzes einen Vertexbuffer zu verwenden.
So muß das Polygonnetz nur einmal an die Hardware übergeben werden. Die Render-
durchgänge werden direkt auf den Framebuffer ausgeführt.
4.4.5.2 Textur Blending Kaskade
DirectX erlaubt die Verwendung mehrerer Textur-Stufen. Diese werden – je nach Lei-
stung der Graphikhardware – in ein bis mehreren Durchgängen abgearbeitet (siehe
Abb. 4.12).
Zum Ausmaskieren von Geländeregionen können jedoch maximal die ersten beiden Stu-
fen der Textur Blending Kaskade verwendet werden. Die erste zur Aufbringung der Far-
binformation. Die zweite zur Ausmaskierung mit der Alphamap. Die Alphamap muß als
seperate Textur an die Kaskade übergeben werden.
Abbildung 4.12: Texturstufen unter DirectX

Texturierung 64
Kapitel 5
Systemarchitektur
5.1 Konzeptuelle Überlegungen

In der Literatur ([BWAK 99], [Low 00]) wird für physikalische Simulationen ein eigenes
Modul empfohlen, das die Integration der Systemgrößen übernimmt. Dieses Modul wird
auch als ODE-Solver bezeichnet (Lösungsverfahren für Ordinary Differential Equati-
ons). In meiner Implementierung verzichte ich auf dieses Modul, da ich mich für ein sehr
einfaches numerisches Integrationsverfahren entschieden habe: für die Euler-Integration.
Stattdessen werden die nötigen Berechnungen in die Methoden der jeweiligen Klassen
durchgeführt. Die Implementierung eines zentral gekapselten Lösers erscheint nur aus
zweierlei Gesichtspunkten als sinnvoll:
1. Für die Implementierung eines Verfahrens höherer Ordnung, wie beispielsweise dem
Runge-Kutta-Verfahren. Hier verlangt die Komplexität des Verfahrens nach einer sau-
beren Modultrennung.
2. Für die Verwendung in einem Framework zur Simulation mehrerer physikalischer

(Teil-)Systeme, deren Verarbeitung nach einem einheitlichen Schema vorgenommen
werden kann. So können alle Komponenten die Funktionalität des zentalen Löser nut-
zen.
Im Hinblick auf einen sauberen, modularen Aufbau des Systems wäre ein derartiges Fra-
mework sicherlich wünschenswert. Ich denke dabei an eine Reihe von „Physik-Objek-
ten“, die sich von einer Basisklasse ableiten, und deren Zusammenspiel durch ein äuße-
res Modul geregelt wird. Betrachtet man den Ansatz, den [Low 00] für die Modellierung
der Physik in Computerspielen vorschlägt, so wird man dort die angesprochene
Modultrennung verwirklicht finden. Die von Low verwendeten Objekte sind durch phy-
sikalische Attribute (Zustandsgrößen, funktionale Größen), durch äußere Kräfte und
65
Verwendete Datenstrukturen 66
Momente, und durch Bewegungseinschränkungen (Constraints)1 charakterisiert. Die

Simulation selbst stützt sich auf die Verwendung eines gekapselten Lösers: Der Dyna-
mics Controller stellt neben dem numerischen Integrationsverfahren einen Löser für
Kollisionen und einen Löser für Constraints zur Verfügung. Er ist für die Berechnung
aller Bewegungsabläufe zuständig.
Meine derzeitige Realisierung beschreibt einen anderen Weg. Da ich aus Komplexitäts-
gründen die eine oder andere Vereinfachung treffe, habe ich von vorneherein nur wenige
Systemkomponenten zu simulieren. Bei der Modellierung der Federung verwende ich
beispielsweise einen eindimensionalen Ansatz mit einem Massepunkt. So spare ich mir
die Verwendung eines Starrkörpers, der durch Feder und Dämpfer gekoppelt, und durch
Constraints in seiner Bewegung eingeschränkt ist. Anstelle der Kopplung mehrerer
gleichartiger Komponenten wird das Fahrzeugmodell durch wenige unterschiedliche
Komponenten beschrieben. Und in diesem Zusammenhang erweist es sich als sinnvoll,
sowohl die schrittweise Integration, als auch die Berechnung und Auflösung von Kolli-
sionen im Speziellen durchzuführen. Die Verwendung eines Frameworks für die physi-
kalischen Berechnungen könnte hier nicht effizient eingesetzt werden. Ein zentrales
Modul für die Auflösung der Bewegungsabläufe würde nicht die gewünschte Einsparung
an Programmcode bringen, da sich nur wenige Simulationsroutinen von den Komponen-
ten-Klassen in den zentralen Löser übernehmen ließen.
Dennoch versuche ich eine einheitliche „Schnittstelle“ zwischen den Systemkomponen-

ten zu schaffen. Durch das Mitführen von Attributen für eingehende und ausgehende
physikalische Größen, wie Kraft, Position und Geschwindigkeit läßt sich die Wechsel-
wirkung zwischen den Komponenten zentral in der Klasse Dynamics behandeln. Eine
Namenskonvention bei der Bezeichnung der Attribute erleichtert das Auslesen und
Zuweisen der jeweiligen Größen.
5.2 Verwendete Datenstrukturen

Da gewisse Teilsysteme wie Radaufhängung und Räder (Drehimpuls) eindimensional
modelliert sind, reichen Skalare für die Abbildung ihrer Systemzustände. Die Zustands-
größen werden durch Float-Werte einfacher Genauigkeit wiedergegeben. Alle anderen
verwendeten Strukturen sind in der Bibliothek lin_math.h definiert.
Für den Kräfteaustausch zwischen den Teilkomponenten ist eine Transformation der ska-
laren Zustandsgrößen ins Weltkoordinatensystem erforderlich. Sie müssen in gerichtete
Größen (Vektoren) umgerechnet werden. Die Orientierung der Vektoren läßt sich eindeu-
tig aus der Orientierung der Komponenten entnehmen.
1. Constraints werden in der Literatur v.A. im Zusammenhang mit der Verwendung von Starrkörpern im
dreidimensionalen Raum erwähnt. [Witk 99] befaßt sich ausführlich mit der Modellierung von
eingeschränkten Bewegungsabläufen.
67 Systemarchitektur
5.2.1 Eindimensionale, gerichtete Größen
Eindimensionale, gerichtete physikalische Größen wie Position, Geschwindigkeit (und

weitere Ableitungen der Position nach der Zeit), Kraft und Momente werden durch Vek-
toren repräsentiert. Ich verwende dazu die von der Direct3DX Utility Library
[D3DX 02] vordefinierte Struktur D3DXVECTOR3. Es handelt sich dabei um einen drei-
dimensionalen Vektor von Float-Werten einfacher Genauigkeit. Die Felder tragen die
Bezeichnungen x, y und z. In DirectX sind auf den Datentyp außerdem bereits einige
Rechenoperationen vordefiniert (Addition, Subtraktion, Zuweisung, Multiplikation mit
einem Skalar und Division durch einen Skalar). Dadurch wird die Handhabung der Vek-
toren maßgeblich vereinfacht. Zur Abkürzung der Schreibweise verwende ich für
D3DXVECTOR3 den Alias vec3.
Besonders erwähnen möchte ich in diesem Zusammenhang die Repräsentation des

Moments. Es kann ebenfalls durch einen Vektor angegeben werden. Die Richtung des
Vektors gibt die Rotationsachse an, um welche das Moment ausgeübt wird. Die Länge
des Vektors stellt die Amplitude (die Stärke) des Drehmoments dar. Momente lassen sich
durch Anwendung der auf Vektoren definierten Rechenoperationen addieren und subtra-
hiern.
5.2.2 Orientierung
Die Orientierung des Starrkörpers wird durch Quaternions repräsentiert. Die verwendete
Datenstruktur trägt den Namen quaternion und besitzt die Felder r, x, y und z. Für die
Felder werden Float-Werte doppelter Genauigkeit verwendet. Sie sollen den Fehler bei
der Berechnung der Starrkörperrotation möglichst gering halten. Unter der Verwendung
von Matritzen würde – durch die in jedem Simulationsschritt wiederholte Multiplikation
– bereits nach wenigen Simulationsschritten ein deutlich erkennbarer Verschiebungsef-
fekt auftreten. Verwendet man Quaternions, so bleibt dieser Verschiebungseffekt aus, da
die Orientierungsmatrix in jedem Schritt erneut aus dem Quaternion berechnet wird. Die
Rechenungenauigkeit, die sich aufgrund der wiederholten Multiplikation des Quaterni-
ons ergibt, ist im Vergleich zu Matrizenrepräsentation sehr gering. Außerdem wird das
Quaternion bei jeder erneuten Berechnung normalisiert. Dennoch ist die Verwendung
von double-Werten zur Speicherung der Orientierung vorzuziehen.
5.2.3 Masseträgheit
Im eindimensionalen Fall (Reifen, Motor) kann die Trägheit I(t) ebenfalls durch einen
Skalar angegeben werden. In der dritten Dimension (Starrkörper) ist eine 3x3 Matrix
erforderlich. Für die Felder der Matrix sind Float-Werte einfacher Genauigkeit ausrei-
chend. Da I(t) mit jedem Simulationsschritt aus der Konstanten Ibody und der Orientie-
rungsmatrix R(t) berechnet wird, können sich hier keine größeren Rechenungenauigkei-
ten ergeben.
Überblick über die verwendeten Klassen 68
5.3 Überblick über die verwendeten Klassen

Grob betrachtet gliedert sich die Implementierung in drei Bereiche:
1. Implementierung des Fahrzeuges
2. Graphikschnittstelle
3. Terrainvisualisierung
Den zentralen Teil stellt die Implementierung des Fahrzeuges und dessen Physik dar.
Die nachstehende Abbildung (Abb. 5.1) zeigt die Beziehungen zwischen den verwende-
ten Klassen in UML Notation [UML 99].
Abbildung 5.1: UML Klassendiagramm
5.3.1 Implementierung des Fahrzeuges

Die Klasse Vehicle stellt die Schnittstelle für die Anwenderschicht dar. Sie erlaubt das
Setzten von Position und Orientierung des Fahrzeuges. Außerdem werden hier die Fahr-
zeugkontrollen (Gas, Kupplung, Lenkung, Bremse) bereitgestellt. Die Physik wird mit
Hilfe der Klasse Dynamics umgesetzt. Sie beinhaltet die Umsetzung des vorgestellten
Fahrzeugmodells und wird von der Klasse Vehicle instanziert. Die Implementierung der
Physik spaltet sich in mehrere Komponenten auf: Starrkörper (RigidBody), Federung
(Suspension), Reifen (Tyres), Motor (Engine) und Bremsen (Brakes) sind als eigene
Klassen modelliert. Die Gliederung orientiert sich an den Komponenten des Automo-
dells.
5.3.2 Graphikschnittstelle
Die Graphikschnittstelle dient als Anbindung zur DirectX Schnittstelle und kapselt die
wichtigsten Routinen zur Graphikausgabe. Der wesentliche Teil der Implementierung
erstreckt sich über eine einzige Klasse, GFX_Engine. Lediglich die Kamera ist in eine
eigene Klasse ausgelagert. Sie wird als Objekt dynamisch an die Graphik Engine gebun-
den. So kann sie von anderen Systembestandteilen referenziert und auch aktualisiert wer-
den. Außerdem können aufgrund der dynamischen Bindung mehrere Kameras instanzi-
iert werden, zwischen denen zur Laufzeit umgeschaltet wird. Die View Matrix wird bei
jedem Render-Vorgang dem Zustand der ausgewählten Kamera angepaßt.
Die Graphik Engine ist dazu vorgesehen, vom Hauptprogramm statisch eingebunden zu
werden. Sie stellt (neben der Kamera-Verwaltung) Routinen zum Manipulieren der Welt-
matrix und der Projektionsmatrix zur Verfügung. Sie erlaubt das Setzen von Licht- und
Beleuchtungswerten, und sie stellt Methoden zum Laden und zum Darstellen von
DirectX Objekten bereit. Alle weiteren Zustandsveränderungen der Render-Pipeline
[D3DP 98] und das Ausführen von Zeichenfunktionen müssen direkt über das Direct3D
Device durchgeführt werden. Die Referenz auf das Direct3D Device wird von der Gra-
phik Engine verwaltet und kann per Methodenauruf abgefragt werden.
5.3.3 Terrainvisualisierung
Die Terrain Engine übernimmt das Laden der Geländedaten und deren Visualisierung.
Der für die Aufbereitung der Visualisierungsdaten gewählte Algorithmus wurde bereits
in Abschnitt 4.3 auf Seite 49 näher behandelt. Ebenso, wie die Graphik Engine, ist auch
die Terrain Engine als eine einzige Klasse konzipiert. Das verhindert eine unnötige Refe-
renzierung der Datenstrukturen in den Teilobjekten und kommt der Ausführungsge-
schwindigkeit zugute. Da zur Laufzeit maximal eine Instanz der Terrain Engine benötigt
wird, empfiehlt es sich, diese ebenfalls statisch in das Hauptprogramm einzubinden.
Der Vollständigkeit halber möchte ich anführen, daß die Terrain Engine im Grunde nicht
die gesamte Graphik Engine referenziert, sondern nur das von der Graphik Engine ver-
waltete Direct3D Device. Für die Visualisierung der Daten ist die Referenz auf das
Direct3D Device ausreichend. Aus der obigen UML Notation ist dieser Zusammenhang
nicht ersichtlich.
5.4 Die Klassen im Detail
5.4.1 Relevante Klassen für den Entwickler

Für den Entwickler ist nur ein Teil der im Klassendiagramm angeführten Klassen rele-
vant. Für das Aufsetzen eines lauffähigen Programmes müssen folgende Klassen instan-
ziert werden:
Die Klassen im Detail 70
Vehicle
Vehicle ist die zentrale Klasse für die Implementierung des Fahrzeuges. Das Anwender-
programm greift ausschließlich auf Vehicle-Objekte zu, um das Fahrzeug manipulieren
zu können, bzw. um es zu visualisieren.
In der Initialisierungsphase des Vehicles werden alle wichtigen Simulationsparameter
gesetzt: Die Methode loadData lädt die fahrzeugspezifischen Daten und nimmt die Ein-
stellungen am physikalischen Modell vor. (Die Parameter werden über die Member-
Methoden des eingebetteten Dynamics-Objektes gesetzt.) Außerdem werden in load-
Data die Visualisierungsdaten1 geladen, die später über die draw-Methode an die Ren-
der-Pipeline übergeben werden.
TER_Engine
Die Terrain Engine lädt die benötigten Visualisierungsdaten in der Methode loadData.
Diese muß vom Benutzer in der Initialisierungsphase aufgerufen werden. Um Land-
schaften als eine Einheit laden zu können, habe ich für die Terrain Engine ein eigenes
Dateiformat spezifiziert. Es bietet Platz für folgende Informationen:
• Höhendaten
• Featuremap
• Beschreibung der einzelnen Geotypen und die zugehörigen Textur-Referenzen
Die Visualisierung erfolgt gemäß des in Abschnitt 4.3 auf Seite 49 vorgestellten Algo-
rithmus. Auf weitere Aspekte der Implementierung werde ich im folgenden Kapitel
näher eingehen.
GFX_Engine
Die Graphik Engine wird vom Hauptprogramm aus statisch eingebunden. Um den Pro-
grammierer zu entlasten, stellt sie sowohl Methoden zum Erzeugen als auch zum Freige-
ben eines DirectX-fähigen Win32 Fenster zur Verfügung. Die „Hauptschleife“ der
Win32 Anwendung wird ebenfalls über Methoden der Klasse GFX_Engine realisiert. So
wird eine effiziente Einbindung der Graphikausgabe in die Windows Hauptnachrichten-
schleife erreicht (siehe Anhang C).
Camera
Die Klasse Camera leitet sich von GFX_Camera ab. Sie wird als Referenz im Fahrzeug
mitgeführt und bietet unterschiedliche Kamera-Einstellungen (fixe Position und Orien-
1. Es handelt sich dabei um DirectX Mesh-Daten. Über das von Microsoft definierte Dateiformat lassen
sich Polygonmodelle für den Anwender relativ einfach handhaben. Außerdem gibt es im DX8 SDK für
die gängigsten 3D-Editoren Plugins zum Export in DirectX-Dateien.
tierung, fixe Position mit Blick auf das Fahrzeug, Cockpit-Ansicht, Draufsicht auf das
Fahrzeug, usw.). Zusätzlich wird über die Camera-Klasse die Anzeige der Instrumente in
den Render-Zyklus eingebunden.
Driver
Die Klasse Driver läßt sich nicht als integraler Bestandteil der Systemarchitektur verste-
hen. Sie ist lediglich eine Hilfsklasse, und dient dazu, den Code zur Ansteuerung des
Fahrzeuges aus dem Hauptprogramm auszugliedern.
Diese Klasse ist dazu gedacht, unterschiedliche Fahrzeugsteuerungen zu realisieren.
Eine Subklasse von Driver kann etwa verwendet werden, um auf Benutzerinteraktionen
zu reagieren. Eine weitere Subklasse könnte die autonome Steuerung (Computersteue-
rung) des Fahrzeug übernehmen. Letzteres ist vor allem bei der Verwendung mehrerer
Fahrzeug-Instanzen interessant.
Driver:HumanDriver
Diese Subklasse von Driver fragt die gedrückten Tasten ab und reagiert mit der entspre-
chenden Ansteuerung der Fahrzeugkontrollen. Der Einfachheit halber verwende ich die
Win32 Tastaturabfragen. Denkbar wäre aber auch die Verwendung von DirectInput.
5.4.2 Intern verwendete Klassen
Änderungen an den folgenden Klassen seitens des Benutzers sind an und für sich nicht
vorgesehen. Um andere Graphiken einzubinden oder um das Laufzeitverhalten zu
ändern, kann es aber dennoch sinnvoll sein, Änderungen am vorliegenden Code vorzu-
nehmen. Die Positionierung und das Eichen der Overlay-Anzeigen (Instruments) muß
beispielsweise direkt im Konstruktor der Klasse vorgenommen werden. Dies ist jedoch
nur nötig, soferne eine andere Anzeige als die bestehende verwendet werden soll.
Instruments
Die Klasse Instruments dient zur Laufzeitvisualisierung folgender Daten:
• Geschwindigkeit des Fahrzeuges
• Motordrehzahl
• eingelegter Gang
Die Fahrzeuggeschwindigkeit wird – analog zur Geschwindigkeitsmessung an einem

realen Fahrrzeug – aus der Drehzahl eines Antriebsreifens berechnet. Das führt dazu, daß
die angezeigte Geschwindigkeit nicht immer der tatsächlichen Geschwindigkeit des
Fahrzeuges (= Geschwindigkeit des Starrkörpers) entspricht. Sie entsteht aufgrund der
Gleitreibung der Reifen.

Die Motordrehzahl wird direkt aus der Zustandsvariable rpm des Motors ausgelesen.
Für eine korrekte Darstellung der Werte muß der Darstellungswinkel des Zeigers auf das
verwendete Ziffernblatt abgestimmt werden. Dies geschieht mit Hilfe der Variable
omega0, die den Winkel für die Null-Auslenkung der Nadel festlegt. Die Skalierungsva-
riable multiplier bestimmt die Ausschlag der Nadel pro Messeinheit. Die Ziffernblätter,
die Nadel und die Symbole für die Gangschaltung werden in der Methode loadData
geladen.
Dynamics
Dynamics kapselt alle Objekte, die zur Berechnung der Fahrzeugsynamik von Bedeu-
tung sind. Außerdem koordiniert die Klasse die Teilberechnungen der darunterliegenden
Klassen und kombiniert deren Ergebnisse. Auf diesem Weg wird das Zusammenspiel der
Teilkomponenten realisiert: Der in Abschnitt 3.8 auf Seite 43 vorgestellte Simulationszy-
klus wird in dieser Klasse umgesetzt. Die Verteilung der Auflagekräfte und die Rückfüh-
rung der Federkräfte in den Aufhängungspunkten in den Masseschwerpunkt des Starr-
körpers erfolgt ebenfalls in dieser Klasse.
Es folgt eine kurze Beschreibung der untergeordneten Klassen von Dynamics. Die Inte-
gration der Zustandsgrößen erfolgt in den jeweiligen Klassen. Die dafür zuständige
Methode trägt den Namen transform. In dieser Methode wird das System von einem
Zustand in den darauf folgenden Zustand überführt.
RigidBody
Umsetzung der Starrkörperdynamik. Der Zustand des Starrkörpers wird durch die
Anwendung von externen Kräften, Momenten und von Stößen beeinflußt. Die Zufüh-
rung dieser Größen geschieht über entsprechende Methoden. Werden innerhalb eines
Simulationsschrittes mehrere Kräfte oder Momente auf den Körper ausgeübt, so werden
diese akkumuliert, ehe sie in die Systemgleichung eingehen. Die Stoßberechnung ergibt
sich aus einer Kollision, die in Kollisionspunkt und Stoßrichtung aufgelöst wird.
Suspension
Umsetzung der Federung. Unter Berücksichtigung der Kraft, die der Reifen bei Boden-
auflage auf die Federung ausübt, wird die Auslenkung der einzelnen Massen berechnet.
(Zur Erinnerung: die Federung setzt sich aus zwei Massen zusammen. Eine davon ist
beweglich. Der oberste Massepunkt ist gleich der Karosserie und wird für die Simulation
des Teilsystems „Radaufhängung“ starr angenommen.) Die Kraft, mit der die Karosserie
getragen wird, berechnet sich aus der Auslenkung der Federn.
Beim Überschreiten der Federwege (gegenseitige Eindringung der Massen) wird ein
Stoß berechnet, der zwischen den Massen der Federung übertragen wird. Da sich ein
Stoß vom Boden her beginnend nach oben fortsetzen kann, muß die Eindringung einer
Federmasse in die Karosserie in der Klasse Dynamics abgefangen werden. Die Daten,
die zur Durchführung der Stoßberechnung nötig sind, werden aus der Federung ausgele-
sen und an den Starrkörper überführt.
Tyre
Umsetzung des Reifenmodelles. Im Zusammenspiel mit dem Antrieb (Engine) werden in

jedem Simulationsschritt die Drehzahl des Reifens und die Kräfte in der Bodenkontakt-
fläche bestimmt. In Anhängigkeit von Auflagekraft und horizontaler Beschleunigung
berechnet sich die Bodenhaftung des Reifens. Für den Reifen ergeben sich zwei mögli-
che Zustände, die das Bodenverhalten (für den nächsten Simulationsschritt) beeinflus-
sen:
1. Haftreibung
2. Gleitreibung
Für die Kollisionsberechnung werden die Reifen per Referenz an die Terrain Engine
übergeben. Dort findet die Schnittberechnung statt. Die ermittelten Werte werden von
der Terrain Engine durch direkten Zugriff im Reifen abgelegt. Die aktuellen Daten ste-
hen ab diesem Zeitpunkt in der Fahrzeug-Hierarchie zur Verfügung.
Engine
Die Klasse Engine modelliert den Antrieb mit Hilfe einer Drehmomentkurve. Basierend
auf den Daten der Vollastkurve werden die Teillastkurven vorberechnet. Als Parameter
dienen Nullpunkt und Neigung der Projektionsgerade (siehe Abschnitt 3.6.1.1 auf Seite
40). Die genaue Vorgehensweise bei der Skalierung der Drehmomentkurve wird im fol-
genden Kapitel näher besprochen. Ist der Motor an die Antriebsreifen gekoppelt, wird
das Drehmoment des Motos als Antrieb an die Reifen übertragen und sorgt für den nöti-
gen Vortrieb. Die Drehzahl des Motors reguliert sich durch die Abrollgeschwindigkeit
der Reifen. Sind die Reifen vom Motor entkoppelt, ist dieser Rückkopplungszyklus
unterbrochen. Deshalb wird im Leerlauf eine Schwungmasse zu Hilfe genommen, mit
der sich das Drehzahl-Verhalten des Motors nachbilden läßt.
Brakes
Die Bremsen sind durch den maximalen Bremsdruck, die Bremskraftverteilung auf die
vier Räder und den Radius der Bremsscheiben spezifiziert. Als Reibwert zwischen
Bremsklötzen und Bremsscheibe verwende ich einen typischen Wert für „Eisen auf
Eisen“. Die Bremskraft, die sich beim Ausüben eines Bremsdruckes bildet, wird als
Moment an die Reifen übertragen.
5.4.3 Weitere Klassen und Include-Dateien
lin_math.cpp
Die Include-Datei lin_math.cpp beinhaltet Vektor- und Matrizenoperationen, die von

DirectX nicht zur Verfügung gestellt werden. Außerdem enthält die Funktionssammlung
die Umrechnung zwischen Matrizen und Quaternions und andere Hilfsfunktionen. In der
Headerdatei werden Pi, die Absolut-, Minimum- und Maximum-Funktion und die
Datenstrukturen vec3, mat3 und quaternion definiert.
defs.h
Diese Datei definiert die Konstante für die Erdgravitation, sowie Konstanten für die Indi-
zierung der Systemteile im Automodell. Die Rate, in der die mathematischen Berech-
nungen durchgeführt werden (= Anzahl der Simulationsschritte pro Sekunde) wird eben-
falls in dieser Datei festgelegt.
Kapitel 6
Implementierungsaspekte
6.1 Physikalisches Fahrzeugmodell
Es folgen Details zur Umsetzung der Fahrzeugkomponenten. Sie sollen einen Überblick
über die angewendeten Verfahren geben und zum Verständnis des Quellcodes beitragen.
6.1.1 Kräfteberechnungen
Der Simulationszyklus verlangt nach der Transformation des Starrkörpers eine Berech-
nung der Bodenkollisionen (siehe Abbildung 3.8, „Simulationszyklus,“ auf Seite 44).
Aufgrund der festgestellten Eindringungen werden die Kontaktkräfte in den Reifen
ermittelt. Weitere Kräfte in den Reifen ergeben sich durch den Antrieb, durch die Brem-
sen, und in Querrichtung der Reifen durch die seitliche Beschleunigungen des Fahrzeu-
ges.
6.1.1.1 Auflagekraft (Normalkraft)
Die Auflagekraft ist jener Anteil der Reifenkräfte, der in Normalrichtung zur Boden-
ebene verläuft. Sie wird aus den Bodeneindringungen der Reifen entnommen. Um die
Entwicklung und die Übertragung von Stößen entlang der Radaufhängung abfangen zu
können, wird diese Kraft jedoch nicht direkt verwendet. Sie wird zuerst an die Radauf-
hängung übergeben. Diese wird sie einen Simulationsschritt weitersimuliert. Dabei kön-
nen eventuelle Masse-Eindringungen aufgelöst werden. Anschließend wird aus der Kraft
in der Aufhängung und im Reifen die Auflagekraft berechnet. Neben der Auflösung von
Eindringungen wird damit auch eine bessere Näherung bei der Berechnung der Radlast
erreicht.
75
Physikalisches Fahrzeugmodell 76
An die Radaufhängung wird jener Teil der Bodennormalkraft übertragen, der in Rich-
tung der Federungsachse verläuft. Dazu wird der Kraftvektor aus dem Reifen mit dem
Cosinus zwischen Bodennormale und Federungsachse skaliert (siehe Abb. 6.1).
Abbildung 6.1: Bestimmung des Kraftanteiles, der in die

Radaufhängung überführt wird
Fn ist die Normalkraft, die durch die Bodeneindringung in der Feder des Reifens ent-
steht. Fra ist jener Anteil von Fn , der in die Radaufhängung überführt wird. Longitudi-
nal- und Lateralkräfte der Reifen (durch Antrieb, Bremse oder seitliche Beschleunigung)
werden dabei nicht berücksichtigt.
6.1.1.2 Hangabtriebskraft (Horizontalkraft)
Die vertikale Kraft, mit der ein Körper nach unten gezogen wird (Gewichtskraft), resul-
tiert aus Masse mal Erdbeschleunigung. Liegt der Körper am Boden auf, so lastet diese
Gewichtskraft auf der Auflagefläche. Sie spaltet sich in eine Normalkomponente und in
eine Hangabtriebskomponente auf. Die Normalkraft wird in Richtung der Bodennormale
entnommen. Die Hangabtriebskraft verläuft in Bodenebene im „steilstmöglichen Winkel
hangabwärts“. Abb. 6.2 zeigt die Aufspaltung der Gewichtskraft Fg in die Normalkraft
Fn und die Hangabtriebskraft Fh .
Abbildung 6.2: Aufspaltung der Gewichtskraft in Normalkraft

und Hangabtriebskraft
77 Implementierungsaspekte
Die Normalkraft wird – unter Berücksichtigung der Kraftkomponente aus der Radauf-
hängung – aus der Bodeneindringung des Reifens ausgelesen (siehe Abschnitt 6.1.1.1).
Die Hangabtriebskraft muß berechnet werden. Gleichung (6.1) und (6.2) beschreiben die
Ermittlung des Richtungsvektors h, entlang dem die Hangabtriebskraft Fh verläuft. Die
Stärke von Gewichtskraft Fg und Hangabtriebskraft Fh läßt sich im rechtwinkeligen
„Kräftedreieck“ mit Hilfe der Trigonometrie bestimmen. Die Variable a bezeichnet einen
Vektor, der horizontal innerhalb der Bodenebene verläuft.
h = a×n (6.1)
a = Fg × n (6.2)
Da der Reifen nur in Längsrichtung abrollen kann, wird dem Reifen in Querrichtung
immer eine Kraft entgegengesetzt. Der Lateralanteil der Hangabtriebskraft ist zur Seiten-
führungskraft hinzuzuaddieren. In Longitudinalrichtung wirken sowohl Antriebskraft als
auch Bremskraft der Bewegung des Fahrzeuges entgegen. Deshalb muß der Longitudi-
nalanteil der Hangabtriebskraft nur beim völligen Blockieren der Reifen an den Starrkör-
per überführt werden.
Da ein Teil der Normalkraft zuerst in die Radaufhängung übertragen, und nach einem
Simulationsschritt wieder aus der Radaufhängung entnommen wird, kommt es zu gewis-
sen Rechenungenauigkeiten. Diese wirken sich auf die Berechnung der Seitenführungs-
kräfte aus. Steht das Fahrzeug quer am Hang, so ist ein leichtes Auf- und Abschwingen
bemerkbar. Dieses Schwingen ist durch die Radaufhängung bedingt und kann bei dem
vorliegenden Modellierungsansatz leider nicht umgangen werden.
6.1.2 Stoßberechnungen
Für die Berchnung eines Stoßes zwischen zwei Körpern werden folgende Größen benö-
tigt: Die beiden Massen, die Geschwindigkeiten, der Kollisionspunkt, und die beiden
Oberflächennormalen im Kollisionspunkt. Da die Übertragung des Stoßes immer zwi-
schen Boden und Fahrzeug stattfindet, kann zur Berechnung von J die vereinfachte For-
mel (2.37) aus Abschnitt 2.7.1 auf Seite 22 angewendet werden. Die Normale auf den
Starrkörper wird in Richtung des Geschwindigkeitsvektors angenommen.
Zugunsten der Laufzeiteffizienz verzichte ich auf eine Annäherung an den exakten Kolli-
sionszeitpunkt. Wird zum zum Zeitpunkt t eine Eindringungerkannt, so wird derselbe
Zeitpunkt t als Kollisionszeitpunkt betrachtet. Zusätzlich zu Masse und Geschwindigkeit
muß deshalb auch die Eindringungsdistanz aus den Attributen der Körper hervorgehen.
Diese wird benötigt, um bestehende Eindringungen wieder aufzulösen.
6.1.2.1 Radaufhängung
Bei der Zustandsüberführung der Radaufhängung stößt man auf folgendes Problem: der
Massepunkt kann sowohl nach unten (durch die Eindringung des Reifens in den Boden)
als auch nach oben in einen anderen Massekörper eindringen. Um gewährleisten zu kön-
nen, daß diese Eindringungen aufgelöst werden, wird die Position des Massepunktes vor
und nach der Überführung des Differentialsystemes auf die Einhaltung der Federwege
überprüft. Unter der Annahme, daß sich ein Stoß ausschließlich vom Bodenkontaktpunkt
der Reifen ausgehend in Richtung des Fahrzeuges fortpflanzen kann, werden die Ein-
dringungen so aufgelöst, daß der obere Massepunke auf Position des unteren angehoben
wird. Die Berechnung des Impulses für „eindimensionale“ Stöße wurde in Abschnitt 2.7
auf Seite 21, Gleichung (2.31) angegeben.
Der Starrkörper als oberster Massepunkt erfährt eine Spezialbehandlung. Damit die Ein-
dringungen aufgelöst werden können, muß seine Position bis zum nächsten Transforma-
tionsschritt um die Distanz der größten Eindringung aller vier Radaufhängungen nach
oben versetzt werden. Der Versatz wird entlang der Federachse vorgenommen.
Bei einem einzigen Kollsisionspunkt muß der Stoß genau durch den Schwerpunkt des
Starrkörpers verlaufen, um die Fallbewegung des Starrkörpers stoppen zu können. Bei
den Stößen, die von der Radaufhängung entlang der Federungsachse auf die Karosserie
übertragen werden, kann das nie der Fall sein. Außer, es werden mehrere Stöße gleich-
zeitig übertragen. In diesem Fall kann die „Verteilung der Auflagekräfte“ (siehe
Abschnitt 2.5 auf Seite 17) angewendet werden. Der berechnete Impuls wird zur Gänze
in das angulare Moment (in den Drehimpuls) überführt, aber nur zu den vorberechneten
Anteilen in das lineare Moment.
6.1.2.2 Stoßübertragung vom Reifen an den Starrkörper
Von den Reifen müssen nur jene Stöße direkt an den Starrkörper übertragen werden, die
nicht entlang der Federachse verlaufen. Auch hier muß berücksichtigt werden, daß ein
Stoß, der von nur einem der Reifen ausgeht, im wesentlichen nur einen Drall des Fahr-
zeuges bewirkt.
Für die Rückführung mehrerer Stöße kann die Horizontalverteilung aus Abschnitt 2.6
angewendet werden. Zusätzlich ist die Lage des Schwerpunktes zu berücksichtigen. Es
wirkt nur jener Anteil des Stoßes, der durch Projektion in Richtung des Schwerpunktes
aufgetragen werden kann.
Wird ein Stoß in mehreren Kontaktpunkten gleicheitig übertragen, so wird jener „virtu-
elle“ Angriffspunkt als Ursprung für den Stoß betrachtet, der sich zwischen den Kontakt-
punkten befindet. Wird beispielsweise auf beide Hinterräder ein Stoß in Längsrichtung
übertragen, so liegt der Ursprung für die Stoßübertragung auf halbem Weg zwischen den
beiden Hinterrädern.
6.1.3 Abstimmung der Radaufhängung

Die allgemeine Bewegungsgleichung für ein gedämpftes Federsystem ohne äußere
Krafteinflüße lautet [Efun 02]:
mx·· + dx· + kx = 0 (6.3)
Sind alle Parameter (Masse, Federsteifigkeit, Dämpfungswiderstand) konstant, so wird

aus der Differentialgleichung zweiter Ordnung eine lineare Differentialgleichung mit
konstanten Koeffizienten. Sie kann mit Hilfe der folgenden charakteristischen Gleichung
gelöst werden:
2 (6.4)
mA + dA + k = 0
Es sind drei Fälle zu unterscheiden:
2
1. d – 4mk < 0 : das System ist unterkritisch gedämpft. Die Amplituden klingen im
periodischen Schwingungsverlauf exponentiell ab.
2
2. d – 4mk = 0 : das System ist kritisch gedämpft. Die Amplitude nähert sich
schnellstmöglich ihrem Nullwert an, ohne zu überschwingen oder zu oszillieren.
2
3. d – 4mk > 0 das System ist überkritisch gedämpft. Je größer die Dämpfung, desto
länger dauert die Rückkehr der Masse in die Ruhelage („Kriechfall“).
unterkritische Dämpfung, kritische Dämpfung,

und überkritische Dämpfung (von oben nach unten)
Abbildung 6.3: Drei Formen eines gedämpften Schwingungsverlaufes

Die Achsfederung des Fahrzeuges sollte kritisch gedämpft sein. Dh., der Wert für die
Dämpferkonstante d ist bei 4km zu wählen. Mit m wird die Auflagekraft bezeichnet,
die auf der Radaufhängung lastet. Das ist etwa ein Viertel von der Masse des Fahrzeuges,
multipliziert mit der Erdbeschleunigung.
Hat das Fahrzeug ein Gewicht von 1200 kg und eine Federkonstante von 40 N/m, so ist
die Dämpferkonstante mit
d = 1200 / 4 * 9,81 * 40000 = 10849, 89
zu wählen. Typische Werte für die Federung eines PKW liegen bei 25 bis 50 N/mm. Vor-
der- und Hinterreifen sind meist unterschiedlich stark gefedert.
6.1.4 Berechnung der Teillastkurven

Wie bereits in Abschnitt 3.6.1.1 auf Seite 40 angeführt, muß die Drehmomentkurve für
den Teillastbetrieb skaliert werden. Die nachstehende Skizze zeigt die Skalierung eines
Kurvenpunktes:
Abbildung 6.4: Skalierung der Vollastkurve am Beispiel eines Kurvenpunktes
Gegeben sind der zu skalierende Kurvenpunkt P, der Schnittpunkt der Projektionsgera-

den mit der x-Achse S, und der Winkel, den die Projektionsgerade mit der x-Achse ein-
schließt. Dieser Winkel ist α . Gesucht ist der skalierte Punkt Ps . Um diesen Punkt zu
bestimmen, berechnet man zuerst die Distanz drpm. Skaliert mit der Geradensteigung k
ergibt sie die Auslenkung des Punktes P’. Ich bezeichne diesen Wert g0y. Die Summe
aus g0y und tq ergibt schließlich die Basis des rechtwinkeligen Dreieckes, dessen
Kathete a durch den Punkt Ps verläuft. Ich fasse mich kurz:

a = c * cos( α ) und
 
Ps = P – a ( 1 – d )  sin ( α )  (6.5)
 cos ( α ) 
d enspricht der Stellung des Gaspedals in einem Intervall von 0 bis 1.
Wie man bereits in Abb. 6.4 erkennen kann, liefert die Skalierung der vorliegenden Kur-
venpunkte keine Werte, die in die Abtastfrequenz der Kurve fallen: Die Skalierung des
Wertes bei 4500 Umdrehungen pro Minute liefert beispielsweise einen neuen Wert bei
4220,71 RPM. Kurvenpunkte werden aber nur alle 500 RPM gespeichert. Um dieses
Problem in den Griff zu bekommen, kann man sich den den gewünschten Abtastpunkten
mit Hilfe eines Bisektionsverfahren nähern.
Es soll das Drehmoment für eine vorgegebene Drehzahl bestimmt werden: Betrachtetes
Intervall ist das Ausdehnungsintervall der Kurve (Drehzahlbereich). Dieses Intervall
wird halbiert, und der auf halbem Drehzahlbereich ausgelesene Kurvenpunkt wird für
die gewünschte Gaspedalstellung skaliert. (Es können auch Kurvenpunkte zwischen den
Stützpunkten skaliert werden. Der Verlauf der Kurve zwischen den Stützpunkten wird
linear angenommen.) Liegt der skalierte Punkt links vom gewünschten Drehzahlbereich,
wird das Intervall für den nächsten Interationsschritt auf die obere Hälfte eingeschränkt.
Ansonsten auf die untere Hälfte. Nach etwa 12 bis 16 Interationsschritten hat man bereits
eine sehr gute Annäherung gefunden.
Achtung: Können aufgrund des Verlaufes der Vollastkurve mehrere Punkte auf einen
Drehzahlbereich abgebildet werden, wird dieses Verfahren nur einen dieser möglichen
Punkte berechnen. Solche Kurven müßten jedoch einen sehr ungewöhnlichen Verlauf
aufweisen und sind daher als Ausnahmefall zu betrachten. Sie werden in der Praxis nie-
mals auftreten.
Für die Berechnung der Teillastkurven in Abb. 6.5 wurden 16 Iterationsschritte verwen-
det. Der Schnittpunkt von Projektionsgerade und x-Achse liegt bei 1000 Umdrehungen.
Die Geraden schneiden einander in einem Winkel von 7,5 Grad. Im unteren Drehzahlbe-
reich lege ich ein minimales Drehmoment von 10 Nm fest. Im oberen Drehzahlbereich
werden die Kurven bei –70 Nm abgeschnitten. Damit wird die Bremswirkung des
Motors modelliert.
Abbildung 6.5: Berechnete Teillastkurven
6.1.5 Getriebeabstimmung
Das Beschleunigungsverhalten des Fahrzeuges wird durch die Motorisierung und durch
die Abstimmung des Getriebes bestimmt. Betrachtet man die Vollastkurve aus Abb. 6.5
in ihrem nutzbaren Bereich zwischen 1000 RPM und 6000 RPM, so ergeben sich unter
Anwendung der Getriebeübersetzungen aus Tab. 3.1 folgende Traktionskurven (siehe
Abb. 6.6). Der Reifenradius wurde mit 0,3m gewählt.
Beschleunigt das Fahrzeug beim Hochschalten nur träge bis gar nicht, sollte man die
Motorisierung austauschen, bzw. die Übersetzungsverhältnisse der Gänge näher zusam-
menlegen. Liegen die Gänge zu dicht beieinander, so kann das ebenfalls unerwünschte
Folgen haben, wie z.B. eine niedrigere Maximalgeschwindigkeit des Fahrzeuges.
Für sinnvolle Werte, ist es empfehlenswert, sich an den Daten von Fahrzeugherstellern
zu orientieren. Während die Getriebeübersetzung in jedem Typenschein angeführt ist,
sind die Daten der Drehmomentkurve leider meist nur schwer zugänglich. Die von mir
verwendete Vollastkurve orientiert sich an den in [Mons 01] angeführten Daten. Um eine
Übermotorisierung zu vermeiden, habe ich sie nach eigenem Ermessen etwas variiert.
Abbildung 6.6: Vollastkurve bei unterschiedlichen Getriebeübersetzungen
6.1.6 Luftwiderstand und Rollwiderstand

Aus Abb. 6.6 läßt sich eine Höchstgeschwindigkeit des Fahrzeuges von 55,7 m/s ausle-
sen. Das entspricht in etwa 200 km/h. Aufgrund der bei der Fahrt auftretenden Gegen-
kräfte wird diese Geschwindigkeit in der Praxis jedoch nie erreicht. Luftwiderstand und
Rollwiderstand der Reifen wirken der Traktionskraft entgegen und sorgen dafür, daß die
erreichbare Geschwindigkeit deutlich unter der theoretischen Höchstmarke liegt.
Während der Rollwiderstand linear angenommen werden kann, steigt der Luftwiderstand
quadratisch mit der Geschwindigkeit des Fahrzeuges [Mons 01]. Siehe (6.6).
2
Fdrag = 0, 5 ⋅ C w ⋅ A ⋅ ρ ⋅ v (6.6)
C w ist der Luftwiderstandsbeiwert,

A ist die Frontquerschnittsfläche des Fahrzeuges,
ρ ist die Luftdichte,
und v ist die Geschwindigkeit des Autos.
3
Die Luftdichte liegt bei etwa 1,29 kg/ m . Der C w -Wert ist von der Form des Fahrzeuges
abhängig und wird durch Windkanal-Test ermittelt. Bei einer Corvette liegt dieser Wert
etwa bei 0,30.
Aus dem 0,5-fachen aus Reibkoeffizient, Querschnittsfläche und Luftdichte läßt sich ein
Faktor berechnen, der mit dem Quadrat der Geschwindigkeit multipliziert die Luftwider-
standskraft ergibt. Ich bezeichne diesen Wert als Cdrag . Nehmen wir für die Corvette eine
2
Querschnittsfläche von 2,2 m an, so ist
Cdrag = 0,5 * 0,3 * 2,2 * 1,29 = 0,4257.
Abbildung 6.7: Traktions- und Fahrtwiderstandskräfte
Abb. 6.7 zeigt den Einfluß von Luftwiderstand und Rollwiderstand in Abhängigkeit von
der Geschwindigkeit des Fahrzeuges. Die erreichbare Höchstgeschwindigkeit wird durch
den Schnittpunkt von Traktionskraft und Fahrtwiderstandskraft (Summe aus Luftwider-
standskraft und Rollwiderstandskraft) festgelegt. Cdrag wurde mit 0,45 angenommen,
der Rollwiderstand mit dem 12-fachen der Fahrgeschwindigkeit. Es läßt sich erkennen,
daß der Luftwiderstand bis etwa 27 m/s dominiert. Ab 27 m/s übersteigt der Luftwider-
stand den Rollwiderstand.
Bei diesem Beispiel wurde die Getriebeübersetzung ungünstig gewählt. Aufgrund der
Gegenkräfte kann der fünfte Gang nicht voll ausgenutzt werden. Die Gegenkräfte über-
steigen Antriebskraft ab etwa 35 m/s. Im vierten Gang läßt sich das Fahrzeug auf eine
höhere Geschwindigkeit beschleunigen, als im fünften.
6.1.7 Rückkopplung von Motor und Antriebsrädern
Für die Realisierung des Antriebes muß das Drehmoment des Motors bestimmt und auf
die Antriebsräder übertragen werden. Nach Ablauf eines Simulationsschrittes wird die
Drehzahl aus den Rädern ausgelesen und an den Motor rückgeführt. Eine wichtige Rolle
in diesem Zyklus spielt der Kontakt zwischen Reifen und Straße.
6.1.7.1 Übertragung des Antriebsmomentes auf die Räder
Ob ein Rad mit dem Antrieb verbunden ist oder nicht, wird bei der Initialisierung des
Fahrzeuges festgelegt. Zur Laufzeit ergeben sich zwei weitere Faktoren, die einen Reifen
vom Antriebsstrang trennen können: Die Getriebe-Übersetzung (Leerlauf) und die
Kupplung. Diese beiden Faktoren sind ausschlaggebend dafür, welches Drehmoment
vom Motor auf die Räder übertragen wird.
Das Einlegen des Leerlaufes bedeutet, daß die Verbindung vom Motor zu den Antriebs-
reifen völlig unterbrochen wird. Die Räder werden wie freilaufende Räder behandelt.
Und zwar solange, bis wieder ein Gang eingelegt wird. Bei hergestellter Verbindung zum
Motor wird das übertragene Drehmoment mit einem Faktor skaliert, der den Zustand der
Kupplung wiedergibt. Der Wertebereich für den Faktor liegt zwischen 0 und 1. Das
Drehmoment wird entsprechend der Auflagekräfte auf die beiden (oder vier) Antriebs-
reifen verteilt.
6.1.7.2 Übertragung des Antriebsmomentes auf die Straße
Durch die Übertragung des Drehmomentes vom Motor auf die Antriebsräder entsteht in
den Kontaktpunkten zwischen Reifen und Straße eine Kraft. Diese Kraft wird durch die
Reibung in den Kontaktflächen verursacht. Sie bewirkt eine Beschleunigung des Fahr-
zeuges. Bedingt durch das Auflagegewicht und die Hafteigenschaften des Reifens kann
es sein, daß nur ein Teil der vom Motor erzeugten Kraft auf die Straße übertragen wird.
Übersteigen Traktionskraft und Seitenführungskraft das Haftungslimit des Reifens, so
bricht er aus aus und geht er in den Zustand der Gleitreibung über (siehe Abschnitt 3.4.1
auf Seite 34).
Um die Reibkraft zwischen Reifen und Straße zu bestimmen, muß zunächst die Radlast
ermittelt werden. Das ist die Kraft, mit der der Reifen gegen den Boden gedrückt wird.
Bildet man die Summe der Kräfte, die in den Feder- und Dämpferelementen von Reifen
und Federung gespeichert sind, so erhält man jene Kraft, die vom Auflagepunkt des Rei-
fens aus auf den Starrkörper ausgeübt wird. Der Anteil, der den Starrkörper daran hin-
dert, in den Boden einzudringen, ist die Radlast. Man erhält sie durch Projektion des
Kraftvektors auf die Bodennormale. Mit Hilfe der Radlast kann die maximal zulässige
Reibkraft in der Bodenkontaktfläche berechnet werden. Sie bestimmt, ob sich der Reifen
im Zustand der Haftreibung oder im Zustand der Gleitreibung befindet. Abhängig davon
wird die Reibkraft ermittelt (siehe Abschnitt 2.8 auf Seite 25).
6.1.7.3 Bestimmung der Reifendrehzahl
Für einen Reifen mit Bodenkontakt gilt es vier Fälle zu unterscheiden:
1. Reifen ist mit Antrieb gekoppelt und hat volle Bodenhaftung.
2. Reifen ist mit Antrieb gekoppelt und hat die Bodenhaftung verloren (Gleitreibung).
3. Reifen ist vom Antrieb entkoppelt und hat volle Bodenhaftung.
4. Reifen ist vom Antrieb entkoppelt und hat die Bodenhaftung verloren.
Für einen Reifen ohne Bodenkontakt sind zwei weitere Fälle zu betrachten:
1. Reifen ist mit Antrieb gekoppelt.
2. Reifen ist vom Antrieb entkoppelt.
Reifen ohne Bodenkontakt
Betrachten wir zunächst den ersten Fall für einen Reifen ohne Bodenkontakt. Da dem
Reifen kein Widerstand entgegengesetzt wird (ich vernachnachlässige die Masseträgheit
des Reifens, seinen Luftwiderstand, und Reibverluste durch die Lagerung), geht das
gesamte Antriebsmoment des Motors in den Drehimpuls des Reifens über.
Für den zweiten Fall reicht es, die Eigenrotation des Reifen aufrechtzuerhalten.
Reifen mit Bodenkontakt
Im ersten Fall für einen Reifen mit Bodenkontakt wird eine einfache Abrollbewegung
ausgeführt. Die Rotationsgeschwindigkeit des Reifens wird durch Projektion der Fahr-
zeuggeschwindigkeit auf den Laufrichtungsvektor des Reifens ermittelt.
Die Rückführung der Drehzahl im zweiten Fall ist etwas komplizierter. Der Reifen
besitzt weder vollen Bodenkontakt, noch kann er sich völlig ungehindert drehen. Um
dennoch eine Drehzahl bestimmen zu können, muß der Einfluß des Bodenkontaktes auf
den Reifen angenähert werden. Als brauchbar hat sich folgende Methode erwiesen:
Die Drehzahl des Reifens bei vollem Bodenkontakt (Reifen mit Bodenkontakt, Fall 1)
und bei fehlendem Bodenkontakt (Reifen ohne Bodenkontakt, Fall 1) lassen sich ermit-
teln. Außerdem kann man unter Berücksichtigung des Auflagegewichtes jenen Anteil
der im Auflagepunkt des Reifens anliegenden Kraft bestimmen, der tatsächlich auf die
Straße übertragen wird. Skaliert man zwischen den beiden ermittelten Drehzahlen im
Verhältnis von übertragener Kraft zu nicht übertragener Kraft, so hat man eine ganz gute
Annäherung gefunden.
Der dritte Fall ist gleich dem ersten Fall zu behandeln.

Der vierte Fall ist gleich dem zweiten Fall zu behandeln.
6.1.7.4 Motorrückkopplung
Für die Rückkopplung der Antriebsräder mit dem Motor wird deren Drehzahl verwendet.
Diese Drehzahl bestimmt das neue Drehmoment des Motors. Im Normalfall wird jedoch
mehr als ein Rad vom Motor angetrieben. Deshalb müssen die rückgeführten Drehzahlen
auf einen Wert abgebildet werden. Ich verwende hierfür das Maximum. Damit kann der
Motor in einem höheren Drehzahlbereich gehalten werden.
Bei eingelegtem Gang und Bodenkontakt der Reifen funktioniert dies alles ganz gut.
Legt man jedoch den Leerlauf ein wird die Verbindung des Motors zu den Antriebsrä-
dern getrennt. In diesem Zustand können keine Drehzahlen ausgelesen werden. Der
Motor wird in seinem momentanen Zustand verweilen. Damit das nicht passiert, ver-
wende ich eine Pseudo-Schwungmasse. Sie besizt eine gewisse Trägheit und speichert
den Drehimpuls, der durch das Drehmoment des Motors aufgebaut wird. Dadurch ist es
möglich, den Motor auch im Leerlauf hochdrehen zu lassen.
6.1.8 Bremse
Grundsätzlich berechnet sich die Bremskraft, die durch die Reibung der Bremsklötze auf
der Bremsscheibe entsteht durch Multiplikation des Bremsdruckes mit dem Reibkoeffi-
zienten. Rotiert ein Reifen jedoch nur sehr langsam oder gar nicht, so kann durch das
Betätigen der Bremse ein entgegengerichteter Drehimpuls aufgebaut werden. Das ist
unerwünscht. Die Bremse soll den Drehimpuls verringern aber nicht umkehren.
Um zu verhindern, daß das Fahrzeug beim Betätigen der Bremse über den Stillstand hin-
aus negativ beschleunigt wird, muß die ausgeübte Bremskraft mit der Winkelgeschwin-
digkeit des Reifens abgeglichen werden. In dem Drehzahbereich, in dem das Betätigen
der Bremse zum sofortigen Stillstand der Räder führt, gilt der statische Reibkoeffizient.
Im darüberliegenden Drehzahlbereich werden die Räder nur abgebremst. Die Brems-
klötze reiben an der Bremsscheibe. Dh., es muß der kinetische Reibkoeffizient verwen-
det werden.
6.1.9 Lenkgeometrie
Die Ackermann-Bedingung wurde bereits in Abschnitt 3.5.1 auf Seite 37 angesprochen.
Das folgende Diagramm zeigt den detaillierten Zusammenhang zwischen den Lenkwin-
keln der beiden Vorderreifen und dem Kurvenradius R.
Abbildung 6.8: Bestimmung der Lenkwinkel nach Ackerman
Der trigonometrische Zusammenhang (6.7) erlaubt die Berechnung des inneren Lenk-
winkels δ i . Der äußere Lenkwinkel δ a kann mit Hilfe der Gleichungen (6.8) und (6.9)
bestimmt werden.
l
sin δi = --- (6.7)
R
l
tan δa = ----------------- (6.8)
(b + B)
2 2 (6.9)
B = R –l
Für die Simulation ist es wünschenswert, den Lenkeinschlag der Räder normalisiert auf
das Intervall [-1,1] anzugeben. -1 steht für maximalen Einschlag links, 1 für maximalen
Einschlag rechts. Basierend auf dem Wendekreis des Fahrzeuges läßt sich dieser maxi-
male Lenkeinschlag für jedes der Vorderräder vorberechnen. Zur Bestimmung des Lenk-
einschlages zur Laufzeit reicht eine lineare Skalierung der Winkel zwischen 0 und 1.
6.1.10 Fahrzeugkontrollen
Zur Steuerung des Fahrzeuges werden fünf Parameter benötigt. Der Fahrer hat die Mög-
lichkeit über Lenkung, Gaspedal, Bremspedal, Kupplung und Gangschaltung in das
Fahrverhalten einzugreifen (siehe Abb. 6.9). Siehe dazu auch [Rill 01].
Abbildung 6.9: Eingriffsmöglichkeiten des Fahreres auf die

Steuerung des Fahrzeuges
Der Zustand der Kontrolen wird in der Fahrzeugklasse verwaltet. Das Auslesen und Ver-
ändern der Werte geschieht durch ein Objekt der Klasse Driver. Es liest die Eingaben des
Benutzers von der Tastatur ein und versucht aufgrund dessen eine möglichst plausible
Ansteuerung der Kontrollen umzusetzen. Da die Tastatur ein digitales Eigabemedium ist,
können die analogen Fahrzeugkontrollen nur mit einer entsprechenden Programmlogik
sinnvoll genutzt werden. Nur die Gangschaltung besitzt einen diskreten Wertebereich
und kann daher direkt manipuliert werden.
Abbildung 6.10: Modellierung des von Gas und Kupplung beim

Schaltvorgang
Die Erhöhung der Werte für Lenkung, Gaspedal, Bremse und Kupplung erfolgt linear.
Die Wertzuwachsrate ist mit der Systemzeit gekoppelt. Gültige Werte liegen jeweils
jeweils zwischen 0 und 1, bei der Lenkung zwischen -1 und 1. Während die Veränderung
von Lenkung, Gas und Bremse an einen Tastendruck gebunden sind, wird die Kupplung
automatisch betätigt. Und zwar bei jedem Schaltvorgang. Beim Einlegen eines neuen
Ganges wird die Kupplung voll durchgetreten und dann langsam kommen gelassen
(siehe Abb. 6.10).
Graphik Engine 90
Die Zeitspanne zum Einschleifen der Kupplung sollte nach möglichkeit so gewählt sein,
daß ein Abgleich zwischen Motordrehzahl und Fahrzeuggeschwindigkeit möglich ist.
Bei zu schnellem Einkuppeln würde entweder der Motor „abgewürgt“ werden, oder die
Räder würden beginnen, sich durchzudrehen. Die Wertzuwachsraten sind als Konstante
in der Klasse Driver festgelegt.
6.2 Graphik Engine

Die Graphik-Engine basiert auf DirectX 8.1 [DX8 00] und dem Win32 API [Petz 98].
Für die Schnittstelle habe ich mich aus zweierlei Gründen entschieden: Zum einen bietet
DirectX ein eigenes Dateiformat, das das Laden und Visualisieren von Polygonmodellen
für den Programmierer stark vereinfacht. Der Export in das .x Dateiformat wird für die
meisten 3D Modellierungs-Werkzeuge unterstützt.
Obgleich sich OpenGL [OpGL 98] (gerade auch im professionellen Bereich) mittler-
weile seit längerem als Standard etabliert hat, bietet DirectX 8.1 für den Programmierer
durchaus auch seine Vorzüge. Vor allem die Programmer’s Reference von Microsoft ist
mir in diesem Zusammenhang positiv aufgefallen. Die Verwendung der Schnittstelle ist
dort sehr übersichtlich und auch umfangreich beschrieben. Sie ist als Windows Compi-
led HTML Help File (chm-Datei) aufbereitet. Außerdem werden mit dem DX8 SDK
einige Programmierbeispiele mitgeliefert, die die Verwendung von häufig benötigten
Funktionen demonstrieren.
Ursprünglich hatte ich geplant, die Schnittstelle der Graphik-Engine so allgemein zu hal-
ten, daß die DirectX Implementierung später jederzeit ohne größeren Aufwand gegen
eine OpenGL Implementierung ausgetauscht werden kann. In Anbetracht des relativ gro-
ßen Funktionsumfanges von DirectX, einer notwendigen Neudefinition vieler Konstan-
ten und des sehr geringen Innovationsanteiles bei dieser Tätigkeit habe ich aber schließ-
lich darauf verzichtet. Der Zugriff auf das Direct3D-Device wird von der Graphik-
Engine auch an weitere Klassen abgetreten. Dadurch wird zwar das Prinzip einer saube-
ren Schnittstellentrennung verletzt. Für eine schnelle, kontextbezogene Anpassung der
Ausgabezustände (Render States) erscheint diese Vorgehensweise aber dennoch sinnvoll.
Die Zustandsänderung des Ausgabegerätes obliegt nicht alleine der Graphik-Engine.
Als Anhaltspunkt für die Implementierung der Graphik Engine diente unter anderem die
Zen-X Engine [Arce 02], eine auf DirectX 8 basierende Open Source Graphik Engine.
Sie kann kostenlos über das Internet bezogen werden. Während die Zen-X Engine eine
relativ umfangreiche Graphikschnittstelle darstellt, beschränkt sich die vorliegende
Implementierung auf nur wenige, sehr grundlegende Funktionen. Diese Funktionen sol-
len die Programmierung der Graphikausgabe erleichtern. Sie stellen eine funktionale
Abstraktion von ausgewählten Bereichen der DirectX-Schnittstelle dar.
Folgende Funktionen werden angeboten:
• Initialisierung eines DirectX Renderdevice im Fenster- oder im Vollbild Modus.
• Matrizenoperationen für Weltmatrix, Sichtmatrix und Projektionsmatrix.

• Laden und Ausgeben von DirectX-Meshes
• Beleuchtung und Nebel
• Ausgabe von Overlay-Graphiken (siehe Anhang D)
• Tastaturabfragen
• Timer-Funktion zur Ermittlung der Bildwiederholrate
6.2.1 Matritzenoperationen
In DirectX erfolgt das Setzen der Weltmatrix (D3DTS_WORLD), der Ansicht
(D3DTS_VIEW) und der Projektionsmatrix (D3DTS_PROJECTION) über den Befehl
SetTransform. Werden mehrere Transformationsschritte auf eine der Matritzen ausge-
führt (Rotation, Translation, Skalierung, etc.), so reicht es, die entsprechenden Multipli-
kationen vorerst auf eine lokale Matrix auszuführen. Das Setzen der Transformationszu-
stände ist erst unmittelbar vor der Zeichenausgabe nötig. Die Graphik Engine übernimmt
diese Aufgabe für die Ausgabe von DirectX-Meshes über den Befehl drawObject.
6.2.1.1 Weltmatrix
Die Weltmatrix dient zur Ausgabe-Transformation von Graphikobjekten. Die globale

Variable matWorld, in welcher der Zustand der Weltmatrix gespeichert ist, wird zu
Beginn eines jeden Render-Zyklus auf die Einheitsmatrix zurückgesetzt. Dies geschieht
in der Methode beginRendering. Für die Transformation der Matrix stehen folgende
Befehle zur Verfügung:
• pushMatrix: Sichern der aktuellen Weltmatrix (maximal 8 Sicherungsstände).
• popMatrix: Wiederherstellen der zuletzt gesicherten Matrix.
• identity: Rücksetzen der Weltmatrix auf die Einheitsmatrix.
• translate: Translation auf die Weltmatrix anwenden.
• rotateH: Rotation um die y-Achse auf die Weltmatrix anwenden (Heading).
• rotateP: Rotation um die z-Achse auf die Weltmatrix anwenden (Pitch).
• rotateR: Rotation um die x-Achse auf die Weltmatrix anwenden (Roll).
• multiplyMatrix: Multiplikation der Weltmatrix mit beliebiger Transformationsmatrix.
Vor Aufruf der Methode drawObject (Ausgabe geladener DirectX-Meshes) bleiben jegli-
che Veränderungen der Variable matWorld ohne Auswirkung auf die DirectX Ausgabe-
Transformation.
Graphik Engine 92
6.2.1.2 Projektionsmatrix
Die Projektionsmatrix wird mit Hilfe der folgenden Methoden gesetzt: (Die Änderungen
werden direkt in die Render-Pipeline [D3DP 98] übernommen.)
• setFOV: Setzt den halben Öffnungswinkel des Viewing-Frustums (Field Of View).

Die Angabe des Winkels erfolgt in Grad.
• setNearFar: Setzen der Near- und der Far-Clipping Plane des Viewing-Frustums.
• setAspect: Seitenverhältnis des Ausgabemediums spezifizieren (Höhe durch Breite in

Pixeln)
• setProjectionMatrix: Erlaubt das Setzen aller drei vorangegangener Eigenschaften

mit einem Methodenaufruf.
6.2.1.3 Sichtmatrix
Die Sichtmatrix wird laufend über ein Objekt des Types GFX_Camera aktualisiert. Das
Objekt ist dynamisch an die Graphik Engine gebunden. Die Anpassung der Render-Pipe-
line an die Sichtmatrix erfolgt in der Methode beginRendering. Dort wird die Methode
GFX_Camera::update aufgerufen. Sie bewirkt ein Setzen des Transformationszustan-
des. Die Kamera kann mit folgenden Methoden ausgerichtet werden:
• setPosition: Setzen der Kameraposition.
• setTarget: Angabe des (statischen) Punktes im Raum, auf den die Kamera ausgerich-
tet werden soll.
• setUpVector: „Stativ-Achse“ der Kamera spezifizieren.
• set: Erlaubt das Setzen aller drei vorangegangenen Eigenschaften mit einem Metho-
denaufruf.
6.2.2 Das DirectX Dateiformat

Das DirectX Dateiformat ist ein Template-basiertes Dateiformat. Es erlaubt das Spei-
chern von Meshes, Texturen, Animationen und benutzerdefinierbaren Objekten. Das
Format wurde mit DirectX 2.0 eingeführt. Eine Binärversion des Formates gibt es seit
DirectX 3.0. Schnittstellen zum Schreiben und Lesen der .x Dateien sind ab Version 6.0
verfügbar. Leider jedoch enthält die Dokumentation zum DirectX 8.1 SDK nur wenige
Informationen zum Aufbau des Formates. Die Referenz von Paul Bourke [Bour 99] ist
eine der wenigen Informationsquellen, die man zum DirectX Dateiformat findet.
Das Laden und Darstellen von .x Dateien kann mit den in den Direct3DX Utility Library
[D3DX 02] enthaltenen Funktionen realisiert werden. Über die Funktion D3DXLoad-
MeshFromX werden die Polygoninformationen aus der Datei in ein Mesh-Objekt ausge-
lesen. Das Mesh gliedert sich in mehrere Teilnetze (Subsets) mit unterschiedlichen Mate-
rialeigenschaften und Texturen.
Das DirectX SDK stellt Werkzeuge zur Verfügung, um 3D-Modelle in das .x Dateifor-
mat zu konvertieren (Conv3ds.exe) und zu exportieren (Plugins für gängige 3D Modeler
wie 3D-Studio Max u.a.). Damit lassen sich Modelle erstellen, die später für die Visual-
isierung des Fahrzeuges verwendet werden.
6.2.3 Beleuchtung und Nebel

Über die Graphik Engine kann sowohl das Umgebungslicht spezifiziert, als auch eine
gerichtete Lichtquelle angegeben werden. Im Gegensatz zu einer punktförmigen Licht-
quelle werden bei diesem Modell alle Lichtstrahlen parallel angenommen. Das entspricht
am ehesten einer Beleuchtung mit Sonnenlicht. Durch die Verwendung von exponentiel-
lem Nebel wird zusätzlich ein atmosphärischer Effekt erzielt. Der Himmel (Löschen des
Framebuffers) und der Nebel-Effekt werden in der gleichen Farbe gezeichnet.
6.3 Terrain Engine

Die Terrain-Engine ist eine eigenständige DirectX Implementierung. Die Graphik
Engine wird nur referenziert, um den Zeiger auf das Direct3D-Device zu erhalten. Eine
weitere Abhängigkeit zur Klassenhierarchie ergibt sich durch die Implementierung des
Intersektionstestes zwischen Reifen und Bodenoberfläche.
6.3.1 Repräsentation der Daten

Die Terraindaten werden aus einer .ter-Datei entnommen. Das Format wurde eingeführt,
um neben der Höheninformation auch geotypische Informationen über die Landschaft
speichern zu können. Der Aufbau des Formates ist in Anhang D beschrieben. Es setzt
sich aus Header, Höhenmap und Featuremap zusammen. Die Featuremap besitzt die
selbe Auflösung wie die Höhenmap und ordnet einem jeden Vertex einen Bodentyp zu.
Im Header sind neben den globalen Terrain-Spezifikationen wie Auflösung, Höhenska-
lierung und Rasterweite spezifische Informationen für jeden Geotyp abgelegt. Insgesamt
können fünfzehn Geotypen definiert werden.
Für jeden Geotyp kann genau eine Texturreferenz angegeben werden. Als Darstellungs-
information wird außerdem ein Skalierungswert benötigt (eine Texturkachel erstreckt
sich auf wieviele Meter Länge?). Zusätzlich können Reibwert und Rollwiderstandswert
vergeben werden. Die Zuordnung eines Höhenoffsets erlaubt es, das eine Byte an
Höheninformation für jeden Geotyp auszunutzen. Dh., bei 15 Geotypen sind maximal
15x256=3840 Höhenabstufungen möglich.
Verwendet man die Angabe des Offsets, so wird das Editieren der Höhendaten
erschwert: Ein Grauwert kann nicht mehr eindeutig einem Höhenwert zugeordnet wer-
den – für die Bearbeitung wird ein spezieller Editor benötigt.
Warum nur 15 und keine 256 Geotypen zugelassen werden hat den folgenden Grund: Zur
Laufzeit können die oberen 4 Bit eines Datenbytes für die Unterbringung der Quadtree
Terrain Engine 94
Struktur verwendet werden: 1 Bit dient als Quadtree-Flag (verzweigt der Quadtree an
dieser Stelle oder nicht?). Die restlichen 3 Bit geben die Detailstufe an, in denen der Ter-
rainblock dargestellt werden soll (diese Information wird ausschließlich in den Blättern
des Quadtrees benötigt). Diese Belegung erlaubt eine Auflösung von maximal 129x129
Vertices pro Terrainblock.
Zusätzlich ist der erste der 16 Geotypen als „Null-Wert“ reserviert. Er kann als Kenn-
zeichnung für die „Abwesenheit“ von Bodendaten verwendet werden. Damit ist es mög-
lich, gewisse Stellen bei der Triangulierung des Terrains auszulassen. Er kann für die
Einbindung größerer Objekte (Gewässer, Felsen, Überhänge, Gebäude, ...) genutzt wer-
den.
6.3.2 Bestimmung des Höhenwertes für einen beliebigen Geländepunkt

Das Höhenfeld liefert nur für gewisse Punkte innerhalb der Landschaft eine exakte
Höheninformation. Diese Information wird für die Erstellung des Polygongitters ver-
wendet, das die Geländeoberfläche beschreibt. Einem jeden Vertex ist genau ein Wert
des Höhenfeldes zugeordnet. Möchte man den Höhenoffset in einem beliebigen Punkt
des Polygongitters bestimmen, muß zwischen den vorliegenden Daten interpoliert wer-
den.
Durch die Triangulierung wird jedes Rasterquadrat in zwei Dreiecke zerlegt. Nur so
kann garantiert werden, daß jedes der Polygone innerhalb einer Ebene aufgespannt wird.
Ob die Teilung eines Rasterqudrates entlang der einen Diaglonale oder entltang der
anderen Diagonale erfolgt, liegt in der Entscheidung des Programmierers. Um den
Höhenverlauf sauber wiedergeben zu können, kann die Wahl der richtigen Diagonale
allerdings entscheidend sein. Ich verwende der Einfachheit halber für jedes Quadrat die
gleiche Diaglonale. Das vereinfacht sowohl den Aufbau des Polygongitters als auch die
Interpolation des Höhenwertes.
Eine effiziente Methode zur Interpolation des Höhenwertes ist die folgende:
Als erstes muß der Punkt dem darunterliegenden Polygon zugeordnet werden. Die Eck-
punkte des Polygons bezeichne ich als y00, y10, y01 und y11. Die Punkte, deren Höhen-
information bestimmt werden sollen, tragen die Bezeichnungen P1, P2 und P3 (siehe
Abb. 6.11).
Abbildung 6.11: Interpolation eines Höhenwertes
Durch die Unterteilung des Polygons in zwei Dreiecke werden drei Fälle unterschieden:
1. P liegt in Ebene 1 (dx > dz)
2. P liegt in Ebene 2 (dx < dz)
3. P liegt auf der Schnittkante der beiden Ebenen (dx = dz)

(dieser Fall kann gleich dem Fall 1 oder dem Fall 2 behandelt werden)
Bei Betrachten des Punktes P1 läßt sich erkennen, daß dieser in Ebene 1 liegt. Für die
berechnung des Höhenwertes wird die Projektion des Polygons in die xz-Ebene auf ein
Quadrat mit der Seitenlänge eins skaliert.
Das Teilungsvehältnis f ergibt sich aus dem Strahlensatz:
dx : dz = f : 1.
Der Punkt yf wird über die Höhendifferenz zwischen y01 und y11 gefunden:
yf = y10 + f * (y11 – y10)
Die Lage von P1 ist:

P1 = y00 + dx * (yf – y00)
6.3.3 Reifen-Boden Kollision

Das Reifenmodell besitzt nur eine einzige Feder, entlang derer sich eine Kraft entwik-
keln kann. Deshalb muß die Schnittberechnung zwischen Reifen und Bodenoberfläche
auf einen einzelnen Eindringungsvektor zurückgeführt werden. Länge und Orientierung
des Vektors geben Richtung und Stärke der Federstauchung an.
Wie bereits in Abschnitt 3.3.2.1 auf Seite 33 erwähnt, verwende ich für die Berechnung
der Bodenkollision eine kugelförmige Reifengeometrie. Sie nähert sich der tatsächlichen
Form eines Reifens zwar nur sehr unzureichend an. Für den Bereich der Kugel, über den
Terrain Engine 96
sich das Reifenvolumen erstreckt, liefert das Modell jedoch eine ausreichend gute Nähe-
rung. Das Kollisionsmodell kommt mit jedem Geländeanstieg zurecht.
6.3.3.1 Berechnung des Eindringungsvektors
Um die Eindringung der Kugel auf einen Vektor zurückzuführen, müssen alle Normal-
eindringungen der Kugel in die Bodenoberfläche bestimmt werden. Betrachtet man die
Ausdehnung des Reifens, projiziert auf die xz-Ebene, so lassen sich alle Polygone ermit-
teln, für die eine Schnittberechnung durchgeführt werden muß (siehe Abb Abb. 6.12).
Für diese Polygone gilt es, die Ebenengleichgungen aufzustellen, und den Normalab-
stand des Reifenmittelpunktes zu den einzelnen Ebenen zu ermitteln. Um sicherzustel-
len, daß sich die Normalprejektion des Reifenmittelpunktes auch innerhalb des betrach-
teten Polygones befindet, muß der projizierte Schnittpunkt gegen die Ausdehnung des
Polygones getestet werden. Dabei kann man ähnlich wie bei Bestimmung des Höhen-
wertes (Abschnitt 6.3.2) vorgehen: Liegt der Punkt innerhalb des Rasterquadrates, so
bestimmt man den Anstieg der Geraden zwischen linkem oberem Eckpunkt und dem
Projektionspunkt. Ist der Anstieg kleiner gleich 1, so liegt der Punkt im oberen Polygon,
ansonsten im unteren.
Abbildung 6.12: Auswahl der Polygone für die

Schnittberechnung mit dem Reifen
Als Eindringungsdistanz wird das arithmetische Mittel alles Ebeneneindringungen

betrachtet. Der Richtungsvektor für die Eindringung ergibt sich aus der Summe aller
Eindringungsvektoren. Er wird auf Einheitslänge skaliert und als Normale der Bodenein-
dringung an den Reifen übergeben. Der „Kontaktpunkt“ zwischen Reifen und Boden-
oberfläche liegt auf der Geraden, die sich vom Reifenmittelpunkt aus in Richtung der
Bodennormalen erstreckt. Seine Distanz zum Reifenmittelpunkt des ist durch den Radius
und die Eindringungsdistanz des Reifens festgelegt.
6.3.3.2 Laufrichtungsvektor
Die Longitudinalkräfte sind jene Kräfte, die (durch eine beschleunigte Abrollbewegung)
in der Laufrichtung des Reifens entstehen. Den Vektor, der ihre Orientierung angibt,
bezeichne ich als Laufrichtungsvektor. Er verläuft tangential zum Reifenzylinder und
parallel zur Bodenebene, die durch die polygonale Oberflächenstruktur im Kontaktpunkt

angegeben wird. Er beschreibt keine Kraft sondern eine Richtung.
Um diesen Richtungsvektor zu bestimmen, muß das Kreuzprodukt der Bodennormale

mit der Achsrichtung des Reifens gebildet werden. Der Laufrichtungsvektor gibt den
Verlauf der Schnittgerade wieder, die zwischen Bodenebene und „Reifenebene“ gebildet
wird (siehe Abb. 6.13).
Abbildung 6.13: Bestimmung der Laufrichtung des Reifens
6.3.4 Initialisierung des Quadtrees

Da die Featuremap nur zur Hälfte mit Nutzdaten belegt ist, wird der restlichen Platz zur
Speicherung der Quadtree-Struktur und der LOD-Informationen für die auszugebenden
Terrainblöcke verwendet (siehe Abschnitt 6.3.1). Die Vorgehensweise bei der Initiali-
sierng des Quadtrees wurde in Abschnitt 4.3.3 auf Seite 51 allgemein beschreiben. Dem
möchte ich an dieser Stelle das Unterteilungskriterium und die Berechnung des Detaille-
vels hinzufügen, in dem ein Terrainblock visualisiert werden soll.
Die Funktion getY liefert den Wert aus dem Höhenfeld an der Stelle (x,z). Die Konstante
TERRAINBLOCK_WITH gibt die Auflösung eines Terrainblocks an. set_qt_lod setzt das
Detaillevel für den Terrainblock an der Stelle (x,z). Es wird mit Hilfe der Funktion cal-
cLOD berechnet.
01 setup_quadtree( int x, int z, int width )

02 {
03 // subdivision criterion (frustum culling)
04 if( cubeInFrustum( x,getY(x,z),z, width ))
05 {
06 set_qt_flag( x, z );
07
08 width /= 2;
09 if( width < TERRAINBLOCK_WIDTH )
10 {
11 set_qt_lod( x,z, calcLOD(x,z) );
12 }
13 else
Terrain Engine 98
10 {
11 setup_quadtree( x-width, z-width, width );
12 setup_quadtree( x+width, z-width, width );
13 setup_quadtree( x-width, z+width, width );
14 setup_quadtree( x+width, z+width, width );
15 }
16 }
17 else
18 {
19 clear_qt_flag( x, z );
20 }
21 }
In Verbindung mit der Auto-Simulation bereitet das von [Boer 00] vorgestellte Verfahren
zur Bestimmung der Detail-Stufe gewisse Probleme: An manchen Stellen ist ein „Versin-
ken“ der Autoreifen im Boden bemerkbar. Um die Darstellung zu korrigieren, ist ein
höherer Detailgrad bei der Triangulierung der Terrainblöcke erforderlich. Da das Versin-
ken der Reifen mit zunehmender Distanz zur Kamera vermehrt auftritt, lasse ich gerin-
gere Detail-Stufen erst ab einer gewissen Kameradistanz zu. Ein höherer Detaillevel
kann jedoch aufgrund des ersten Kriteriums auch in einem näher gelegenen Bereich
erforderlich sein. Der von mir verwendete Algorithmus sieht wie folgt aus:
01 calcLOD( int x, int z, float dist2 )

02 {
03 const int C = 8;
04
05 int L = LOD_MIN; // höchstes Detail = 0
06 int d = (1 << L) * C;
07 while( ( dist2<(Dn2(x,z,L-1) || dist2<d*d ) && L>0 )
08 {
09 L--;
10 d = (1 << L) * C;
11 }
12 return L;
13 }
Beginnend bei der kleinstmöglichen Detailstufe (LOD_MIN) wird die Detailstufe

solange erhöht, bis ein zulässiger Wert für die vorliegende Kameradistanz gefuden wird.
Um die Verwendung der Quadratwurzel-Funktion zu vermeiden, wird mit dem Quadrat
der Kameradistanz (dist2) und dem Quadrat der Mipmap-Distanzen gerechnet (Dn2).
Die minimale Distanz für den Detaillevel L wird in Anlehnung an das Kriterium von
[RHSS 97] durch die Größe eines Polygones im Terrainblock und einen konstanten Fak-
tor C festgelegt. C richtet sich nach der Schrittweite des Grundrasters. Zufriedenstel-
lende Ergebnisse konnten ab einem Wert von C = 8 erreicht werden.
6.3.5 Der Render-Durchlauf

Der Render Durchlauf beschränkt sich darauf, den erzeugten Quadtree noch einmal zu
durchlaufen, und dabei all jene Terrainblöcke zu rendern, die bei der Erzeugung des
Quadtrees dafür ausgewählt wurden. Der zweite Durchlauf ist deshalb nötig, weil erst
mit dem vollständigen Quadtree alle Terrainblöcke bestimmt sind. Um die nötigen Detai-
lübergänge schaffen zu können, muß die Detailstufe der angrenzenden Terrainblöcke

bekannt sein.
6.3.6 Texturierung
Die Texturierung des Terrains erfolgt unter Verwendung von zwei Texturen: Eine Grund-
textur wird mit unterschiedlicher Intensität von einer zweiten Textur überblendet. Die
Stärke der Überblendung richtet sich nach den Informationen aus der Höhenmap. Auf
Null-Niveau beträgt der Überblendungsfaktor 0 %, bei maximaler Höhenauslenkung
wird die Grundtextur zu 100 % überdeckt. Diese Transparenzinformation wird als Ver-
tex-Alpha an die Graphikkarte übergeben. Da die meisten Graphikkarten die Ausgabe
von (mindestens) zwei Texturen in einem Durchgang unterstützen (single-pass multi-tex-
turing), ergeben sich daraus keine Einbußen bei der Ausgabegeschwindigkeit. Die Textu-
ren werden über die gesamte Landschaft hinweg wiederholt (gekachelt) aufgetragen.
Alternative Methoden zur Aufbringung einer Landschaftstextur wurden in Abschnitt 4.4
auf Seite 59 behandelt.
6.3.6.1 Automatische Generierung von Texturkoordinaten
Um den Datendurchsatz von der CPU an die Graphikkarte zu verringern, ist es empfeh-
lenswert, die Texturkoordinaten automatisch generieren zu lassen. Dabei werden die 3-
dimensionalen Vertexkoordinaten durch die Multiplikation mit einer Projektionsmatrix
in 2-dimensionale Texturkoordinaten transformiert. Da die Vertex-Transformationen auf
der Graphikkarte stattfinden, wird damit nicht nur der AGP-Bus, sondern auch die CPU
entlastet.
Um die Render-Pipeline entsprechend aufzusetzen, muß DirectX eine Transformations-

matrix übergeben werden. Da die Transformation nur im „Camera-Space“ durchgeführt
werden kann (also zusätzlich die Kamera-Transformationsstufe durchläuft), muß die
Transformationsmatrix zuvor mit der Inversen der Sichtmatrix multipliziert werden.
Nehmen wir an, das Tripel (x,y,z) beschreibt die Position des Vertex, view ist die Sicht-
matrix und mat die Projektionsmatrix für die Textur-Transformation, so wird von der
Graphikhardware folgender Ausdruck berechnet:
(tu,tv,-,-) = (x,y,z,1) * view * view –1 * mat.
Die Ergänzung des linken Vektors mit „-“ soll andeuten, daß das Ergebnis zwar ein Vek-
tor mit vier Elementen ist. Relevant sind nur die ersten beiden Elemente tu und tv, die
berechneten Texturkoordinaten.
Der folgende Quellcode-Auszug zeigt, wie die Pipeline unter DirectX für die automati-
sche Generierung der Texturkoordinaten aufgesetzt werden muß. p_pd3dDevice ist ein
Pointer auf das Direct3D-Device. Da die Position des Vertex in Texturkoordinaten
Transformiert werden soll, muß für die Texturstufe D3DSS_TCI_CAMERASPACE-
POSITION als TCI (Texture Coodrinate Index) angegeben werden (siehe Zeile 24).
Terrain Engine 100
01 D3DXMATRIX mat, view, iView;

02 float det;
03
04 // Definition der Projektionsmatrix
05 mat._11 = 0.25f; mat._12 = 0.00f; mat._13 = 0.00f; mat._14 = 0.00f;
06 mat._21 = 0.00f; mat._22 =-0.25f; mat._23 = 0.00f; mat._24 = 0.00f;
09
10 // Sichtmatrix auslesen und invertieren
11 g_pd3dDevice->GetTransform( D3DTS_VIEW, &view );
12 D3DXMatrixInverse( &iview, &det, &view );
13
14 // Projektionsmatrix mit der Inversen der Sichtmatrix multiplizieren
15 mat = iview * mat;
16
17 // Transformationsmatrix übergeben
18 g_pd3dDevice->SetTransform( D3DTS_TEXTURE0, &mat );
19
20 // Anpassen der Texturstufe (hier nur Stufe 0)
21 g_pd3dDevice->SetTextureStageState( 0, D3DTSS_TEXTURETRANSFORMFLAGS,
22 D3DTTFF_COUNT2 );
23 g_pd3dDevice->SetTextureStageState( 0, D3DTSS_TEXCOORDINDEX,
24 D3DTSS_TCI_CAMERASPACEPOSITION );
Ohne Berücksichtigung der Kamera-Transformation wird folgende Abbildung berech-

net. Siehe (6.10). Die Transformation ist das Produkt einer Salierung des x- und des y-
Anteils, und der anschließenden Translation um eine halbe Texturbreite.
 0, 25 0 0 0   0, 25x + 0, 5 
   
 x y z 1  ⋅  0 – 0, 25 0 0 
 = 
– 0, 25y + 0, 5  (6.10)
   0 0 1 0  z 
 0, 5 0, 5   

0 1
  1 
Es lassen sich folgende Texturkoordinaten auslesen:

tu = 0,25x + 0,5
tv = – 0,25y + 0,5
Bei dem betrachteten Beispiel wird ein zur xy-Ebene paralleles Quadrat mit den folgen-
den Abmessungen vollständig mit der Textur abgedeckt (siehe Abb. 6.14).
Abbildung 6.14: Zuordnung der Texturkoordinaten auf ein qudratisches Polygon
6.3.7 Wahl der Parameter
Die Daten für die Visualisierung des Terrains entnehme ich der Datei „data\ter-
rain\m513.ter“. Das Höhenfeld hat eine Auflösung von 513x513 Rasterpunkten. Die
Vertikale Skalierung beträgt 0,16 m pro Höheneinheit. Die Rasterweite beträgt 1 m.
Dadurch ergibt sich eine Fläche von 512m x 512m. (Siehe dazu auch Abschnitt 4.3.2 auf
Seite 50.)
Für die Terrainblöcke verwende ich eine Auflösung von 17x17 Vertices. Dadurch wird
das Terrain in 32x32 Terrainblöcke mit jeweils fünf möglichen Detailstufen unterteilt.
Der Quadtree Algorithmus bricht in einer Tiefe von vier ab. Unter Verwendung dieser
Parameter kann das Terrain mit einer Framerate von durchschnittlich 50 Hz dargestellt
werden. Bei einer horizontalen Verdopplung der Vertexdichte (horizontale Skalierung
von 0,5m) fällt die Framerate stark ab. Es werden etwa viermal so viele Dreiecke an die
Graphikkarte geschickt. – Sowohl das Frustum Culling als auch die LOD-Entscheidung
sind distanzabhängig. Die Einheit für die Distanz sind Meter.
6.4 Szenenaufbau
Aufgrund von Datenabhängigkeiten muß für den Szenenaufbau eine gewisse Reihen-
folge eingehalten werden:
1. Überführung des Fahrzeuges in seinen neuen Zustand (Ausführung eines Simulati-

onsschrittes).
2. Aktualisierung der Kamera und der Instrumente. Zur Ausrichtung der Kamera wird
die eben bestimmte Position des Fahrzeuges benötigt (Onboard-Kamera, Ausrichtung
der Kamera auf das Fahrzeug). Die Werte für die Intrumente werden aus dem Zustand
des Modelles entnommen.
3. Selektion des Framebuffers als Rendertarget und Ausgabe der Szene.

Szenenaufbau 102
Die Fahrzeugteile (Chassis, Reifen) werden durch die Anwendung von Translation und
Rotation in die richtige Position gebracht. Welche Transformationsschritte für die Aus-
gabe eines Objektes in welcher Reihenfolge auf die Weltmatrix anzuwenden sind, zeigt
der Szenengraph in Abb. 6.15. Die Daten für Positionierung und Ausrichtung werden
dem physikalischen Modell entnommen. Aufgrund der Verwendung des Z-Buffers ist die
Reihenfolge für die Ausgabe der Szenenelemente unerheblich. Einen Sonderstatus
nimmt die Anzeige der Instrumente ein. Sie darf erst am Ende des Szenenaufbaus erfol-
gen, damit der Überblendungsmechanismus funktioniert.
Abbildung 6.15: Szenengraph
Während die Szenenobjekte die ganze Transformationspipeline [D3DP 98] durchlaufen,

ist die Instrumentenanzeige davon nicht betroffen. Die Ausgabe erfolgt mit Hilfe von
vortransformierten Vertexdaten. Im Szenengraphen ist dies dadurch angedeutet, daß der
Visualisierungsknoten oberhalb der Kameratransformation eingehängt ist.
Kapitel 7
Laufzeitmessungen
Die folgenden Daten stammen aus Laufzeitmessungen des Systems. Sie wurden mit dem
Programm Gnuplot32 [Gnup 99] visualisiert.
Das Gewicht des Fahrzeuges wurde mit 1020 kg angenommen. Die Federkonstanten
betragen k = 65 N/mm für die Radaufhängung und k = 130 N/mm für die Radfederung.
Die Dämpferkonstante beträgt d = 8100 Ns/m. Die Reifen sind ungedämpft. Sie haben
einen Radius von 0,3 m. Die Federwege betragen 0,15 m (Radaufhängung) und 0,04 m
(Reifen).
7.1 Fall aus einem Meter Höhe

Beim Fall des Fahrzeuges aus einem Meter Höhe (gemessen am geometrischen Mittel-
punkt der Karosserie) wurden folgende Messdaten aufgezeichnet:
Abb. 7.1 zeigt den Geschwindigkeitsverlauf des Starrkörpers. Zwischen t = 0 und t = 50

befindet sich der Körper im freien, ungebremsten Fall. Bei etwa t = 50 setzt das Fahr-
zeug am ebenen Boden auf und wird dabei durch die Radaufhängung abgebremst. Nach
einem gedämpften Schwingungsverlauf nähert sich der Starrkörper der Ruhelage.
Abb. 7.2 zeigt die Auflagekräfte in den Bodenkontaktpunkten der Reifen.
Die Abbildungen Abb. 7.3 bis Abb. 7.6 zeigen den Schwingungsverlauf in den vier Rad-
aufhängungen. Da der Schwerpunkt des Fahrzeuges etwas nach hinten versetzt ist, ver-
teilt sich der Großteil der Last auf die Hinterräder.
103
Fall aus einem Meter Höhe 104
Abbildung 7.1: Starrkörpergeschwindigkeit
Abbildung 7.2: Auflagekräfte in den Reifen

105 Laufzeitmessungen
Abbildung 7.3: Radaufhängung vorne links
Abbildung 7.4: Radaufhängung vorne rechts

Fall aus einem Meter Höhe 106
Abbildung 7.5: Radaufhängung hinten links
Abbildung 7.6: Radaufhängung hinten rechts

7.2 Beschleunigung auf der Geraden

Die nachstehenden Diagramme dokumentieren das Beschleunigungsverhalten des Fahr-
zeuges in der Ebene entlang einer Geraden. Die Motorisierung wird durch die Drehmo-
mentkurve in Abb. 7.7 beschrieben. Der Rollwiderstand der Reifen beträgt das 12-fache
der Fahrzeuggeschwindigkeit. Der Luftwiderstand beträgt das 0,45-fache der Fahrzeug-
geschwindigkeit zum Quadrat (siehe Abb. 7.8). Die Höchstgeschwindigkeit wird – auf-
grund der Fahrtwiderstandskräfte – bei etwa 43 m/s erreicht. Als Getriebeübersetzung
wurden die Daten aus Tabelle 3.1 auf Seite 41 verwendet.
Abb. 7.9 zeigt den Geschwindigkeitsverlauf des Fahrzeuges. Kurz nach t = 0 wird der
erste Gang eingelegt. Bei etwa t = 500 der zweite. Das Hochschalten in den fünften Gang
läßt sich bei etwa t = 2300 erkennen. Das Ausbrechen der Motorkennlinie (grün) ist dar-
auf zurückzuführen, daß die Getriebeübersetzung von einem Simulationszeitpunkt auf
den nächsten geändert wird. Durch das Einschleifen der Kupplung wird die Verbindung
zwischen Motor und Antriebsrädern langsam wieder hergestellt. Die Kennlinie von
Motor, Antriebsrädern und Fahrzeuggeschwindigkeit werden zur Deckung gebracht.
Die Zacken zwischen t = 0 und t = 150 sind – so, wie im vorangegangenen Beispiel – auf
das Aufsetzen des Fahrzeuges zurückzuführen.
Das Fahrzeug legt in den 35 sec eine Strecke von gut einem Kilometer zurück.
Abbildung 7.7: Drehmomentkurve

Beschleunigung auf der Geraden 108
Abbildung 7.8: Antriebs- und Widerstandskräfte
Abbildung 7.9: Fahrzeuggeschwindigkeit

Abbildung 7.10: Auflagekräfte
Während des Beschleunigungsvorganges kommt es zu einer dynamischen Verteilung der

Auflagekräfte. Die Kraft in den Auflagepunkten der Reifen erzeugt neben dem Vortrieb
auch ein Drehmoment um den Schwerpunkt des Fahrzeuges. Je stärker die Beschleuni-
gung, desto stärker werden die Hinterräder auf den Boden gepresst. Die Vorderräder wer-
den entlastet.
Bei den Schaltvorgängen setzt die Antriebskraft kurzfristig aus. Dadurch werden die
Hinterräder entlastet. Diese Zeitpunkte lassen sich in Abb. 7.10 gut erkennen. Durch das
Ausfedern der hinteren Radaufhängungen, und durch das vom Rollwiderstand erzeugte
Moment um den Schwerpunkt, haben die Vorderräder kurzfristig eine größere Last als
die Hinterräder zu tragen.
7.3 Kurvenverhalten
Die folgenden Daten wurden bei einer Kurvenfahrt in der Ebene aufgezeichnet. Der sta-
tische Reibkoeffizient der Reifen wurde mit µs = 1, 1 gewählt. Der kinetische Reibko-
effizient ist µk = 0, 9 .
Abb. 7.12 zeigt den Verlauf der Fahrt. Das Fahrzeug wird an der Position (0,y,0) aus
einer Höhe von einem Meter auf ebenes Gelände fallengelassen. Es beschreibt eine
Rechtskurve und anschließend eine Linkskurve. Vor dem Richtungswechsel läßt sich ein
Ausbrechen der Hinterräder erkennen. Die Reifen können den Seitenkräften beim beim
Beschleunigen in der Kurve nicht mehr standhalten. Durch Gegensteuern wird das Aus-
brechen des Fahrzeuges abgefangen. Dabei verringert sich seine Geschwindigkeit und
das Fahrzeug erlangt erneut die Bodenhaftung. Ein weiteres Ausbrechen der Räder ist
Kurvenverhalten 110
am Ende des Kurvenverlaufes zu erkennen, wenn das Fahrzeug bei etwa t = 1300 nach
einem weiteren Beschleunigungsmanöver abgebremst wird (siehe Abb. 7.13).
Abbildung 7.11: Fahrzeug in Kurvenlage (Linkskurve)
Im Kurvenverlauf in Abb. 7.13 lassen sich folgende markante Punkte erkennen: Gleich
beim Aufsetzen am Boden (t = 100) wird der erste Gang eingelegt. Bis das Fahrzeug und
die Reifen die Geschwindigkeit erreicht haben, die durch die Motordrehzahl vorgegeben
wird, vergehen etwa zwei Sekunden. Ab etwa t = 300 folgt der Verlauf der Motorkennli-
nie dem von Fahrzeug und Reifen. Ein weiteres Hochschalten ist bei t = 500 zu erken-
nen. Durch den Geschwindigkeitsverlust beim Kurvenwechsel wird bei t = 950 auf den
ersten Gang heruntergeschaltet. Anschließend folgt eine neuerliche Beschleunigungs-
phase, bis bei t = 1300 in den Leerlauf geschaltet und die Bremse betätigt wird.
Über den gesamten Verlauf des Diagrammes hinweg fällt eine Diskrepanz in den Reifen-
geschwindigkeiten auf. Diese ergibt sich aufgrund der Kurvenlage des Fahrzeuges. Da
die Reifen unterschiedlich große Wendekreisdurchmesser besitzen, müssen sie in der
Kurve auch unterschiedlich große Strecken zurücklegen. Bei etwa t = 900 ist ein Rich-
tungswechsel erkennbar. Die Kurven überschneiden sich. Während vorher der linke Vor-
derreifen die größte Geschwindigkeit aufweisen konnte, so ist es nach dem Richtungs-
wechsel der rechte Vorderreifen (in Abb. 7.12 läßt sich erkennen, daß dieser den
kleinsten Wendekreisradius besitzt). Erst durch den Bremsvorgang gleichen sich die
Geschwindigkeiten der Räder an einen Wert an.
Abbildung 7.12: Fahrspur
Abbildung 7.13: Geschwindigkeitsmessung

Kurvenverhalten 112
Federungsverhalten
Durch die longitudinale und durch die laterale Beschleunigung des Fahrzeuges kommt es
zu unterschiedlichen Kräfteverteilungen in den Bodenkontaktpunkten der Reifen (siehe
Abb. 7.14). In direktem Zusammenhang mit den Auflagekräften in den Reifen stehen die
Auslenkungen der Radaufhängungen. Abb. 7.15 bis Abb. 7.18 zeigen das Einfedern der
einzelnen Radaufhängungen.
Abbildung 7.14: Auflagekräfte in den Reifen


Kurvenverhalten 114

7.4 Freie Fahrt im Gelände

Für die Fahrt im Gelände wurden die Federkonstanten in der Lagerung des Starrkörpers
etwas hinaufgesetzt. Die Federkonstante in der Radaufhängung beträgt 80 N/mm, die Im
Reifen 210 N/mm. Der Dämpfer wurde mit 8950 Ns/m proportioniert.
Abb. 7.19 gibt die Position des Fahrzeuges wieder. Das Fahrzeug wurde an der Position
(0,y,0) aus einer Höhe von etwa 0,5 Meter auf abschüssiges Gelände fallengelassen.
Abbildung 7.19: Fahrspur
Während dem Fahrverlauf wurden folgende Geschwindigkeiten aufgezeichnet (siehe

Abb. 7.21). Am Beginn der Kurve ist ein linearer Anstieg der Geschwindigkeit zu erken-
nen. Aufgrund der Gravitation wird das Fahrzeug gleichmäßig nach unten beschleunigt.
Haben die Reifen den Bodenkontakt erlangt, geht die Bewegung des Fahrzeuges in eine
Rollbewegung über. Das Fahrzeug rollt den Hang nach unten. Gleichzeitig findet eine
Angleichung der Reifendrehzahlen an die Geschwindigkeit des Starrkörpers statt. Diese
Angleichung ist etwa zwischen t = 100 und t = 200 zu erkennen.
Zu diesem Zeitpunkt wurde bereits der erste Gang eingelegt. Bei t = 900 wird in den
zweiten Gang hochgeschaltet. Bei t = 2000 wird der Leerlauf eingelegt und ein Brems-
vorgang eingeleitet.
Freie Fahrt im Gelände 116
Abbildung 7.20: Fahrzeug im Gelände (erste Rechtskurve)
Abbildung 7.21: Geschwindigkeitsmessung
Während der Fahrt kommt es immer wieder zum Ausbrechen der Antriebsreifen. Das ist
darauf zurückzuführen, daß die Antriebsräder manchmal stärker, und manchmal weniger
stark belastet werden. Durch die Unebenheiten im Gelände variiert die Radlast der Rei-
fen relativ stark. Die Räder können den Bodenkontakt verlieren.
Die anderen Abweichungen der Reifendrehzahlen sind durch die Kurvenlage des Fahr-
zeuges bedingt.
Bleibt die Geschwindigkeit eines nicht angetriebenen Reifens über einen kurzen Zeit-
raum hinweg konstant, darf davon ausgegangen werden, daß der Reifen den Bodenkon-
takt verloren hat. Durch seinen Drehimpuls wird die Geschwindigkeit aufrechterhalten.
Abb. 7.22 zeigt die Auflagekräfte in den Reifen. Sie variieren relativ stark.
Abbildung 7.22: Auflagekräfte
Federungsverhalten
Die nachfolgenden Diagramme zeigen den Federungsverlauf eines jeden der vier Räder.


Anhang A
Quaternions
In diesem Abschnitt versuche ich, einen groben Überblick über Quaternions zu geben.
Es werden sowohl Aufbau, als auch Rechenoperationen behandelt. Die Ausführungen
basieren auf [PeWe 82], [TMQF 97] und [Sobe 00]. Für die Implementierung der Starr-
körperdynamik wird die in Abschnitt A.1.2 besprochene Multiplikation benötigt. Außer-
dem werden die Umrechnungen aus Abschnitt A.2.1 und Abschnitt A.2.2 verwendet.
Quaternions sind eine Erweiterung der Komplexen Zahlen. Anstatt eines einzigen Imagi-
näranteils i bestitzen Quaternions drei imaginäre Anteile i, j und k, sodaß
i ⋅ i = –1
j ⋅ j = –1
k ⋅ k = –1
Ein Quaternion hat folgende Darstellungsform:
q = r + xi + yj + zk
r ist eine reelle Zahl. x, y und z sind komplexe Zahlen.

Faßt man x, y und z in einen Vektor v zusammen, erhält man folgende, ebenfalls gängige
Darstellungsform für Quaternions:
q = [ r, v ]
121
Rechenoperationen 122
Der Anteil v = ( x, y, z ) wird als Vektor bezeichnet, r als Skalar. Man darf sich v aller-
dings nicht als typischen 3-dimensionalen Vektor vorstellen. Es ist ein Vektor im 4-
dimensionalen Raum.
Die Länge eines Quaternions ist definiert als q = sqrt ( r 2 + x 2 + y 2 + z 2 ) .
Das konjungierte Quaterionin q’ ist gleich r – xi – yj – zk.
–1
Außerdem gilt folgender Zusammenhang: q = 1 ⇒ q = q′
Das Eins-Element bezüglich der Multiplikation ist [1,(0, 0, 0)], das Null-Element
bezüglich der Addition ist [0,(0, 0, 0)].
A.1 Rechenoperationen
A.1.1 Addition und Subtraktion

Zwei Quaternions werden addiert, indem man ihre Komponenten addiert. Und sie wer-
den subtrahiert, indem man ihre Komponenten subtrahiert.
q = (r,x,y,z) = r + xi + yj + zk,
p = (s,a,b,c) = s + ai + bj + ck,
q+p = (r+s, x+a, y+b, z+c),

q-p = (r-s, x-a, y-b, z-c).
A.1.2 Multiplikation
Die Multiplikation zweier Quaternions entspricht der Multiplikation zweier Polygone:
q = (r,x,y,z),
p = (s,a,b,c),
qp = (r+xi+yj+zk)(s+ai+bj+ck)
= ...
= ( rs-xa-yb-zc,
ra+xs+yc-zb,
rb-xc+ys+za,
rc+xb-ya+zs )
In der zweiten Darstellungsform läßt sich die Multiplikation zweier Quaternions folgen-
dermaßen anschreiben:
123 Quaternions
[ r 1, v 1 ] [ r 2, v 2 ] = [ r 1 r 2 – v 1 ⋅ v 2, r 1 v 2 + r 2 v 1 + v 1 × v 2 ]
Achtung: Die Multiplikation von Quaternions ist assoziativ, nicht aber kommutativ!
A.2 Umrechnungen
A.2.1 Rotationsmatrix in Quaternion

Eine Rotationsmatrix kann mit Hilfe des folgenden Algorithmus in ein Quaternion
umgerechnet werden:
1. Berechne die Spur der Matrix M:
S = 4 - 4x² - 4y² - 4z²

= 4( 1 - x² - y² - z² )
= mat[0] + mat[5] + mat[10] + 1
2. Ist die Spur größer Null, so ist das Quaternion durch folgende Gleichungen bestimmt:
u = 0.5 / sqrt(S);
r = 0.25 / u;
x = ( mat[9] - mat[6] ) * u;
y = ( mat[2] - mat[8] ) * u;
z = ( mat[4] - mat[1] ) * u;
Andernfalls ( S ≤ 0 ) bestimme das größte Element der Hauptdiagonale. In Abhängig-

keit von diesem Wert, berechnet sich das Quaternion wie folgt:
// 1. Element der Hauptdiagonale am größten:

u = sqrt( 1.0 + mat[0] - mat[5] - mat[10] ) * 2;
x = 0.5 / u;
y = (mat[1] + mat[4] ) / u;
z = (mat[2] + mat[8] ) / u;
r = (mat[6] + mat[9] ) / u;

u = sqrt( 1.0 + mat[5] - mat[0] - mat[10] ) * 2;
x = (mat[1] + mat[4] ) / u;
y = 0.5 / u;
z = (mat[6] + mat[9] ) / u;
r = (mat[2] + mat[8] ) / u;

u = sqrt( 1.0 + mat[10] - mat[0] - mat[5] ) * 2;
x = (mat[2] + mat[8] ) / u;
Umrechnungen 124
y = (mat[6] + mat[9] ) / u;
z = 0.5 / u;
r = (mat[1] + mat[4] ) / u;
A.2.2 Quaternion in Rotationsmatrix

Die Umrechnung eines Quaternions in eine Rotationsmatrix wird wie folgt durchgeführt:
r2 + x2 – y2 – z2 2xy – 2rz 2xz + 2ry

M = 2xy + 2rz r 2 – x2 + y 2 – z2 2yz – 2rx
2xz – 2ry 2yz + 2rx r2 – x2 – y2 + z2
Verwendet man ein Quaternion der Länge 1 verkürzt sich der Ausdruck auf:
1 – 2y 2 – 2z 2 2xy – 2rz 2xz + 2ry

M = 2xy + 2rz 1 – 2x 2 – 2z 2 2yz – 2rx
2xz – 2ry 2yz + 2rx 1 – 2x 2 – 2y 2
A.2.3 Rotationsachse und -winkel in Quaternion

Bei gebener Rotationsachse axis und gegebenem Rotationswinkel angle wird das Qua-
ternion nach folgender Fomel berechnet:
sin_a = sin( angle / 2 )

cos_a = cos( angle / 2 )
x = axis.x / sin_a
y = axis.y / sin_a
z = axis.z / sin_a
r = cos_a
A.2.4 Quaternion in Rotationsachse und -winkel

Die Umrechnung des Quaternions in Rotationsachse und -winkel sieht wie folgt aus:
cos_angle = r;
angle = acos( cos_angle );
sin_angle = sqrt( 1.0 - cos_angle * cos_angle );

if ( fabs( sin_angle ) < 0.0005 )
sa = 1;
125 Quaternions
axis.x = x / sa;
axis.y = y / sa;
axis.z = z / sa;
Umrechnungen 126
Anhang B
Frustum Culling
Die folgenden Codeauszüge sind im wesentlichen dem Paper von Mark Morley
[Morl 00] entnommen. Morley verwendet jedoch für seine Beispielcodes die Graphik-
Schnittstelle OpenGL. Die Berechnung der Clipping Planes mußte auf DirectX ange-
passt werden.
01 void extractFrustum()
02 {
03 double t;
04
05 // Get the current PROJECTION matrix
06 D3DXMATRIX proj;
07 g_pd3dDevice->GetTransform( D3DTS_PROJECTION, &proj );
08
09 // Get the current MODELVIEW matrix
10 D3DXMATRIX view;
11 g_pd3dDevice->GetTransform( D3DTS_VIEW, &view );
12
13 // Combine the two matrices (multiply projection by modelview)
14 D3DXMATRIX clip = view * proj;
15
16 // Extract the RIGHT plane ---------------------------
17 frustum[0][0] = clip._14 - clip._11;
21 t = sqrt( frustum[0][0] * frustum[0][0] +
22 frustum[0][1] * frustum[0][1] +
23 frustum[0][2] * frustum[0][2] );
24 frustum[0][0] /= t;
25 frustum[0][1] /= t;
26 frustum[0][2] /= t;
27 frustum[0][3] /= t; // ...Normalize the result
28
127
128
29 // Extract the LEFT plane ----------------------------

30 frustum[1][0] = clip._14 + clip._11;
37 frustum[1][0] /= t;
38 frustum[1][1] /= t;
39 frustum[1][2] /= t;
41
42 // Extract the BOTTOM plane --------------------------
50 frustum[2][0] /= t;
51 frustum[2][1] /= t;
52 frustum[2][2] /= t;
54
55 // Extract the TOP plane -----------------------------
63 frustum[3][0] /= t;
64 frustum[3][1] /= t;
65 frustum[3][2] /= t;
67
68 // Extract the FAR plane ----------------------------
76 frustum[4][0] /= t;
77 frustum[4][1] /= t;
78 frustum[4][2] /= t;
80
81 // Extract the NEAR plane -----------------------------
89 frustum[5][0] /= t;
129 Frustum Culling
90 frustum[5][1] /= t;
91 frustum[5][2] /= t;
93 }
Zur Entscheidungsfindung, ob ein Würfel mit Mittelpunkt (x, y, z) und Größe size zur
Gänze oder teilweise innerhalb des Frustums liegt, kann folgende Funktion verwendet
werden:
01 bool cubeInFrustum( float x, float y, float z, float size )

02 {
03 int p;
04 for( p = 0; p < 6; p++ )
05 {
06 if( frustum[p][0] * (x - size) + frustum[p][1] * (y - size) +
07 frustum[p][2] * (z - size) + frustum[p][3] > 0 )
08 continue;
09
10 if( frustum[p][0] * (x + size) + frustum[p][1] * (y - size) +
12 continue;
13
14 if( frustum[p][0] * (x - size) + frustum[p][1] * (y + size) +
16 continue;
17
18 if( frustum[p][0] * (x + size) + frustum[p][1] * (y + size) +
20 continue;
21
22 if( frustum[p][0] * (x - size) + frustum[p][1] * (y - size) +
23 frustum[p][2] * (z + size) + frustum[p][3] > 0 )
24 continue;
25
26 if( frustum[p][0] * (x + size) + frustum[p][1] * (y - size) +
28 continue;
29
30 if( frustum[p][0] * (x - size) + frustum[p][1] * (y + size) +
32 continue;
33
34 if( frustum[p][0] * (x + size) + frustum[p][1] * (y + size) +
36 continue;
37
38 return false;
39 }
40 return true;
41 }
Zu beachten ist, daß das Ergebnis von cubeInFrustum() in gewissen Spezialfällen falsch
sein kann. Das ist genau dann der Fall, wenn die getesteten Punkte zwar innerhalb der
jeweiligen Ebenen liegen, der Wüfrel aber dennoch keinen Schnittkörper mit dem
Frustum aufweist (siehe dazu Abb. B.1). Diese Fehler können allerdings vernachlässigt
werden, da sie nur sehr selten auftreten. Außerdem wird die Sichtbarkeitsentscheidung
130
hierarchisch auf immer kleinere Ausschnitte der Landschaft ausgeführt, wodurch eine
Fehlinterpretation auf der nächst-tieferene Ebene in den meisten Fällen wieder kompen-
siert wird. Im schlimmsten Fall werden ein paar überflüssige Dreiecke an die Render-
Pipeline geschickt. Das stört aber nicht weiter, da sich daraus kein merklicher Einfluß
auf die Ausgabegeschwindigkeit ergibt. Um einen merklichen Einbruch in der Framerate
zu erhalten, müßten sich in der fälschlicherweise akzeptierten Region vergleichsweise
viele Polygone befinden. Aufgrund der Anordnung der Geländedaten darf man davon
aber nicht ausgehen. Die Berücksichtigung der eben angesprochenen Spezialfälle würde
im Vergleich mehr an Rechenzeit kosten, als jemals durch eine Fehlentscheidung in der
Bestimmung der Ausgabemenge entstehen könnte.
Abbildung B.1: Mögliche Fehlentscheidung beim Frustum Culling

Anhang C
DirectX Render-Framework
Für das Verständnis der Abarbeitungsreihenfolge ist es wichtig, sich mit dem von Win-
dows verwendeten Nachrichtenkonzept vertraut zu machen. Inwieweit die Graphikaus-
gabe in dieses Konzept eingebunden werden kann, wird im Anschluß daran behandelt.
C.1 Das Nachrichtenkonzept unter Windows

Wenn der Benutzer über Maus oder Tastatur mit einem Windows Programm interagiert,
so geschieht dies über Nachrichten (Messages): Bei jedem Systemereignis (z.B. Maus-
klick auf das Fenster) wird vom Betriebssystem eine Nachricht erstellt und in der Nach-
richten-Queue des betroffenen Fensters abgelegt. Um darauf reagieren zu können, müs-
sen die Nachrichten aus der Queue ausgelesen werden. Dies geschieht in der Hauptnach-
richtenschleife
C.1.1 Hauptnachrichtenschleife (Windows Message Loop)

Das folgende Codestück zeigt eine Implementierung des Windows Message Loops. Sie
bildet den Kern der Win32 Anwendung und wird solange durchlaufen, solange GetMes-
sage keine WM_QUIT Message aus der Queue des Programm-Threads ausliest.
01 MSG msg; // Datenstruktur für Nachricht

02
03 while( GetMessage( &msg, NULL, 0, 0 ) )
04 {
05 TranslateMessage( &msg );
06 DispatchMessage( &msg );
07 }
131
Das Nachrichtenkonzept unter Windows 132
Innerhalb der Schleife werden die Anweisungen TranslateMessage und DispatchMes-

sage ausgeführt. Den beiden Prozeduren haben folgende Verwendung:
• TranslateMessage sendet die Nachricht an Windows zurück. Dort wird sie übersetzt1
und erneut an die Nachrichten-Queue des Fensters übergeben.
• DispatchMessage sendet die Nachricht abermals an das Betriebssystem. Von dort

wird sie an die passende Windows-Prozedur für Nachrichtenverarbeitung weitergelei-
tet. Diese Prozedur muß beim Registrieren der Fensterklasse angegeben werden und
trägt üblicherweise den Namen WndProc (siehe Abschnitt C.1.2). Der Methodenauruf
von WndProc wird innerhalb von DispatchMessage durchgeführt.
C.1.2 Nachrichtenverarbeitung des Hauptfensters
Innerhalb des Hauptfensters kann über eine Windows-Prozedur auf bestimmte Ereig-
nisse reagiert werden. Die Ereignisse werden vom System in Form von Nachrichten in
die Message-Queue des betroffenen Fensters gestellt und beim Aufruf von DispatchMes-
sage an die Prozedur weitergeleitet, die beim Registrieren der Fensterklasse angegeben
wurde. Der folgende Codeausschnitt zeigt eine auf das Wesentlichste beschränkte Win-
dows-Prozedur (normalerweise werden hier mehrere Ereignisse abgefangen).
01 LRESULT WINAPI WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
02 {
03 switch( msg )
04 {
05 case WM_DESTROY:
06 PostQuitMessage(0);
07 return 0L;
08 default:
09 return DefWindowProc( hWnd, msg, wParam, lParam );
10 }
11 return 0;
12 }
• PostQuitMessage in Zeile 06 signalisiert dem System, daß der Thread zu terminieren

beabsichtigt. Dazu sendet sie eine WM_QUIT Nachricht an die Message-Queue des
Threads. PostQuitMessage wird typischerweise als Antwort auf eine
WM_DESTROY Nachricht eingesetzt.
• DefWindowProc in Zeile 09 ruft die Standard Windows-Prozedur eines Fensters auf.

Sie bearbeitet alle Nachrichten, die von Applikation nicht behandelt wurden. Sie wird
mit der selben Parameterliste wie die Windows-Prozedur aufgerufen.
1. Hierbei handelt es sich im wesentlichen um die Übersetzung von virtuellen Tastencodes in

länderspezifische Zeichen. Näheres dazu kann [Petz 98] entnommen werden.
133 DirectX Render-Framework
C.2 Einbindung der Graphikausgabe

Auf Basis der vorliegenden Implementierung kann im Hauptprogramm mit nur wenigen
Befehlen ein Fenster für die Direct3D Ausgabe bereitgestellt werden (siehe nachfolgen-
der Quellcode). Die Aufgaben der Hauptnachrichtenschleife werden in Zeile 04 durch
den Befehl readInput übernommen. Das Programm bricht beim Drücken der Escape-
Taste ab.
01 gfx_engine.init( hInstance, "Fenstertitel", 1024,768, false );

02 // weitere Einstellungen für das Ausgabefenster (optional)
03
04 while( gfx_engine.readInput() && !gfx_engine.keyPressed( VK_ESCAPE ))
05 {
06 gfx_engine.beginRendering();
07 // Graphikausgabe über D3D-Device
08 gfx_engine.swapBuffers( true );
09 }
C.2.1 Nachrichten
Die Methode readInput übernimmt die Funktionalität der Hauptnachrichtenschleife. Sie
fragt anliegende Nachrichten ab und übernimmt deren Abarbeitung:
01 bool GFX_Engine::readInput()
02 {
03 MSG msg;
04 if ( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
05 {
06 if ( msg.message == WM_QUIT )
07 return false;
08 else
09 {
10 TranslateMessage( &msg );
11 DispatchMessage( &msg );
12 }
13 }
14 return true;
15 }
C.2.2 Graphikausgabe
Die Graphikausgabe wird durch den Befehl beginRendering eingeleitet und durch den
Befehl swapBuffers abgeschlossen. swapBuffers präsentiert gerenderte Graphik im Aus-
gabebereich des Applikationsfensters.
beginRendering
In beginRendering wird zuerst der Status des Fensters geprüft: Die Graphikausgabe
braucht nur erfolgen, soferne das Fenster nicht
Einbindung der Graphikausgabe 134
• minimiert
• durch ein maximiertes Fenster verdeckt
• inaktiv (ohne Fokus)
ist. Andernfalls wird die Methode verlassen.

Falls keine der obigen Bedingungen zutrifft, wird Position und Orientierung der referen-
zierten Kamera in die View-Matrix übertragen. Die Welt-Matrix wird zurückgesetzt.
Und das Direct3D Ausgabefenster wird vorbereitet:
01 void GFX_Engine::beginRendering()
02 {
03 if( !s.bActive ) return;
04 if( camera ) camera->update();
05 D3DXMatrixIdentity( &matWorld );
06 g_pd3dDevice->Clear( 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER,
07 cSky, 1.0f, 0 );
08 g_pd3dDevice->BeginScene();
09 }
swapBuffers
Im Anschluß befindet Sie der Code der Methode swapBuffers (in gekürzter Fassung).
Die Methodenaufrufe in Zeile 06 ud 08 werden zwingend durch DirectX vorgegeben.
01 void GFX_Engine::swapBuffers( bool printFPS )

02 {
03 /* Ausgabe der Frames per Second (fps)
04 ...
05 */
06 g_pd3dDevice->EndScene();
07 if( s.bActive )
08 g_pd3dDevice->Present( NULL, NULL, NULL, NULL );
09 }
Anhang D
Blit Funktion
Unter Blitting versteht man das Kopieren von Bilddaten aus einem Speicherbereich in
einen anderen (bit block transfer). Üblicherweise werden damit zweidimensionale Bild-
daten direkt in den Framebuffer geschrieben. Dabei müssen Pixelformate, Clipping und
Scanline-Stufen berücksichtigt werden. Das Win32 GDI (Graphics Device Interface)
stellt einen Befehl zur Verfügung, der dies über den Treiber der Graphikkarte als direkten
Zugriff auf den Bildschirmspeicher realisiert. Der Befehl heißt BitBlt. In Kombination
mit der Verwendung eines Direct3D-Devices ist die Verwendung dieses Befehles aller-
dings nicht zu empfehlen. Den gleichen Effekt erzielt man unter DirectX durch die Aus-
gabe von zwei vortransformierten Polygonen innerhalb der Bildebene. Ein großer Vorteil
dieser Methode liegt darin, daß die Bilddaten nicht nur in rechteckige Bereiche des Bild-
schrimes eingebelendet werden können, deren Kanten parallel zum Rand des Monitors
verlaufen. Als Zielregion können Polygone in allgemeiner Lage verwendet werden.
Mit Hilfe dieser Technik sollen die Instrumente (Speedometer, Tachometer, Gangan-
zeige) in den Bildschirm eingeblendet werden. Um die Angabe der Eckpunkte in Bild-
schirmkoordinaten durchführen zu können, muß DirectX mitgeteilt werden, daß die Ver-
tices bereits vortransformiert sind. (Sie brauchen die Transformationspipeline nicht mehr
zu durchlaufen.) Dies erreicht man mit Hilfe des flexiblen Vertexformates. Durch Setzen
des D3DFVF_XYZRHW-Flags in der Strukturdefinition der Daten wird die Anwendung
der Vertextransformation (und die Belechuchtungsberechnung) außer Kraft gesetzt.
Die folgenden Code-Segmente sind aus [Dunl 01] entnommen. Für die Verwendung in
der Graphik Engine wurden ein paar minimale Veränderungen durchgeführt.
01 #define D3DFVF_TLVERTEX D3DFVF_XYZRHW|D3DFVF_DIFFUSE|D3DFVF_TEX1

02
03 typedef struct _D3DTLVERTEX
04 {
05 float sx;
135
136
06 float sy;
07 float sz;
08 float rhw;
09 D3DCOLOR color;
10 float tu;
11 float tv;
12 _D3DTLVERTEX() { }
13 _D3DTLVERTEX( const D3DVECTOR &v, float _rhw,
14 D3DCOLOR _color,
15 float _tu, float _tv )
16 { sx = v.x; sy = v.y; sz = v.z; rhw = _rhw;
17 color = _color;
18 tu = _tu; tv = _tv;
19 }
20 } D3DTLVERTEX;
sx und sy sind die Bildschirmkoordinaten der Eck-Vertices. sz wird in einem Bereich von
0,0 (nahe) bis 1,0 (ferne) übergeben. Der Wert gibt die Tiefe des Rechtecks an und kann
verwendet werden, um mehrere Darstellungsebenen zu realisieren.
Die folgende Funktion wird zum Einblenden eines rechteckigen Bildes in Normallage
verwendet. g_pd3dDevice ist ein Pointer auf das Direct3D Device. lpScr zeigt auf eine
zuvor geladene Textur. Der Wert rhw ermittelt sich aus der Distanz der Near-Clipping-
Plane und der Far-Clipping-Plane des Viewing Frustums.
01 void GFX_Engine::blitRect( LPDIRECT3DTEXTURE8 lpSrc,

02 float left, float top,
03 float right, float bottom,
04 D3DCOLOR col, float z )
05 {
06 // reciprocal of homogeneous w
07 float rhw = 1.0f / ( z * frust.zFar + frust.zNear );
08
09 D3DTLVERTEX verts[4];
10 verts[0] = D3DTLVERTEX( vec3( left, top, z ), rhw, col, 0.0f,0.0f );
11 verts[1] = D3DTLVERTEX( vec3( right, top, z ), rhw, col, 1.0f,0.0f );
12 verts[2] = D3DTLVERTEX( vec3( right, bottom, z ), rhw, col, 1.0f,1.0f );
13 verts[3] = D3DTLVERTEX( vec3( left, bottom, z ), rhw, col, 0.0f,1.0f );
14
15 g_pd3dDevice->SetTexture( 0, lpSrc );
16
17 g_pd3dDevice->SetVertexShader( D3DFVF_TLVERTEX );
18
19 g_pd3dDevice->DrawPrimitiveUP(
20 D3DPT_TRIANGLEFAN, 2, verts, sizeof( D3DTLVERTEX ) );
21 }
Für die Anwendung der Funktion muß die Beleuchtung ausgeschaltet sein (Renderstate
D3DRS_LIGHTING auf FALSE setzen). Transparente Stellen in der Ausgabe erzielt man
durch die Verwendung einer Alphamap.
137 Blit Funktion
Abbildung D.1: Darstellung eines rechteckigen Bildes mit Hilfe der Blit-Funktion
138
Anhang E
Das Terrain Dateiformat
Der Header des Terrain Dateiformates ist die folgt spezifiziert:
Datei:
terrain/header.h
01 #ifndef __TER_HEADER
02 #define __TER_HEADER
04
05 #define NTEX 15 // maximale Anzahl an Texturen
06 // (bzw. Geotypen)
07
08 typedef struct
09 {
10 WORD size; // Breite der Map (2^n+1)
11 float rasterScale; // Rasterbreite (in m)
12 float heightScale; // Höhenraster (in m)
13
14 BYTE texUsed; // Anzahl verwendete Texturen
15 CHAR texFile[32][NTEX]; // Textur-Referenzen
16 float texScale[NTEX]; // Textur-Skalierung (1 Kachel auf
17 // wieviele Meter Seitenlänge?)
18 float Yofset[NTEX]; // relative 0-Höhe
19
20 float friction[NTEX]; // Reibwert
21 float rollResist[NTEX]; // Rollwiderstandswert
23
24 } TER_Header;
25
26 #endif
Im Anschluß an den Header folgen die Höhendaten und die Geotyp-Daten in einem
jeweils size*size großem Feld. Die Messpunkte liegen im BYTE-Format vor.
139
140
Anhang F
Tastaturbelegung
Steuerung des Fahrzeuges:

OBEN ........... Gas geben
UNTEN......... bremsen
LINKS .......... links lenken
RECHTS....... rechts lenken
A ................... Gang hochschalten
Y ................... Gang herunterschalten
SPACE .......... Fahrzeug an Startposition zurücksetzen
Wahl der Kamera-Ansicht:

1 .................... fixe Position, fixe Orientierung
2 .................... fixe Position, Sicht auf das Fahrzeug
3 .................... Kameraverfolgung (nahe)
4 .................... Kameraverfolgung (weit)
5 .................... Cockpitansicht
6 .................... Motorhaube
7 .................... Stoßstange
8 .................... Reifen-Kamera
9 .................... Draufsicht (starr)
0 .................... Draufsicht (rotierend)
Darstellung der Gelände-Triangulierung

T.................... Umschalten zwischen gefüllter Darstellung, Drahtgitterdarstellung und
Überblendung der beiden Darstellungsformen.
141
142
Sonstige
F1 .................. Inhalt des Bildschirmes in eine Datei schreiben
(die Dateien werden in dem Verzeichnis capture\screenshots\ abgelegt)
143
Literaturverzeichnis
[Arce 02] Tomas Arce: Zen-X engine. Internet, http://www.zen-x.net, 2002.
[BWAK 99] David Baraff, Witkin, Andrew and Kass: Physically Based Modelling.
SIGGRAPH Course Notes, 1999.
[Beck 01] Brian Beckman: The Physics of Racing Series. Internet, http://
www.esbconsult.com.au/ogden/locost/phors/phors.html, 2001.
[BeHa 78] Norman H. Beachley, Howard L. Harrison: Introduction to Dynamic

System Analysis. Addison Wesley Longman, Inc. 01/1978.
[Bloo 00] Charles Bloom: Terrain Texture Compositing by Blending in the

Framebuffer. Internet, http://cbloom.com/3d/techdocs/splatting.txt, 2000.
[Boer 00] William H. de Boer: Fast Terrain Rendering Using Geometrical

MipMapping.
Internet, http://www.flipcode.com/tutorials/tut_geomipmaps.shtml, 2000.
[Bosc 97] Robert Bosch: Automotive Handbook. Robert Bosch GmbH, 4th ed.,
1997.
[Bour 99] Paul Bourke: Direct-X File Format. Internet,

http://astronomy.swin.edu.au/~pbourke/geomformats/directx/, 1999
[Clar 76] J. H. Clark: Hierarchical Geometric Models for Visible Surface

Algorithms. J. H. Clark – Communications of the ACM (19), pp. 547-554,
1976.
[D3DP 98] Microsoft Corporation: The Direct3D Transformation Pipeline.

White Paper, MSDN Library/Graphics and Multimedia/Directx/Technical
Articles, April 1998.
[D3DX 02] Philip Taylor: Exploring D3DX. MSDN Library/Graphics and Multi-
media/DirectX/Columns/Driving DirectX, 2002.
[DIN50323] DIN 50323: Teil 3: Tribologie, Reibung. Beuth Verlag GmbH, Berlin
1998.
[Dubb 90] W. Beitz, K.-H. Küttner: Dubbel – Taschenbuch für den Maschinenbau.
17., neubearbeitete Auflage. Springer Verlag, Berlin, 1990.
[Dunl 01] Robert Dunlop: A Simple Blit Function for Direct3D. Internet, http://
www.mvps.org/directx/articles/blit3d.htm, 2001.
144
[DWSM 97] Mark Duchaineau, Murray Wolinsky, David E. Sigeti, Mark C. Miller,
Charles Aldrich, Mark B. Mineev-Weinstein: ROAMing Terrain: Real-
time Optimally Adapting Meshes. Los Alamos National Laboratory,
Lawrence Livermore National Laboratory, 1997.
[DX8 00] Philip Taylor: Introduction to DirectX 8.0. MSDN Library/Graphics and
Multimedia/DirectX/Columns/Driving DirectX, 2000.
[Efun 02] Engineering Fundamentals: Damped Vibration of Free SDOF Systems.

Internet,
http://www.efunda.com/formulae/vibrations/sdof_free_damped.cfm,
2002
[Gent 97] Giancarlo Genta: Motor Vehicle Dynamics. World Scientific, Singapore,
1997.
[Gnup 99] Gnuplot Central. Internet, http://www.gnuplot.info/, 1999.
[Gold 99] Peter Goldkuhle: Einsatz des Rechners im Physikunterricht zur

Modellbildung und Simulation. Unterlagen zur Vorlesung Modellbildung
und Simulation, Universität Paderborn, 1999.
[LCRH 96] Peter Lindstrom, David Coller, William Ribarsky, Larry F. Hodges, Nick
Faust, Gregory A. Thurner: Real-Time, Continous Level of Detail
Rendering of Height Fields. In Proceedings of ACM SIGGRAPH 96,
August 1996, pp. 109-118.
[Low 00] Colin Low, Games and Physics: Design Issues. Hewlett Packard
Laboratories, Technical Report, 2000.
[Mits 02] Mitsubishi Motors: Lancer Evolution VII GT-A. Press Information,
January 2002.
[Mons 01] Marco Monster: Car Physics for Games. Internet, http://home.planet.nl/
~monstrous/tutcar.html, 2001.
[Morl 00] Mark Morley: Frustum Culling in OpenGL. Internet,

http://www.markmorley.com/opengl/frustumculling.html, 2000.
[OpGL 98] Silicon Graphics: OpenGL - The Industry's Foundation for High
Performance Graphics. Internet, www.opengl.org, 1998.
[Petz 98] Charles Petzold: Programming Windows. Microsoft Press, 1998.
[PeWe 82] Edward Pervin, Jon A. Webb: Quaternions in Computer Vision and
Robotics. Technical Report, Carnegie Mellon University, School of
Computer Science, cmu-cs-82-150, 1982.
145
[RHSS 97] Stefan Röttger, Wolfgang Heidrich, Philipp Slusallek, Hans-Peter Seidel:
Real-Time Generation of Continuous Levels of Detail Height Fields.
Technical Report, Universität Erlangen-Nürnberg, 13/1997.
[Rill 01] Prof. Dr.-Ing. G. Rill: Fahrzeugdynamik. Skriptum, Fachhochschule

Regensburg, 2001.
[SaHa 95] Michael W. Sayers and Dongsuk Han: A Generic Multibody Vehicle
Model for Simulating Handling and Braking. Presented at the 1995
Symposium of the International Association of Vehicle System
Dynamics, Ann Arbor, USA. To appear in a special edition of the Journal
Vehicle System Dynamics, 1996.
[Sobe 00] Sobeit Void: Quaternion Powers. Internet, http://www.gamedev.net/

reference/articles/article1095.asp, 2000.
[StSG 88] Steger, Sieghart, Glauninger: Technische Mechanik 2: Festigkeitslehre,

Kinematik, Kinetik, Hydromechanik. B. G. Teubner Stuttgart, 1988.
[TMQF 97] The Matrix and Quaternions FAQ. Internet, http://skal.planet-d.net/demo/

matrixfaq.htm, 1997.
[UML 99] Cris Cobryn: UML 2001 - A Standardization Odyssey. Communications

of the ACM, vol. 42, no. 10, October, 1999.
[VTP 01] Virtual Terrain Project: Detail Textures. Internet, http://www.vterrain.org/

Textures/detail.html, 2001.
[Witk 99] Andrew Witkin: Constrained Dynamics. SIGGRAPH Course Notes,

1999.
[Zuvi 00] Ted Zuvich: Vehicle Dynamics for Racing Games. Game Developers
Conference Proceedings, 2000.

Ackerman Geometrisi Diplomarbeit

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ackerman Geometrisi Diplomarbeit

Hochgeladen von

Copyright:

Verfügbare Formate

J O HA NN E S K E P L E R

Ein 3-dimensionales Modell zur Simulation von

o. Univ.-Prof. Dr. Jens Volkert

Linz, September 2002

Johannes Kepler Universität

Die physikalische Modellierung beweglicher Objekte spielt in vielen Anwendungsgebie-

Geboren am 12.10.1976 in Ried i. I.

1995: Abschluß des Bundesrealgymnasiums Ried

1995-1997: Colleg für Graphik Design (Kommunikationsdesign) in Linz

Linz, Oktober 2002 Gsöllpointner Stephan

4 Visualisierung des Terrains 47

6.4 Szenenaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B Frustum Culling 125

C DirectX Render-Framework 129

D Blit Funktion 133

E Das Terrain Dateiformat 137

1.1 Bezugskoordinatensysteme des Fahrzeuges. . . . . . . . . . . . . . . . . . . . . . . . 3

4.6 Gitterstruktur eines Terrainblocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.22 Auflagekräfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

1.1 Motivation und Zielsetzung

Da ein physikalisches Modell in Abhängigkeit von seinem Detaillierungsgrad schnell

1. Durch welche externen Kräfte wird das Modell beeinflußt?

dung möglichst gut angepasst werden. Im Speziellen bei Echtzeitanwendungen wird

1.2 Aufbau der Arbeit

In den Kapiteln werden folgende Themen besprochen:

• Kapitel 2, „Physikalische Grundlagen“, stellt die physikalischen und mathematischen

• Kapitel 5, „Systemarchitektur“, gibt einen Überblick über die vorliegende Implemen-

• Kapitel 6, „Implementierungsaspekte“, behandelt wichtige Aspekte in der Umsetzung

• Kapitel 7, „Laufzeitmessungen“, präsentiert die Ergebnisse, die in der Simulation

2. Das Objektkoordinatensystem des Fahrzeuges

3. Die Objektkoordinatensysteme der Räder

Abbildung 1.1: Bezugskoordinatensysteme des Fahrzeuges

Wird in den folgenden Kapiteln von Longitudinal- oder Lateralkräften gesprochen, so

Die Kinetik untersucht die Bewegung von Massepunkten, Massepunktsystemen, Kör-

2.1 Diskret-kontinuierliche Simulation

durch schrittweise Integration der abgeleiteten Systemgrößen über die Simulationszeit

Da der kontinuierliche Prozess von diskreten Ereignissen unterbrochen werden kann,

2.1.1 Kontinuierliche Simulation von physikalischen Systemen

Da der Funktionsverlauf nur an bestimmten Stützpunkten exakt gegeben ist, muß er in

2.1.2 Integrationsverfahren nach Euler

Für die Radaufhängungen des Fahrzeuges werden Masse-Feder-Systeme benötigt. Diese

1. Erdanziehungskraft (Gravitation) – Die Gravitationskraft F ist gleich dem Produkt

Abbildung 2.1: Kräftediagramm: 2-Weg-Federsystem

Abbildung 2.2: Blockschaltbild für das Masse-Feder-System

2.3 Drall (Impulsmoment)

Die Ableitung von L nach der Zeit entspricht dem Moment.

2.4.1 Position und Orientierung

Um die Position eines Punktes von Objektkoordinaten in Weltkoordinaten zu transfor-

Abbildung 2.3: Transformation eines Punktes vom Objektkoordinatensystem

2.4.2 Lineare und angulare Geschwindigkeit

Die angulare Geschwindigkeit beschreibt die Änderung der Orientierung, R· ( t ) . Die

2.4.2.1 Geschwindigkeit eines Partikels im Starrkörper

Abbildung 2.4: Geschwindigkeit des i-ten Partikels im Strarrkörper

2.4.3 Kraft und Moment

2.4.3.1 Linearer Impuls

2.4.3.2 Angularer Impuls

2.5 Verteilung der Auflagekräfte

2.5.1 Herleitung der statischen Verteilung

Abbildung 2.5: Herleitung der vertikalen Kräfteverteilung über Momente

Es werden folgende Momente angesetzt:

2.5.2 Geometrische Interpretation und Anwendung

Abbildung 2.6: Geometrische Interpretation der vertikalten Kräfteverteilung:

2.6 Übertragung der Horizontalkräfte

Zur Bestimmung der Kräfteverteilung werden folgende Momente angesetzt: