1

KIPA Game Engine Seminars

Jonathan Blow

Ajou University

December 9, 2002

Day 12

2

Physics

• Goal: We want gameplay that’s more immersive– Want the world to feel alive, not dead and static

• Physical simulation is one way to achieve this– If objects fall over when you push on them,

that’s interaction with the player that makes things more involving

3

Alternate method: scripting

• If you want the player to be able to topple the pile of logs holding up a guard post, perhaps script that event– Too much manpower; you need to script

*everything* and that is too hard– The player can only do what you have allowed

him to do; so he doesn’t have true freedom

4

Physics can save memoryas well as work?

• If you can simulate what happens to a person’s body when they get knocked down, you don’t need to pre-author an animation for that– Don’t need to spend the time to make it– Don’t need to spend the memory to store it

5

Problem: for gameplay, we need to limit the authority of physics

• Physically-based locomotion is hard, we can’t solve it yet– Not even in realtime for simple creatures;

humans are out of the question

• So we need to constrain player physics to a simpler model and “fake” everything higher– For a first-person shooter, maybe model the

player as a box with momentum

6

Problem: for gameplay, we don’t want the player to be a box

with momentum• In a first-person shooter, we want the

control to be as responsive as possible– When you move or strafe, you start accelerating

instantly– When you jump, you jump instantly

• Giving the player object momentum reduces the amount of player control– Game feels bad

7

Wider view of this problem:In a physics-based game, you

can’t move anything• You can only change accelerations on an

object, and those integrate up to eventually affect the position

• Making a script say “set this guy’s velocity to V” essentially applies an infinite amount of force, which can make physics blow up

• We can hack around this in some cases, but if we do it too much, we don’t really have a simulator

8

Is this a good thing?• Shouldn’t we want control in a game to be lagged

like it is in real life?– When you jump, you have to prepare a little bit

• Maybe for some types of games, but definitely not for action games– You have years of experience steering your body and

you communicate with it deeply; so that “preparation for jumping” is natural and instinctive

– A game controller is some joysticks and buttons, you don’t have very much communication bandwidth with the game; so controlling your character is awkward by nature

• Just think about how hard it is to look around with an analog joystick in 3D

9

Valve’s solution:Attach an invisible box to the

player with a spring• Havok physics system runs using the box as the

effective player object; player drags the box through the world

• Forces applied to the box are transmitted back to the player, but with filters applied

• Generally this lets the game compartmentalize itself away from physics, which is nice– A separate module looks at player position and pulls

the box along

10

Problem: What do you do when a player turns very quickly

and hits an object?• Do you really want to throw that object

aside with huge momentum? Probably not.– So maybe tune it down

• But when a falling object hits the player, you need to compute damage from it

• How to distinguish between player-hits-object and object-hits-player?– This is basically an AI problem

11

Another aspect of that problem, what if the player turns quickly

and hits a wall• The wall has “infinite mass” so the player

should bounce away from the wall very energetically

• This would feel horrible so we can’t allow it.

12

Physics and Stability

• Most physics algorithms aren’t stable; they tend to “blow up” for certain inputs

• In batch applications like movie animation, they adjust the parameters and try again

• In games, it has to work the first time– For frame rate reasons– Because maybe we can’t adjust the parameters

13

So we need stable physicsthat runs in realtime

• To have a hope of developing this technology, we need to apply early versions in real games

• But how do we do this without ruining those games?

• Use the tech in ways that don’t directly affect gameplay– Special effects like explosions– Ponytails, etc

14

I’ve made it sound hard,but it’s not impossible

• David Wu of Pseudo Interactive designed the engine for “Cel Damage” (X-Box)

• Physics-based engine with finite element deformation, etc.

15

Dave says

• Physics and level design interact heavily

• For a vehicle combat game, you want mechanical engineering knowledge to design a stable vehicle

• When building a level, want to understand the subtleties of how objects interact– Collapse a bridge, etc

16

Problem with animation: we can’t know the future

• When the player presses the jump button, they need to start flying through the air

• To physically synthesize a jump we would have the player crouch a little in preparation

