3D-Spieleprogrammierung
Werbung
3D-Spieleprogrammierung
Physik
und
Kollisionsabfrage
10.12.2008
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Kontakt
` Marc Herrlich
mh@tzi.de
Tel. 0421/218-64410
` Martin Faust
faust@tzi.de
Tel. 0421/218-64412
` Webseite zur Vorlesung:
http://medien.informatik.uni-bremen.de/teaching/2008_2009/3d_spieleprogrammierung/
` Materialien, Folien, etc. gibt es auf unserer Webseite
(siehe oben).
` Bitte meldet euch außerdem zur besseren Kommunikation
für die Veranstaltung im Stud.IP an (falls noch nicht
geschehen)!
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Plan für die Vorlesung
22.10.08 Einführung und Organisatorisches
29.10.08 Grundlagen Szenengraph, Content und Bewegung
05.11.08 Mathematische Grundlagen
12.11.08 Spielerinput / Kameras
19.11.08 Licht, Schatten und Texturen
26.11.08 Echtzeit-Grafik
03.12.08 Animation
10.12.08 Terrainrendering, Physik und Kollisionsabfrage
15. und 17.12.08 Präsentation: aktueller Stand der Spiele
Weihnachtsferien
07.01.09 Audio
14.01.09 Spiele-KI
21.01.09 Spezielle Renderingtechniken, Multithreading und Optimierung
28.01.09 Gaming Day
04.02.09 Feedback, Imagine Cup, etc.
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Physikbasierte Animation
` „Dynamics“
` Berühmtes Beispiel: „Luxo Jr.“ von Pixar (1987)
` Ursprünglich Keyframe Animation
` 1988 von Witkin und Kass „physikalisch“ animiert
http://www.pixar.com/shorts/ljr/
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Dynamic Simulation
` Computer Animation (und damit Spiele) mit mehr
„High-Level Control“
` Festlegung einzelner Keyframes bzw. Interpolation
ersetzen durch „Springe von A nach B“
` Modelle und interessante Fälle in Spielen sind sehr
komplex, daher nur sehr eingeschränkt mit
„klassischer“ Physik zu lösen
` Anwendungsspezifische Lösungen daher wichtig, d.h.
Wie sieht die Simulation aus? Welche Gleichungen werden benutzt?
Wie können Bedingungen (Constraints) eingebaut werden?
Wie kann die Simulation kontrolliert werden? Wie kann der Benutzer
damit interagieren und wie fügt sich die Simulation in die
Gesamtarchitektur ein?
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Initial Value vs. Boundary Value Problems
` Initial Value Problems:
Anfangsparameter werden vorgegeben
und dann wird der nächste Zeitschritt
simuliert
` Boundary Value Problems:
Das Ergebnis ist „fix“, die Simulation soll
eine Antwort darauf liefern, wie wir
„dorthin“ gelangen (vgl. IK)
` Aktuell in Spielen meist IVP, aber
BVP werden immer wichtiger
(speziell für KI)
Beispiel: Luxo Jr. (Offline Simulation)
[3D Games, Vol1]
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Motivation für dynamische Simulation
` Simulation liefert „automatisch“ (emergent) komplexes
Verhalten
` „Faken“ funktioniert zwar, liefert aber nur spezielle
Lösungen für Abläufe, die der Entwickler komplett
vorausgeplant hat
` Balance zwischen Realismus und „Game Play“ lässt
sich relativ einfach beeinflussen
` Wichtige Gesichtspunkte:
Detailgrad des Gesamtsystems
Detailgrad der Interaktion
Machbarkeit
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Physikalische Grundlagen für Partikel
` Newtons zweites Gesetz:
Kraft = Masse * Beschleunigung:
r
r
F = ma
` Partikel (Punktmasse) → nur Translation
` Newtons zweites Gesetz kann auch in Abhängigkeit
von Geschwindigkeit
r bzw. Ort formuliert werden:
r&
r&
&
F = mv = mx
` Daraus kann abgeleitet werden, wie die neue Position
r
berechnet werden kann:
r
r
r
r
F
v (t + dt ) = v (t ) + adt = v (t ) + dt
m
r
r
r
r
r
1r 2 r
1F 2
x (t + dt ) = x (t ) + v (t )dt + adt = x (t ) + v (t )dt +
dt
2
2m
r
r
1 r
= x (t ) + (v (t ) + v (t + dt ))dt
2
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Partikel – Fortsetzung
` Allgemein: F und m hängen ebenfalls von t ab
` Integrationsmethode ist kritisch für die Genauigkeit
` Euler Methode (siehe vorherige Folie) ist sehr einfach,
wird aber sehr schnell ungenau
` Bei kleinen Zeitschritten dt liefert dt^2 nur einen sehr
kleinen Beitrag, daher kann man vereinfachen:
r
r
r
x (t + dt ) = x (t ) + v (t )dt
r
r
r
v (t + dt ) = v (t ) + adt
` Um numerische Instabilitäten auszugleichen, führt man
meist noch eine Dämpfungskonstante d ein:
r
r
r
v (t + dt ) = v (t )dr + adt
` Theoretisch auch zeitabhängig:
r
r
t
v (t + dt ) = v (t )d + adt
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Partikel – Implementierung
` Wir „drehen“ nur an der „Beschleunigungsschraube“ bzw. an den
Kräften (Ausnahme: „Collision Resolution“, diese modelliert man
direkt über den Impuls)
` Die Beschleunigung ergibt sich in jedem Frame aus den wirkenden
Kräften, während die Geschwindigkeit bzw. der Impuls erhalten
bleibt (Newtons erstes Gesetz)
` Kräfte werden über Vektoraddition zusammengefasst
forceAcc = force1 + force2 + …
` Wichtigste Kraft: Erdanziehung
Eigentlich g ~ 10 m/s^2, wirkt in Spielen aber meist „langweilig“
Shooter verwenden daher oft ca. 15 m/s^2, Rennspiele manchmal sogar 20 m/s^2
Erdanziehung forceGravity = mg, wg. a = F/m kann die Gravitation auch direkt als
Beschleunigung einbezogen werden, z.B. gravity = (0, -g, 0)
` Frage: Wie repräsentieren wir unendlich große bzw. sehr kleine
Massen?
` Antwort: Am besten wir speichern 1/m, dann
1/m = 0 ~ unendliche Masse
1/m = „sehr groß“ ~ sehr kleine Masse, aber nie unendlich klein
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Partikel – Pseudocode
void Integrate(float dt)
{
if (dt <= 0) throw new Exception(…);
position += velocity * dt;
acceleration = forceAcc * inverseMass;
velocity += acceleration * dt;
velocity *= pow(damping, dt);
}
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Typische Kräfte
` Gravitation
` Dämpfungskräfte (Reibung, Luftwiderstand, usw.)
Linear, Quadratisch, etc. (in Bezug zur Geschwindigkeit), Luftwiderstand kann
z.B. annähernd als quadratisch angenommen werden
vn = normalize(v), s = |v|, fDrag = - vn * (k1*s + k2*s^2)
über k1 und k2 kann gewünschtes Verhalten „eingestellt“ werden
` Federkräfte
elastische Verbindungen erzeugen eine Gegenkraft proportional zum
Verhältnis zwischen aktueller Länge und Ruhelänge
fSpring = -k * (|d| - l0) * d
d der ist Vektor von einem Ende der Feder zum anderen, l0 ist die Ruhelänge
Achtung: Dieses einfache Modell funktioniert nur für relativ elastische Federn!
` Geometrische Bedingungen
im einfachsten Fall als konstante Kräfte modelliert
` Siehe z.B. [Game Physics Engine Development, 2007]
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Physikalische Grundlagen für starre Körper
` Newtons erstes Gesetz:
„Ein Körper verharrt im Zustand der Ruhe oder der gleichförmigen
Translation, sofern er nicht durch einwirkende Kräfte zur Änderung seines
Zustands gezwungen wird.“ (Wikipedia)
Bezieht sich aber nicht auf Geschwindigkeit, sondern auf den sog. Impuls
eines Körpers!
` Wir unterscheiden:
lineare Geschwindigkeit / Impuls (linear velocity / momentum)
Winkelgeschwindigkeit / Drehimpuls (angular velocity / momentum)
` Außerdem wichtig: Massenmittelpunkt eines Körpers (für
unsere Zwecke im Prinzip der Schwerpunkt, physikalisch
gibt es hier aber feine Unterschiede!)
` Kräfte, die am Massenmittelpunkt wirken, verändern den
linearen Impuls (verursachen eine Translation)
` Kräfte, die an anderen Stellen des Objektes wirken,
verändern den Drehimpuls (verursachen Rotation)
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Starre Körper – Fortsetzung
` Linearer Impuls:
r
r
M (t )
v (t ) =
rm
r
r
M (t ) = mv (t )
r&
r&
r
M (t ) = mv (t ) = ma (t ) = F (t )
` Drehimpuls:
r
r
r
r
−1
L (t ) = I (t )ω (t ) ω (t ) = I (t ) L (t )
r&
r&
r
r
L (t ) = I (t )ω (t ) = I (t )α (t ) = τ (t )
` Achtung: I ist eine Matrix, der sog. Trägheitstensor
(„inertia tensor“)
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
World Frame und Body Frame
` Ähnlich wie in der Computergrafik arbeiten wir in
verschiedenen Koordinatensystemen
` Gebräuchlich sind die Bezeichnungen:
World Frame (das Weltkoordinatensystem)
Body Frame (das lokale Koordinatensystem eines Körpers)
` Den Übergang zwischen World Frame und Body Frame
können wir ausdrücken durch einen Translationsvektor
x(t) im World Frame und eine Rotationsmatrix R(t) im
Body Frame bezogen auf den Massenmittelpunkt
` Die Spalten von R(t) geben die Richtung der Body
Space Achsen im World Space an
` R(t) ist orthonormal Matrix, d.h. |R| = 1 und R^-1 = R^T
r
r
r
r (t ) = R (t )rbody + x (t )
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Winkelgeschwindigkeit
` Wie verhält sich der Vektor eines Objektpunktes?
` Beobachter im Body Frame sieht keine Veränderung
` Beobachter im World Frame sieht Translationen und
Rotationen um wechselnde Achsen
` Diese Achsen werden bestimmt durch einen Vektor
ω(t), der durch den Massenmittelpunkt verläuft
` Die Richtung von ω(t) definiert die Drehachse und der
Betrag die Drehzahl (Radiant/Sek.) um diese Achse
[3D Games, Vol1]
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Winkelgeschwindigkeit – Fortsetzung
` Änderung eines Objektpunktes auf Grund der
Winkelgeschwindigkeit:
[3D Games, Vol1]
r
r&
r
rbody (t ) = ω (t ) × rbody (t )
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Integration beider Komponenten
⎡rxx
⎢
R(t ) = ⎢rxy
⎢ rxz
⎣
ryx
ryy
ryz
⎡
⎛ ryx ⎞
rzx ⎤
⎛ rxx ⎞
⎛ rzx ⎞⎤
⎜ ⎟r
⎜ ⎟r
⎜ ⎟⎥ r
⎢r
⎥ &
rzy ⎥ R (t ) = ⎢ω (t ) × ⎜ rxy ⎟ω (t ) × ⎜ ryy ⎟ω (t ) × ⎜ rzy ⎟⎥ = ω (t ) ∗ R(t )
⎜r ⎟
⎜r ⎟
⎜ r ⎟⎥
⎢
rzz ⎥⎦
⎝ xz ⎠
⎝ zz ⎠⎦
⎝ yz ⎠
⎣
r
r
r
r (t ) = x (t ) + R (t )rbody
r&
r&
r
&
r (t ) = x (t ) + R(t )rbody
r
r&
r
r
r (t ) = v (t ) + ω (t ) ∗ R(t )rbody
r
r
r
r
r
= v (t ) + ω (t ) ∗ ( R(t )rbody + x (t ) − x (t ))
r
r
r
r
= v (t ) + ω (t ) ∗ (r (t ) − x (t ))
r
r
r
r
= v (t ) + ω (t ) × (r (t ) − x (t ))
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Trägheitstensor
` 3x3 Matrix
` Beschreibt die Masseverteilung in einem Körper
` Für symmetrische Objekte sind nur die Elemente der
Hauptdiagonalen ungleich Null
` Allgemeiner Aufbau:
⎡ Ix
⎢
I = ⎢− I xy
⎢ − I xz
⎣
− I xy
Iy
− I yz
− I xz ⎤
⎥
− I yz ⎥
I z ⎥⎦
I x = ∫ ( y 2 + z 2 )dm
n
I x = ∑ mi ( yi + zi )
2
i =1
2
I xy = ∫ xydm
n
I xy = ∑ mi xi yi
i =1
` Transformation in den World Frame:
I (t ) = R (t ) I body R (t )T
−1
I −1 (t ) = R (t ) I body
R (t )T
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Trägheitstensoren einfacher Körper
` Kugel mit Radius r und Masse m:
2 2
I x = I y = I z = mr
5
` Zylinder mit Radius r, Höhe h und Masse m (z ist lange
Achse):
1
1 2
1 2
2
I x = I y = m(r + h ), I z = mr
4
3
2
` Rechteckige Box mit den Seiten a, b, c und Masse m:
1
1
1
2
2
2
2
I x = m(b + c ), I y = m(a + c ), I z = m(a 2 + b 2 )
12
12
12
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Drehmomente und Kräfte
` r sei Positionsvektor des Punktes, auf den ein Impuls
wirkt und x der Positionsvektor des
Massenmittelpunkts
` Drehmoment und linearer Kraftanteil hängen dann wie
folgt zusammen:
r r r
τ = (r − x ) × F
r
` Für unsere Integration summieren wir Drehmomente
und lineare Kräfte getrennt auf (forceAcc, torqueAcc)
` Für Kräfte, die nicht am Massenmittelpunkt wirken,
berechnen wir das Drehmoment und addieren beide
Anteile auf
` Drehmomente können direkt aufsummiert werden
` Rotationen und Orientierung können wieder gut durch
Quaternionen dargestellt werden
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Prinzipieller Ablauf
r
r
r
x (t + dt ) = x (t ) + v (t )dt
r
R(t + dt ) =R (t ) + ω (t ) ∗ R (t )dt
r
r
FAcc (t + dt ) = ∑ F (t + dt )
r
r
τ Acc (t + dt ) = ∑τ (t + dt )
r
r
r
1
v (t + dt ) = v (t ) + FAcc (t + dt ) dt
m
r
r
r&
r
r
−1
ω (t + dt ) = ω (t ) + ω (t )dt = ω (t ) + I world (t )τ Acc (t + dt )dt
−1
−1
I world
R (t + dt )T
(t + dt ) = R (t + dt ) I body
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Starre Körper – Pseudocode
void Integrate(float dt)
{
position += velocity * dt;
// would be so much easier with quaternions..
orientation += new Matrix(
cross(rotation, orientation.col[0]),
cross(rotation, orientation.col[1]),
cross(rotation, orientation.col[2]));
acceleration = forceAcc * inverseMass;
angularAcceleration = inverseInertiaTensorWorld * torqueAcc;
velocity += acceleration * dt;
rotation += angularAcceleration * dt;
velocity *= pow(linearDamping, dt);
rotation *= pow(angularDamping, dt);
// update and normalize matrices etc.
…
}
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Numerische Integrationsmethoden
` Euler Integration (Explizit, Implizit)
` Adams-Bashforth
` Predictor-Corrector
` Runge-Kutta
` Adaptive Step Size
` …
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Kollisionsabfrage – Collision Detection
` Immer noch Forschungsthema
` Nicht trivial
` Exakte Bestimmung sehr rechenintensiv
` Außerdem ein Problem: sehr schnelle Objekte
schnell heißt Objektgeschwindigkeit in Relation zum Update-Intervall
` In Spielen: Optimierung durch mehrstufigen Ansatz
Broad phase/narrow phase approach
Kombination/Auswahl der Stufen hängt stark von der Art des Spiels
bzw. der Art und Anzahl der Spielobjekte, der benötigten
Genauigkeit, der Interaktionsmöglichkeiten usw. ab
` Räumliche Datenstrukturen, die wir schon vom
Rendering kennen, lassen sich auch für die CD gut
ausnutzen
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Beispiel Stufenabfolge
` Broad Phase
Kollisionstest über alle Objekte zwischen Bounding Boxes
(Ausnutzung von Bounding Volume Hierarchie (BVH) oder Quad/Octrees)
Kollisionstest zwischen zwei Objekten anhand von approximierten
Volumina (z.B. Bounding Volumes für Submeshes, oder Objektform
wird durch viele kleine Kugeln nachgebildet)
` Narrow Phase
Kollisionstest auf Dreieck-Ebene zwischen Submeshes (Analytische
Methoden, Separating Planes, etc.)
Berechnung der Collision Response (entweder Teil der
Physiksimulation oder Speziallösungen für bestimmte Fälle)
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Bounding Volumes
` Für effiziente Berechnung ist ein Volume besser, das die Objekte
möglichst gut approximiert
` Im Extremfall kann BVH auch auf Dreieck-Ebene berechnet werden
` Es kann sich lohnen für die Kollisionsabfrage andere Volumes zu
speichern als fürs Rendering
` Allerdings: Rechenaufwand für Berechnung und Aktualisierung des
Volume ist unter Umständen nicht zu vernachlässigen!
[3D Games, Vol1]
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Weitere Vorgehensweisen
` Kollisionsabfrage durch Strahlen
` Reduzierung auf 2D
` Ausnutzung von zeitlicher Kohärenz
Objekte bewegen nur ganz wenig von Frame zu Frame
Berechne einmal eine Box, die auch ein rotiertes Objekt aufnehmen
kann und verschiebe diese dann nur entsprechend von Frame zu
Frame
[Foliensatz zu Real-time Rendering]
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Schnelle Objekte
` Exakt:
Berechne nächsten Frame
Verfolge den Weg vom letzten Frame zu diesem Frame (z.B.
Strahlverfolgung (Ray), dabei helfen auch wieder Spatial Data
Structures)
Im Fall eine Kollision: Setze Position zurück auf das letzte Frame
berechne den exakten Zeitpunkt der Kollision und von dort
ausgehend die Simulation neu bis zum aktuellen Frame
Zeichne aktuellen Frame
` Approximativ:
Skaliere Bounding Box mit der Geschwindigkeit
Eventuell reicht sogar der skalierte Orientierungsvektor
(Geschwindigkeitsvektor) für einen ersten einfachen Test
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Gelände
` Berechne Höhe des Terrain
Finde Dreieck (beachte y-Koordinate nicht)
Stelle Ebenengleichung auf (Normale über Kreuzprodukt)
x und z sind bekannt, aus der Ebenengleichung kann man y
berechnen
` Verschiedene Möglichkeiten (je nach Genauigkeit):
Bounding Volume für Terrainblöcke
Triangle Intersection
Point Test (siehe oben)
…
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Collision Response
` Elastische Kollision
Keine Deformation
Bewegungsenergie wird übertragen
` Inelastische Kollision
Bewegungsenergie wird in Deformationsenergie umgewandelt
` Theoretisch:
Physikmodell beeinhaltet Response etc.
` Praktisch:
Simulation nur für „unconstrained“ Movement
Collision Detection stellt Kollisionen fest
Contact Generation berechnet Kontakte für Physik/Response
Collision Response berechnet aus Kollisionsparametern neue
Startwerte für die Simulation
Simulation wird fortgesetzt
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
Literatur
` Dalmau, Core Techniques and Algorithms in Game
`
`
`
`
`
`
`
Programming, New Riders, 2003
Watt & Policarpo, 3D Games: Real-time Rendering and
Software Technology, Addison-Wesley, 2000
Watt & Policarpo, 3D Games: Animation and Advanced RealTime Rendering, Addison-Wesley, 2003
Eberly, 3D Game Engine Design (2nd ed.), Elsevier, 2006
Akenine-Möller et al., Real-Time Rendering, AK Peters, 2008
Zerbst & Duvel, 3D Game Engine Programming, Cengage
Learning, 2004
Carter, Microsoft XNA Unleashed, Sams, 2007
Millington, Game Physics Engine Development, Elsevier,
2007
3D-Spieleprogrammierung
Marc Herrlich & Martin Faust, WS 2008/2009
