Jump to content

Physics engine: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Drewnoakes (talk | contribs)
Line 42: Line 42:


==== Paradigms ====
==== Paradigms ====
Physics engines for video games typically have two core components, a [[collision detection]]/[[collision response]] system, and the [[Dynamical simulation|dynamics simulation]] component responsible for solving the forces affecting the simulated objects. Modern physics engines may also contain [[Computational fluid dynamics|fluid simulations]], animation [[Motion control|control systems]] and [[COLLADA|asset integration]]tools. There are three major paradigms for the physical simulation of solids:
Physics engines for video games typically have two core components, a [[collision detection]]/[[collision response]] system, and the [[Dynamical simulation|dynamics simulation]] component responsible for solving the forces affecting the simulated objects. Modern physics engines may also contain [[Computational fluid dynamics|fluid simulations]], animation [[Motion control|control systems]] and [[COLLADA|asset integration]] tools. There are three major paradigms for the physical simulation of solids:
* Penalty methods, where interactions are commonly modelled as [[Soft body dynamics#Mass-spring models|mass-spring]] systems. This type of engine is popular for deformable, or [[Soft body dynamics|soft-body physics]].
* Penalty methods, where interactions are commonly modelled as [[Soft body dynamics#Mass-spring models|mass-spring]] systems. This type of engine is popular for deformable, or [[Soft body dynamics|soft-body physics]].
* Constraint based methods, where [[Constraint (mathematics)|constraint equations]] are solved that estimate physical laws.
* Constraint based methods, where [[Constraint (mathematics)|constraint equations]] are solved that estimate physical laws.

Revision as of 18:28, 10 December 2010

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:
  1. No physics.
  2. Gravity, no collision detection.
  3. Gravity and collision detection, no rotation calculations.
  4. Gravity, collision detection and rotation calculations.

A physics engine is computer software that provides an approximate simulation of certain simple physical systems, such as rigid body dynamics (including collision detection), soft body dynamics, and fluid dynamics, of use in the domains of computer graphics, video games and film. Their main uses are in video games (typically as middleware), in which case the simulations are in real-time. The term is sometimes used more generally to describe any software system for simulating physical phenomena, such as high-performance scientific simulation.

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. Real-time physics engines—as used in video games and other forms of interactive computing—use simplified calculations and decreased accuracy to compute in time for the game to respond at an appropriate rate for gameplay.

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 perform computational fluid dynamics modeling, where particles are assigned force vectors that are combined to show circulation. Due to the requirements of speed and high precision, special computer processors known as vector processors were developed to accelerate the calculations. The techniques can be used to model weather patterns in weather forecasting, wind tunnel data for designing air- and watercraft, and thermal cooling of computer processors for improving heat sinks. As with many calculation-laden processes in computing, the accuracy of the simulation is related to the resolution of the simulation and the precision of the calculations; small fluctuations not modeled in the simulation can drastically change the predicted results.

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.

Game engines

In most computer games, speed of simulation is more important than accuracy of simulation. This leads to designs for physics engines that produce results in near real-time but that do not completely replicate real world physics.

Collision detection

Objects in games interact with the player, the environment, and each other. Typically, most 3D objects in games are represented by two separate meshes or shapes. One of these meshes is the highly complex and detailed shape visible to the player in the game, such as a vase with elegant curved and looping handles. For purpose of speed, a second, simplified invisible mesh is used to represent the object to the physics engine so that the physics engine treats the example vase as a simple cylinder. It would thus be impossible to insert a rod or fire a projectile through the handle holes on the vase, because the physics engine models based on the cylinder and is unaware of the handles. 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.

An alternative to using bounding box-based rigid body physics systems is to use a finite element-based system. In such a system, a 3-dimensional, volumetric tessellation is created of the 3D object. The tessellation results in a number of finite elements which represent aspects of the object's physical properties such as toughness, plasticity, and volume preservation. Once constructed, the finite elements are used by a solver to model the stress within the 3D object. The stress can be used to drive fracture, deformation and other physical effects with a high degree of realism and uniqueness. As the number of modeled elements is increased, the engine's ability to model physical behavior increases. The visual representation of the 3D object is altered by the finite element system through the use of a deformation shader run on the CPU or GPU. Finite Element-based systems had been impractical for use in games due to the performance overhead and the lack of tools to create finite element representations out of 3D art objects. With higher performance processors and tools to rapidly create the volumetric tessellations, real-time finite element systems began to be used in games, beginning with Star Wars: The Force Unleashed that used Digital Molecular Matter for the deformation and destruction effects of wood, steel, flesh and plants using an algorithm developed by Dr. James O'Brien as a part of his PhD thesis.[1]

Another unusual aspect of precision in discrete collision detection 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 causes a situation where the object does not move smoothly through space but instead seems to teleport from one point in space to the next as each frame is calculated. Projectiles moving at sufficiently high speeds will miss targets, if the target is small enough to fit in the gap between the calculated frames of the fast moving projectile. Various techniques are used to overcome this flaw, such as Second Life's representation of projectiles as arrows with invisible trailing tails longer than the gap in frames to collide with any object that might fit between the calculated frames. By contrast, continuous collision detection such as in Bullet or Havok does not suffer this problem.

Brownian motion

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 unnecessarily wasting the limited CPU power, which can cause problems such as decreased framerate. Thus, games may put objects to "sleep" by disabling the computation of physics on objects that have not moved a particular distance within a certain amount of time. For example, in the 3D virtual world Second Life, if an object is resting on the floor and the object does not move beyond a minimal distance in about two seconds, then the physics calculations are disabled for the object and it becomes frozen in place. The object remains frozen until physics processing reactivates for the object after collision occurs with some other actively physical object.[2]

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

Paradigms

Physics engines for video games typically have two core components, a collision detection/collision response 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 modelled 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.

Limitations

A primary limit of physics engine realism is the precision of the numbers representing the positions of and forces acting upon objects. When precision is too low, rounding errors affect results and small fluctuations not modeled in the simulation can drastically change the predicted results; simulated objects can behave unexpectedly or arrive at the wrong location. The errors are compounded in situations where two free-moving objects are fit 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.

Physics Processing Unit (PPU)

A Physics Processing Unit (PPU) handles the majority of physics processing instead of the CPU, similar to how a Graphic Processing Unit (GPU) performs most of the graphics calculations. An early academic PPU research project[3][4] named SPARTA (Simulation of Physics on A Real-Time Architecture) was carried out at Penn State[5] 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. February 2006 saw the release of the first dedicated PPU PhysX from Ageia (later merged into nVidia). The unit is most effective in accelerating particle systems, with only a small performance improvement measured for rigid body physics.[6] The Ageia PPU is documented in depth in their US patent application #20050075849.[7]

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. With this approach, the GPU supports some physics processing.

ATI and NVIDIA provide rigid body dynamics on their latest graphics cards. NVIDIA's GeForce 8 Series supports a 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.[8] 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 Fusion product line which combines a CPU and GPU technology on one chip.

Engines

Real-time physics engines

Template:Multicol

Open source

Template:Multicol-break

Public domain
  • Phyz (Dax Phyz) - 2.5D physics simulator/editor.
Closed source/limited free distribution

Template:Multicol-end

High precision physics engines

  • VisSim - Visual Simulation engine for linear and nonlinear dynamics
  • Working Model by Design Simulation Technologies

See also

Further reading

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

References

  1. ^ "Graphical Modeling and Animation of Brittle Fracture"
  2. ^ "Doc:Manual/Game Engine/Logic/Object type/Rigid body - BlenderWiki". Wiki.blender.org. 2009-11-20. Retrieved 2010-08-16.
  3. ^ S. Yardi, B. Bishop, T. Kelliher, "HELLAS: A Specialized Architecture for Interactive Deformable Object Modeling", ACM Southeast Conference, Melbourne, FL, March 10–12, 2006, pp. 56–61.
  4. ^ B. Bishop, T. Kelliher, "Specialized Hardware for Deformable Object Modeling," IEEE Transactions on Circuits and Systems for Video Technology, 13(11):1074–1079, Nov. 2003.
  5. ^ "SPARTA Homepage". Cse.psu.edu. Retrieved 2010-08-16.
  6. ^ "Exclusive: ASUS Debuts AGEIA PhysX Hardware". AnandTech. Retrieved 2010-08-16.
  7. ^ "United States Patent Application: 0050086040". Appft1.uspto.gov. Retrieved 2010-08-16.
  8. ^ "NVIDIA 8800 features page - Quantum Effects Technology". Nvidia.com. Retrieved 2010-08-16.