Physics engine

Physics simulations by a physics engine

These are four examples of a physics engine simulating an object falling onto a slope. The examples differ in accuracy of the simulation: No physics. Gravity, no collision detection. Gravity and collision detection, no rotation calculations. Gravity, collision detection and rotation calculations.

A physics engine is a computer program that simulates Newtonian physics models, using variables such as mass, velocity, friction and wind resistance. It can simulate and predict effects under different conditions that would approximate what happens in real life or in a fantasy world. Its main uses are in scientific simulation and in video games.

Description

There are generally two classes of physics engines, real-time and high-precision. High-precision physics engines require more processing power to calculate very precise physics and are usually used by scientists and computer animated movies. In video games, or other forms of interactive computing, the physics engine simplifies its calculations and lowers its accuracy so that they can be performed in time for the game to respond at an appropriate rate for gameplay. This is referred to as real-time physics. Computer games use physics engines to improve realism.

Physics engines have two core components, a collision detection system, and the dynamics simulation component responsible for solving the forces affecting the simulated objects. Modern physics engines may also contain fluid simulations, animation control systems and asset integration tools. There are three major paradigms for the physical simulation of solids:

• Penalty methods, where interactions are commonly modeled as mass-spring systems. This type of engine is popular for deformable, or soft-body physics.
• Constraint based methods, where constraint equations are solved that estimate physical laws.
• Impulse based methods, where impulses are applied to object interactions.

Finally, hybrid methods are possible that combine aspects of the above paradigms.

Scientific engines

One of the first general purpose computers, ENIAC, was used as a very simple type of physics engine. It was used to design ballistics tables to help the United States military estimate where artillery shells of various mass would land when fired at varying angles and gunpowder charges, also accounting for drift caused by wind. The results were calculated a single time only, and were tabulated into printed tables handed out to the artillery commanders.

Physics engines have been commonly used on supercomputers since the 1980s to simulate the flowing of atmospheric air and water, in order to predict weather patterns. This is known as computational fluid dynamics modeling, where particles of air are assigned a force vector, and these combined forces are calculated across vast regions of space to show how the overall weather patterns will circulate. Due to the requirements of speed and high precision, special computer processors known as vector processors were developed to accelerate the calculations.

Generally weather prediction is still an inaccurate science because the resolution of the simulated atmosphere is not detailed enough to match real-world conditions, and small fluctuations not modeled in the simulation can drastically change the predicted results after several days.

Similar fluid dynamic modeling is also commonly used for designing new types of aircraft and watercraft, and can provide engineers the information that used to be obtained solely from wind tunnel testing.

Tire manufacturers use physics simulations to examine how new tire tread types will perform under wet and dry conditions, using new tire materials of varying flexibility and under different levels of weight loading.

Electronics manufacturers use fluid dynamic modeling to examine how cooling air will flow through the computer case, to locate thermal hotspots that may need additional cooling.

Game engines

In most computer games, speed of simulation is more important than accuracy of simulation. Typically most 3D objects in a game are represented by two separate meshes or shapes. One of these meshes is a highly complex and detailed shape which the player sees in the game, for example a vase with elegant curved and looping handles. However, for purposes of speed, a second highly simplified invisible mesh is used to represent the object to the physics engine. To the physics engine, the object may be processed as nothing more than a simple tall cylinder. It is therefore impossible to insert a rod or fire a projectile through the handle holes on the vase, because the physics engine does not know the handles exist and only processes the rough cylindrical shape. The simplified mesh used for physics processing is often referred to as the collision geometry. This may be a bounding box, sphere, or convex hull. Engines that use bounding boxes or bounding spheres as the final shape for collision detection are considered extremely simple. Generally a bounding box is used for broad phase collision detection to narrow down the number of possible collisions before costly mesh on mesh collision detection is done in the narrow phase of collision detection.

In the real world, physics is always active. There is a constant Brownian motion jitter to all particles in our universe as the forces push back and forth against each other. For a game physics engine, such constant active precision is unnecessary and a waste of the limited CPU power. In the 3D virtual world Second Life, if an object is resting on the floor and the object does not move beyond a certain minimal distance in about two seconds, then the physics calculations are disabled for the object and it becomes frozen in place. It remains frozen until a collision occurs with some other actively physical object, and that reactivates physics processing for the object. This freezing of stable non-moving objects allows the physics engine to conserve processing power and increase the framerate of other objects currently in motion, but can lead to unusual problems such as a huge slow pendulum freezing in place on the upswing, as it slows down and starts to reverse direction.

