CSE 380 – Computer Game Programming Physics Primer

1. CSE 380 – Computer Game ProgrammingPhysics Primer http://blogs.sundaymercury.net/weirdscience/newton2.jpeg

2. Collision Detection Game Physics • This is a huge topic • We’ll start slow • Some good online materials: • Iterative Dynamics with Temporal Cohesion • by Erin Catto, then of Crystal Dynamics, now of Blizzard • http://www.gphysics.com/files/IterativeDynamics.pdf • Game physics is rapidly changing

3. Some more people to know • Christer Ericson • Author of Real-Time Collision Detection (RTCD) • Director of Tools & Tech at Sony (God of War team) • Erwin Coumans • was senior physics SDK Engineer for Havok • currently simulation lead at Sony Computer Entertainment • Gino van den Bergen • Author of Collision Detection in Interactive 3D Environments • SOLID 3D engine

4. Their free, open source engines • Box2D Physics Engine • http://www.box2d.org/ • 2D • Bullet • http://www.bulletphysics.com/Bullet/wordpress/download • 3D • SOLID • http://www.dtecta.com/ • 3D

5. Havok • http://www.havok.com/ • A leading professional-grade physics engine • Recently purchased by Intel • Free version for PC game developers • Since May 2008

6. Additional Courses • Game physics are heavy on: • Algebra, Geometry, & Trigonometry (High School) • Physics (PHY 131, PHY 132, etc.) • Calculus (AMS 151, AMS 161, etc.) • Linear Algebra (AMS 210) • Computational Geometry (CSE 355) • Mechanical Engineering Statics (MEC 260) • Mechanical Engineering Dynamics (MEC 262) • Think of these courses in a whole new light

7. Academic vs. Industry Perspective • Academics/Engineering Researchers: • concerned with solving physics problems correctly • bridges need to be designed correctly • Game Industry Researchers: • concerned with modeling approximated physics solutions efficiently • the bridge just needs to look good to the player

8. Collision Detection & Response • Collision Detection • detecting what game objects are colliding with each other • Collision Response • providing a programmed response to collisions that fits with the game’s design & custom laws of physics

9. Static vs. Dynamic Objects • Static objects never move • Dynamic objects move • Collisions may be between: • Static objects & dynamic objects (fast & easy) • Dynamic objects & dynamic objects (harder)

10. What types of collisions might we care about? • Main character and static objects: • terrain, floor, tiles, walls, furniture, buildings, game objects (i.e. power-ups, ammo), etc. • Main character & dynamic objects: • enemies, projectiles (i.e. bullets, arrows, etc.), particles (expensive), etc. • Other dynamic objects and: • other static objects • other dynamic objects

11. Collisions in Pairs • In collision detection, we always compare pairs of objects. Easier to: • understand • design & implement solutions • A naïve approach: • one pair at a time, compare all game objects in a game world against all other game objects in a game world

12. Non-collidable Objects • No collisions with: • certain background tiles (sky, clouds, grass, etc) • dead enemies (maybe, maybe not) • unimportant game objects • Carefully manage these to minimize calculations • Don’t perform unnecessary tests • First test always: if (collidable)

13. Collision Detection Calculations • What data are we looking for? • Do these two objects potentially collide? • Do these two objects collide? • When did these two objects collide? • Where did these two objects collide? • where on geometry of objects, points of impact • These 4 questions get progressively: • more computationally expensive to implement • more complex to implement (more math)

14. First a little Newtonian physics • Basics terms: • m - mass • t - time • x, y, z – position (s) • physicists use an object’s center of gravity • most games use the center of a Bounding Volume (BV) • v - velocity • ds/dt • a - acceleration • dv/dt • F – force • ma • P – momentum • mv