• But that all needs to have happened before the button press (so it didn’t happen!)

• The same problem happens in pre-authored animations, but we can work around it

17

David Wu’s list of goalsfor a game in development using

animation synthesis• Controls should be simple and accessible

• Control should be direct– Animation should not interfere by adding

latency or preventing a desired action

• Plausibility– Avatar should be physically accurate;

animation transitions should be smooth (at least C1 continuous)

18

David Wu’s list (2)• Visual/Audio Feedback

– As much information about the avatar’s state as possible should be communicated (where each hand is, where weapon is, where avatar is looking, where feet are, etc)

– When player initiates an action the results should be immediately visible

• Coolness– Avatar should look cool; should have style and

personality in its actions

19

David Wu’s list (3)

• Dave says this is an “overconstrained system” meaning it would be very difficult to achieve all goals

• But this list is basically what we strive for in synthesized animation

20

Integration

• Analytical integration

• Numerical integration of ODEs– Ordinary Differential Equations

• Friction, cooling, etc

21

Integration:Euler’s Method

• (Example on whiteboard)

22

Integration: Runge-Kutta

• Different order integrators (RK3, RK5, etc)

• Better accuracy than Euler integration

• Not my specialty so I won’t explain it in detail– Plenty of information available on the web

23

Collision response:Penalty forces

• Push objects away from each other using springs

• Springs have to be stiff or the simulation will feel “soupy”

• Stiff springs are hard to simulate in real time

• Generally we don’t have enough CPU time to make these feel good

24

Some physical truthto penalty forces

• Objects in the real world are soft, not totally rigid

• When they collide, they deform and then spring back

• So the interpenetration of penalty forces can be an approximation to this

• But, we don’t necessarily have the CPU to approximate things at the right scale

25

Collision response:Impulse-based microcollisions

• See Brian Mirtich’s paper from 1996

• Maintain invariant that objects never interpenetrate

• Objects are totally rigid

• Approximate object “softness” by integrating effect over a time interval

• Fast enough to be used in games

26

Maintaining non-penetration• I’ve said before that this is a good idea in games• But I’ve had a lot of problems with it in the past

– Algorithms get complicated

– Floating-point accuracy?

• It always seems like sometimes this constraint gets magically violated, and you have to fix it– Teleport objects apart?

– Hard to do without screwing with the game

27

How physics affects game architecture

• Higher-order integrators want to sample at multiple times during one simulator timestep

• They need the function to be continuous over that period

• That means there can’t be ‘if-statement’ style discontinuities inside anything generating forces– ‘if’ statements are all about discontinuity!

28

How physics affectsgame architecture (2)

• AI routines are an example of something that changes forces

• Routines need to be split into “inside timestep” and “outside timestep”

• This makes them more complicated, which is unfortunate.

29

Things you want to knowto simulate objects

• F = ma (linear motion)

• Τ = Iα (angular motion)

• Need to know mass (m) and mass distribution (I) of an object

30

m, x, and Iin 2D

• Treat the object as an infinite number of point densities

• m is the sum of all the densities, times area (total magnitude of mass)

• x is the sum of the first moment of the point positions, times the density of each (center of mass)

• I is the sum of the second moment of the point positions, times the density of each (“Moment of inertia”) [Often simplified into a scalar due to only one axis of rotation]

31

Computing m, x, and I

• (2D example on whiteboard)

• For a specified 2D solid, you can compute the answers for all the simplices in closed form, then sum them to get the answer

32

Computing m, x, and I in 3D

• m remains a scalar,

• x becomes a 3-vector for the position of the center of mass,

• I becomes a 3x3 symmetric matrix

• I is just like the vector variance matrices we have looked at a few times already

33

Linear Constraints

• Point-on-line

• Point-on-plane

• Distance constraint

34

Angular Constraints

• Restrict plane of rotation

• Restrict rotation magnitude to lie within cone

35

Point, Edge, and Face Collisions

• In 3D objects can collide in a few different ways

• Maintaining physical plausibility means simulating them in different ways (analogy to constraints)

36

Different methods of dealing with constraints

• (flip to Chris’s slides for a little bit)