The primary limit of physics engine realism is the precision of the numbers representing the position of an object and the forces acting on that object. When the precision is too low, errors can creep into the calculations due to rounding, causing an object to overshoot or undershoot the correct position. These errors are compounded in situations where two free-moving objects are fitted together with a precision that is greater than what the physics engine can calculate. This can lead to an unnatural buildup energy in the object due to the rounding errors, that begins to violently shake and eventually blow the objects apart. Any type of free-moving compound physics object can demonstrate this problem, but it is especially prone to affecting chain links under high tension, and wheeled objects with actively physical bearing surfaces. Higher precision reduces the positional/force errors, but at the cost of greater CPU power needed for the calculations.

Another unusual aspect of physics precision involves the framerate, or the number of moments in time per second when physics is calculated. Each frame is treated as separate from all other frames, and the space between frames is not calculated. A low framerate and a small fast-moving object leads to a situation where the object does not move smoothly through space but in fact seems to teleport from one point in space to the next point in space as each frame is calculated. At sufficiently high speeds a projectile will miss a target, if the target is small enough to fit in the gap between the calculated frames of the fast moving projectile. In Second Life this problem is resolved by making all projectiles as if they were arrows; a long invisible shaft trails behind the bullet so that as the bullet teleports forward, the shaft is long enough to cover the gap between successive teleports of the bullet and collide with any object that might fit between the calculated frames.

Physics-based character animation in the past only used rigid body dynamics because they are faster and easier to calculate, but modern games and movies are starting to use soft body physics now that it is possible. Soft body physics are also used for particle effects, liquids and cloth. Some form of limited Fluid dynamics simulation is sometimes provided to simulate water and other liquids as well as the flow of fire and explosions through the air.

Physics Processing Unit (PPU)

February 2006 saw the release of the first dedicated Physics Processing Unit (PPU) from Ageia (later merged into nVidia), called PhysX, which functions in a similar manner to the Graphic Processing Unit (GPU) in a graphics card - off-loading the majority of the physics processing weight off the CPU and into a dedicated processor. The unit was most effective in accelerating particle systems. Only a small performance improvement was measured for rigid body physics. [1] The Ageia PPU is documented in depth in their US patent application #20050075849. [2]

An early academic PPU research project named SPARTA (simulation of physics on a real-time architecture) was carried out at Penn State [3] and University of Georgia. This was a simple FPGA based PPU that was limited to two dimensions. This project was extended into a considerably more advanced ASIC-based system named HELLAS.

• Academic PPU research projects
• 
  Example SPARTA animation
• 
  SPARTA Printed circuit board
• 
  Hellas die photo

General Purpose processing on Graphics Processing Unit (GPGPU)

GPGPU ("General Purpose processing on Graphics Processing Unit") is another promising approach for realtime physics engines, including rigid body dynamics. ATI and NVIDIA provide rigid body dynamics on their latest graphics cards. ATI claims that their X1900 XT should deliver 9 times the performance of an nVidia PhysX card.

NVIDIA's GeForce 8 Series supports a new GPU-based Newtonian physics acceleration technology named Quantum Effects Technology - which will compete directly with the PhysX PPU hardware. NVIDIA provides an SDK Toolkit for what they call CUDA (Compute Unified Device Architecture) technology that offers both a low and high-level API to the GPU. Few technical details are available about the physics side of it, and it is not yet clear whether this is part of Havok FX SDK, and/or nVidia PhysX SDK, or a completely separate engine.

ATI & AMD offer a similar SDK for their ATI-based GPUs and that SDK and technology is called CTM (Close to Metal) which provides a thin hardware interface. AMD has also announced the AMD Stream Processor product line which combines a CPU and GPU technology on one chip.

Real-time physics engines

Open source

• Chipmunk
• Box2D
• Blaze
• Bullet
• motor2
• Open Dynamics Engine
• OPAL
• PAL
• SOFA (Simulation Open Framework Architecture)
• Tokamak physics engine
• Farseer Physics Engine - 2D physics engine for Microsoft XNA and Silverlight
• Physics2D.Net - 2D physics engine for the .NET Framework 2.0 or greater.

Public domain

• Phyz (Dax Phyz) - 2.5D physics simulator/editor.

Closed source/limited free distribution

• Newton Game Dynamics
• PhysX (formerly NovodeX and incorporating Meqon)
• Havok

Commercial

• Simul-X . A Havok or Physx add-on to enable advanced vehicle physics for PC , Xbox-360 and PS3.

High precision physics engines

• Working Model by Design Simulation Technologies

See also

• Game physics
• Ragdoll physics
• Procedural animation
• Rigid body dynamics
• Soft body dynamics
• Physics processing unit
• Cell microprocessor

Further reading

• Bourg, David M. (2002) Physics for Game Developers. O'Reilly & Associates.

External links

• DigitalRune Knowledge Base contains a comprehensive list of physics engines and rigid body dynamics resources (master thesis, links).
• Limitations of 3D Physics Engines: Unintended Explosion Google Video demonstration of calculation errors, in the virtual world Second Life.