3D-Spieleprogrammierung
Werbung
3D-Spieleprogrammierung Physik und Kollisionsabfrage 10.12.2008 3D-Spieleprogrammierung Marc Herrlich & Martin Faust, WS 2008/2009 Kontakt ` Marc Herrlich [email protected] Tel. 0421/218-64410 ` Martin Faust [email protected] 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
