3.1. INTRODUCTIONTO REAL-TIME PHYSICS
Overview of core principles behind real-time physics systems
Overview of core principles behind real-time physics systems
Video not available in on-line slides
Video not available in on-line slides
Definition of a physics engine
Early games adopted an adhoc approach to physics, with only the precise
physical effects (e.g. arrow trajectory) needed for that game developed.
Whilst ok for simple simulations, the difficulty of getting physical effects to
look right, combined with the need for common physical effects entailed
developers moved towards more general, reusable, solutions.
A “physics engine” is a common,
reusable, piece of code that
knows about physics in general
but isn’t programmed with the
specifics of each game’s scenario.
As a general simulator it becomes
necessary to supply the engine
with the properties (mass, size,
etc.) of what is to be simulated.
High level overview of a physics engine
Generate contact details
for interpenetrating
/touching bodies
Resolve contacts to
separate any
interpenetrating bodies
and produce resultant
forces/impulses.
Apply accumulated
forces/impulses to bodies
to produce updated
positions and velocities
Apply world and/or game
specific forces and
accelerations to bodies
High level overview: Collision Detector
Collision points (object-to-object, or object-to-immovable-scenery) will
normally be found using a collision detector. Collision detection take the
geometries of the objects into account and produces, as output, a set of
contacts. Features such as the contact point, contact normal,
interpenetration depth, etc. are calculated. Most approaches simply look
for interpenetrating objects, although some try to predict likely future
collisions.
Important: It is the responsible of the
collision detection system to handle the
geometric properties of colliding
objects. The physics simulation part of
the system simply operates on contacts
(and does not need to know the details
of the shape of the object it is dealing
with).
High level overview: Contact Resolver
Two objects are interpenetrating if they are partially embedded in each
other. It is the role of the contact resolver to not only determine the
resultant velocity following a contact, but to ensure that objects are
suitably separated so that they are not interpenetrating (i.e. the objects
are moved apart so that the penetration depth becomes zero – i.e. they
are just touching).
It is the job of the collision detector
to determine how much objects have
interpenetrated.
Determining how two objects should
be moved apart can be complex,
depending on factors such as the
object’s mass, rotational ease, etc.
High level overview: Integrator
The integrator is simply responsible for updating relevant object
properties (e.g. position, orientation, velocity) by integrating all forces,
etc. applied to the body.
Differences between physics engines
Approaches to building a physics engine range from the very simple (and
wrong) to the cutting-edge physics engines of top middleware companies
(Havok, PhysX).
Different approaches can be categorised as follows:
Video not available in on-line slides
Physics engines: Object Representation
A game object can be modelled as follows:
• A rigid-body representation models the object as a solid, non-flexing
entity (which might be a geometric primitive or a more complex
polyhedral).
• A mass-aggregate representation models the objects as if they were
made up of lots of point masses (e.g. a box might can be simulated as
eight point masses connected by rods or springs).
Mass-aggregate engines are easier to develop
as the equations of motion for each point mass
do not need to consider rotation (i.e. the whole
object rotates naturally as a result of the
constrained linear motion of each component).
However, it is hard to get mass-aggregate
objects to act in a very rigid manner.
Physics engines: Contact Resolution
A contact is a point (or edge, or face) between two bodies
which is considered to be touching or otherwise connected.
Contact resolution is the process of deciding how a number
of points of contact within some physics simulation should
be updated each time step. Approaches include:
Iterative approach: Each contact is considered and resolved
individually. This is a fast and relatively easy means of
resolving points of contact; however, resolving one contact
might affect another contact in a non-realistic manner.
Jacobian-based approach: The exact interaction between
different contacts are calculated to provide an overall set of
effects which are then apply to all objects at the same time.
Whilst more complex and computationally expensive this is
a more physically realistic approach.
Physics engines: Impulses and Forces
An impulse can be considered an (near) instantaneous force that acts to
change the velocity of some object, e.g. a falling ball bouncing on the
ground.
Force-based engine: Interaction is modelled using
forces (i.e. impulses are forces acting over a very
small period of time). This approach is more accurate
(modelling reality) however, the mathematics are
also more complex.
Impulse-based engine: Interaction is modelling using
impulses. For example a book resting on a table is
kept there by lots of miniature collisions (due to
gravity) rather than a constant force. This approach
can suffer from jitter and instability given a low frame
rate, but is more simple to implement.
What we will consider:
We will explore the creation of a rigid-body, iterative,
impulse-based physics engine.
Overview of Newton’s first two Laws of Motion as applied to game
physics
The Laws of Motion: The First Law
Law 1: An object continues with a constant velocity unless a force acts
upon it.
Newton’s First Law states that it is the
object’s momentum that is constant in
the absence of force (not simply
velocity).
This is an important distinction when
considering angular velocity (i.e.
rotations) where a change in how the
body’s mass is distributed will, under
this law, result in a change in rotational
speed with no other forces acting.
The Laws of Motion: The First Law
Observed movement is subject to some form of
drag or friction (from the air, or some contact
surface). For most game physics engines a simple
model of drag can be directly embedded within
the physics engine (i.e. only for complex flight or
racing game simulations is an explicit force
modelling drag needed).
A simple means of modelling drag is to remove a specifiable portion of the
object’s velocity at each update, e.g.:
The top form is sensitive to the update
frequency. The bottom form is independent
of update rate, however, xy is expensive and
not ideal given a large number of objects.
The Laws of Motion: The Second Law
Law 2: A force acting on an object produces acceleration that is
proportional to the object’s mass.
Force changes the acceleration of an object, i.e. the position and velocity
are changed by indirectly applying a force (changing acceleration). In other
words, the position and velocity properties should be updated within the
physics integrator (and normally not manually altered). The accelerative
force will be (mostly) determined through the integration of applied
forces.
The Laws of Motion: The Second Law
The formula relating the force to the acceleration is
Gravity
Strictly, gravity applies between every pair of objects with a resting mass
according to the “law of universal gravitation”:
Within the context of a planet-bound game and ‘normal’ objects, the
equation can be simplified to:
On earth g has an average value of 9.8 ms-2, however, in most games a
value greater than 10 ms-2 is selected to provide ‘convincing’ or ‘exciting’
object behaviour (e.g. ~15ms-2)
The Laws of Motion: Updating Positions
The equation for determining the change in an object’s position is:
As the time step within a game is likely to be very small (e.g. 0.017s for
60ups) the squared acceleration component of the above equation
becomes very small (0.00029) and can be effectively ignored.
As such, within a physics game engine the position
can simply be updated as:
Directed reading on physics introduction
Directed reading
• Read Chapter 1 of Game Physics
Engine Development (pp1-12)
• Read Chapter 3 of Game Physics
Engine Development (pp43-54)
Summary
Today we
explored:
 What a
physics engine
is
 Different
types of
physics
engines
 Newton’s First
and Second
laws for game
physics