3.1. INTRODUCTION TO REAL-TIME PHYSICSOverview of core principles behind real-time physics systems

REAL-TIME PHYSICSOverview of core principles behind real-time physics systems

Note: The material in

this section is based on the course

text.

Video not available in on-line slides

Video not available in on-line slides

Definition of a physics engineEarly 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 Collisio

n Detecto

r

Contact Resolve

r

Integrator

Force Generato

rs

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

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 ResolverTwo 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).

Contact Resolve

r

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: IntegratorThe integrator is simply responsible for updating relevant object properties (e.g. position, orientation, velocity) by integrating all forces, etc. applied to the body.

Integrator

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 RepresentationA 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 ResolutionA 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 ForcesAn 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.

Aside: Many middleware commercial systems use a

Jacobian force

based approach.

THE LAWS OF MOTIONOverview 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).

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.

A simple means of modelling drag is to remove a specifiable portion of the object’s velocity at each update, e.g.:

The Laws of Motion: The Second LawLaw 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)

Within the context of a physics engine, gravitational force can be simply directly applied as an acceleration which is assigned to objects during each update.

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 READINGDirected reading on physics introduction

Directed

reading

Directed reading Directed

reading• Read Chapter 1 of Game Physics Engine Development (pp1-12)• Read Chapter 3 of Game

Physics Engine Development (pp43-54)

Summary

To do:Read the directed

reading.Consider if you might

wish to develop your own physics engine as your project.

Today we explored:

What a physics engine is

Different types of physics engines

Newton’s First and Second laws for game physics