This section gives a broad overview of physical simulation, and introduces some concepts you might find useful when working with reactor.
Havok’s physics technology, used in reactor, relies on a process known as physical simulation in order to provide a dynamic environment for the objects in a scene. So what exactly does physical simulation mean?
It is a process that automatically determines the motion of objects according to their physical properties. It achieves this by encapsulating some physical laws, like Newton’s laws of motion, within a robust, efficient engine, which calculates the position of each object as time passes. In much the same way that a motion picture is composed of many individual images or frames, physical simulation splits time into small discrete steps and predicts the motion of each object during each step. The cumulative effect of all these steps is fluid, continuous, believable motion.
Unlike traditional keyframe-based animation, where the animator needs to specify a set of keyframed configurations, physical simulation determines how objects move based their properties. This takes the burden from the animator, who now doesn't need to manually animate every piece in an explosion, every bone in a character stunt animation, or every vertex in a piece of cloth.
In a physical simulation, physical properties such as mass and elasticity are assigned to all objects in a scene. This is then complemented with a set of external forces like gravity or wind and/or constraints, like a spring force or a ball-socket configuration. From all this information, the physics engine calculates a continuous set of states that can then be displayed in real-time, if the calculations are fast enough, or converted into keyframes to be played back later.
A physics engine like Havok has three basic tasks to perform:
-
Collision Detection.
Track the movement of all the objects in the scene and detect when any of them have collided.
-
Update System.
Determine an appropriate response for objects that have collided by resolving the collision according to the object properties and for all other (non-colliding) objects update them according to the forces acting on them.
-
Interface with Application.
Once reactor determines the new positions and state of all objects, it can display the objects in a 3D window or store their states in the form of keyframes.
Note: A physics engine knows nothing about how the objects it is simulating are displayed. It simulates the motion and interaction of these objects based on a physical (not graphical) description of the objects, and this information can be used to generate a display that “tracks” the simulation.
Given that we are talking about simulating a continuously evolving state (in other words, objects are moving and colliding and reacting all the time in general), we need to map this to a series of snapshots in order to generate an animation. In a computer game, for example, we typically want to display the world 60 times per second, because this is how frequently many graphics systems can redraw the screen. When creating an animation, we may want to store the state (that is, create a keyframe) for every frame. At 60 FPS, for example, this would also create 60 keyframes every second, What this really means is that the physics engine must be capable of evolving the world by 1/60th of a second knowing the state of all the objects at the start of this time interval and knowing the external forces acting on these objects. As an example we'll look at the simple case of a cannon ball and we’ll assume we're interested in animation at 60Hz (Hz = cycles or frames per second).
Let’s forget about collisions for now, and consider only the simulation of a cannon ball immediately after it has been fired from the cannon. We know the ball’s position (and orientation, but we'll ignore this for now), speed, acceleration, and weight, and we assume we know the state of the environment (air resistance, wind force, gravity). Armed with this knowledge we can start to make predictions using a physics engine.
This figure illustrates what we would like to achieve. Over a period of time the cannon ball’s rate of ascent should slow due to gravity, and it should eventually fall to the ground having traveled through a classic parabolic arc (assuming no air resistance).
At a given point in time we can examine the state of the ball (its speed v and acceleration a) and knowing the external forces acting on it we can make a guess as to its change in position after a period of time has elapsed (call this period h seconds). This guess is a combination of a number of factors:
-
We assume that Newton’s laws of motion govern the motion of the ball
-
We assume that in the time period h all the external forces acting on the ball are constant, so air resistance and wind and gravity do not change during this time.
-
We assume that the math we use to calculate the new position is accurate
In general, the first assumption is usually valid, except at relativistic or quantum scales, which we can assume should be handled by other systems. The remaining two, however, cause problems and are closely linked to the time period h over which we’re performing the calculations. We’ll now examine the effect of the size of this time period on the accuracy of the simulation.
In general, the forces acting on an object are rarely truly constant; gravity is close to being constant, but most other forces like wind and air resistance are not. So, taking the cannon ball example, imagine a windy layer in the atmosphere that the cannon ball passes through, as shown in the next figure.
In the simulation on the left we assume we’re taking steps of one second; this is actually a relatively large interval for a physics simulation, but is used here to illustrate the point. We know all the forces acting on the ball at time t1 so we use some math to predict the new position and velocity at time t2, after one second has elapsed. During this period, we assume that the wind force acting on the ball is constant. In this example, we’ll calculate the new position above the region of high wind, so we’ll effectively have missed the windy bit by taking too great a jump. In the second example on the right, we’re using time steps of ½ second. In this case, after determining the new position at time t2 we find the ball in the middle of the windy region. This region causes a large wind force to act on the ball which is taken into account during the next time step. At that point we reevaluate the math and determine a new position for the ball at time t3. This is different from the position determined in the simulation on the left, even though the same amount of time has been simulated in each case. In other words, the wind has blown the ball to the left a bit and has reduced the velocity of the ball
In general, the smaller the time step taken, the more accurate the result at the end of the time step. Thus, to step forward in time by a large time step t it is better to split this into n steps of a smaller time interval t/n.
This is also true of the math. As the simulation becomes more complex, the math required to calculate the new positions and velocities of objects in a simulation also becomes more complex, and as a result the guesses produced by the math give progressively less-accurate results.
So the principle is to take small time steps, evaluate all the forces acting on the objects, determine the new positions and velocities (and other parameters) of the objects at the end of the time steps, and then start over. We end up with a series of snapshots of the state of the system as it evolves, as shown in the following illustration.
In the previous section, we said that the physics engine passes on the necessary information to update the display after it determines the new positions for all its objects. However, what if you don't want to update the display in each simulation time step?
Let's say we absolutely need to update the application once every 1/60th of a second, either because we're playing a real-time game that refreshes the screen at 60Hz. or we're creating a keyframe every frame for a 60FPS movie. This effectively means that we want to step the physics engine at intervals of 1/60th of a second. In many cases this does not present a problem, but if, hypothetically, the accuracy of the simulation was not sufficient (remember: smaller time steps mean better accuracy), then we’d like to decrease the time step even further, say to 1/120th of a second. But this would mean we generate twice the number of images/keyframes we are interested in, which is wasteful. To get around this, the Havok engine allows you to specify the number of substeps to take per key.
The Substeps/Key parameter specifies the number of steps the physics engine takes before updating the application. This gives control over the granularity of the physics simulation independent of the display update or keyframe-creation frequency. So with Substeps/Key=1, reactor uses a single simulation step for each update to the 3D display. With Substeps/Key=2, reactor takes two physics steps each time before updating the application, and so on.
In this figure, we have specified that the physics simulation should step at intervals of 1/240th of a second, but that we create a keyframe only once every 1/60th of a second. The red spots indicate a keyframe and simulation step, the yellow spots are simulation steps only. This was achieved by instructing the physics engine to employ four substeps per key. Thus, for each four simulation steps we create only keyframe. By setting the number of substeps we can control the accuracy of the physical simulation independent of the number of keyframes created.
Havok simulates most objects in a simulation as rigid bodies. A rigid body is an object whose geometry doesn't change over the course of the simulation. You can simulate any real-world object that doesn't noticeably change its shape, from a pen to a boulder hurtling down a mountainside, as a rigid body. Simulating objects in this way facilitates rapid physical simulation in real time; the physics engine can make certain assumptions when detecting collisions based on the fact that the objects' shapes don't vary from simulation step to simulation step.
Both the Havok 1 and Havok 3 engines can simulate rigid bodies, but Havok 3 simulations are faster and more accurate.
To simulate cloth, rope, or other material whose shape changes over time, you need to use a different type of body: a deformable body. With deformable objects, collision detection becomes much more difficult, given that the object can change shape dramatically between time steps and can also attempt to collide with itself. For this reason, deformable bodies are more expensive to simulate.
Note: Only the Havok 1 engine can simulate with deformable bodies.
Our scientific knowledge of physics is extensive. What we are concerned with here would more accurately be described as a mechanical simulation of the interactions of objects at real-world scales. We are dealing with Newtonian mechanics; that is, the well-understood laws of motion, popularized by Sir Isaac Newton, that describe the behavior of objects under the influences of other objects and external forces. Since then we’ve discovered that these laws break down at very small (i.e. subatomic) and very large (i.e. planetary) scales.
New physics systems have been devised to work with these scales (for example, relativistic and quantum), but these are beyond the scope of the reactor physics engine. The Havok physics simulation technology works at the scale of objects we interact with on a daily basis, such as chairs, cars, buildings, and footballs. By default, the engine works in units of meters and kilograms.
It's important to keep in mind the scale in which you're working. For example, a common mistake people make is to start by creating a cube 100 meters on a side, and then they wonder why it takes so long to fall. A box of this size when viewed at a distance sufficient to be able to see the entire box (say 1km away) will appear to fall at the same speed as an aircraft hangar dropped from a height and viewed from a kilometer away: slowly.
The Havok physics engine does not care what units of measurement you use when specifying the size of objects or the strength of gravity; it cares only about the numbers. So you could, for instance, work in inches. However, for realistic (or at least predictable) results, it's important to be consistent. So, for instance, if you're working in meters, make sure gravity is set to an appropriate value in meters. To produce Earth-like gravity, use 9.8 m/s2. Otherwise objects might appear to fall faster or slower than you expect.
Note: Due to CPU floating-point precision, a physics engine is most accurate when dealing with numbers as close in magnitude to 1 as possible. In other words, values like 10,000,000 work poorly, as do values like 0.0000001. Therefore, for real-world scenes, when creating objects of 1*1*1 size it is most useful to be working in meters or feet, rather than centimeters/inches or kilometers/miles, in that you most often simulate objects larger than sugar cubes and smaller than football fields. It is for this reason that the default values in many physics engines are usually specified in meters.