15. Newton’s Laws of Motion • “Every object persists in its state of rest or uniform motion in a straight line unless it is compelled to change that state by forces impressed on it.” • Force is equal to the change in momentum per change in time. For a constant mass, force equals mass times acceleration.” • For every action, there is an equal and opposite reaction.” Ref: http://www.grc.nasa.gov/WWW/K-12/airplane/newton.html

16. Position Calculations • New Position with constant velocity: xt = x0 + (vx * t) yt = y0 + (vy * t) zt = z0 + (vz * t) • Velocity is a Vector, (vx, vy, vz), or (vx, vy) in 2D • Example, object at (1, 5), velocity of (4, -3)

17. Velocity Vectors • Velocities have direction, their vector Vtotal = √(Vx2 + Vy2 + Vz2) for 3D games Vtotal = √(Vx2 + Vy2) for 2D games

18. Acceleration • Rate of change of velocity • New Velocity (vt) with Acceleration: vt = dx/dt = v0 + (a * dt) • NOTE – each of these calculations are in one dimension • You would perform similar calculations on y & z axes • NOTE: we will avoid mid-frame acceleration • everybody does it, so will we

19. Trajectory Assumption • In a single frame, if no force is exerted upon an object, it will have a constant velocity for that frame

20. Forces and vectors • F = ma • Collisions produce forces on both colliding objects • Forces have direction, their vector • Forces in x, y, & z axes • Ftotal = √(Fx2 + Fy2 + Fz2) for 3D games • Ftotal = √(Fx2 + Fy2) for 2D games

21. Forces can be summed • Done axis by axis Fx = F1x + F2x + F3x Fy = F1y + F2y + F3y Fz = F1z + F2z + F3z

22. Momentum • (P) – A property that objects in motion have P = m * v, measured in kg * m/s • Force equation can be reduced to: F = dP/dt

23. Momentum & Collisions • Note: Ignore friction for now • Momentum transfer – if 2 objects collide: • A perfectly elastic collision: no loss of energy • Momentum is conserved • An imperfect elastic collision: some energy is converted into heat, work, & deformation of objects • Momentum is reduced after collision

24. Rigid Bodies • Note: we are only dealing with rigid bodies • No deformation due to collisions

25. Calculating new velocities • Note: • ignore rotation/angular velocities for now • ignore centers of mass for now • 2 moving blocks collide: • Block A: mA & vAi • Block B: mB & vBi • Question, if they collide, what should their velocities be immediately after the collision? • vAf & vBf

26. Why are we interested in final velocities? • When a collision precisely happens, we want to: • move our objects to that precise location • change their velocities accordingly

27. Calculating vAf & vBf • If momentum is conserved after collision: PAi + PBi = PAf + PBf (mA * vAi) + (mB * vBi) = (mA * vAf) + (mB * vBf) • Problem has 2 unknowns (vaf & vbf) • we need a second equation (Kinetic energy equation) • ke = (m * v2)/2, where ke is never negative Joules (J) • insert the ke equation into our momentum equation vAf = ((2 * mB * vBi) + vAi * (mA – mB))/(mA + mB) vBf = ((2 * mA * vAi) – vBi * (mA – mB))/(mA + mB)

28. Example • 2 blocks moving • Block A: • mass is 10, initial velocity is (4, 0) • Block b: • mass is 10, initial velocity is (-4, 1) • Results: • Block A final velocity is (-4, 1) • Block B final velocity is (4, 0) • See my ElasticCollisionsVelocityCalculator.xls

29. All dynamic objects in our games • Should have a velocity, mass, & AABB • Can be affected by forces • thus can be accelerated (but only at discrete times) • Forces can be summed (ex: collision & gravity) • Note: beware of energy gains in your momentum equations due to rounding errors

30. Coming Up • Collision detection & collision resolution • Building practical Collision Systems • Examining Box2D

31. References • [1] Real Time Collision Detection by Christer Ericson • [2] Physics for Game Programmers by Squirrel Eiserloh • [3] Collision Detection in Interactive 3D Environments by Gino van den Bergen