3 . 1. Introduction to Real-time Physics

1. 3.1.Introduction to Real-time Physics Overview of core principles behind real-time physics systems

2. Note: The material in this section is based on the course text. Real-time Physics Overview of core principles behind real-time physics systems

3. Video not available in on-line slides

4. Video not available in on-line slides

5. 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.

6. High level overview of a physics engine Generate contact details for interpenetrating /touching bodies Apply world and/or game specific forces and accelerations to 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

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

8. 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.

9. 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.

10. 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:

11. Video not available in on-line slides

12. 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.

13. 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.

14. 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.

15. 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.

16. The Laws of Motion Overview of Newton’s first two Laws of Motion as applied to game physics

17. 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.

18. 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.:

19. 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.

20. 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.

21. 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:

22. Directed reading Directed Reading Directed reading on physics introduction

23. Directed reading Read Chapter 1 of Game Physics Engine Development (pp1-12) Read Chapter 3 of Game Physics Engine Development (pp43-54) Directed reading

24. Summary Today we explored: • What a physics engine is • Different types of physics engines • Newton’s First and Second laws for game physics To do: • Read the directed reading. • Consider if you might wish to develop your own physics engine as your project.