Jump to content

Physics engine

From Wikipedia, the free encyclopedia
(Redirected from Physics engines)
Physics engine

A physics engine is computer software that provides an approximate simulation of certain 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 (CGI). 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

[edit]

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 game play. A physics engine is essentially a big calculator that does mathematics needed to simulate physics.[1]

Scientific engines

[edit]

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 or motor vehicles including racecars, 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

[edit]
Main articles: Game engine and Game physics

In most computer games, speed of the processors and gameplay are more important than accuracy of simulation. This leads to designs for physics engines that produce results in real-time but that replicate real world physics only for simple cases and typically with some approximation. More often than not, the simulation is geared towards providing a "perceptually correct" approximation rather than a real simulation. However some game engines, such as Source, use physics in puzzles or in combat situations. This requires more accurate physics so that, for example, the momentum of an object can knock over an obstacle or lift a sinking object.

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

Collision detection

[edit]
Main article: 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 model is 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.

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

Soft-body dynamics

[edit]

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.[2]

Brownian motion

[edit]

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 active physical object.[3]

Paradigms

[edit]

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:[4]

  • 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

[edit]

A primary limit of physics engine realism is the approximated result of the constraint resolutions and collision result due to the slow convergence of algorithms. Collision detection computed at a too low frequency can result in objects passing through each other and then being repelled with an abnormal correction force. On the other hand, approximated results of reaction force is due to the slow convergence of typical Projected Gauss Seidel solver resulting in abnormal bouncing. 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 needing greater CPU power for the calculations.

Physics processing unit (PPU)

[edit]
Main article: Physics processing unit

A physics processing unit (PPU) is a dedicated microprocessor designed to handle the calculations of physics, especially in the physics engine of video games. Examples of calculations involving a PPU might include rigid body dynamics, soft body dynamics, collision detection, fluid dynamics, hair and clothing simulation, finite element analysis, and fracturing of objects. The idea is that specialized processors offload time-consuming tasks from a computer's CPU, much like how a GPU performs graphics operations in the main CPU's place. The term was coined by Ageia's marketing to describe their PhysX chip to consumers. Several other technologies in the CPU-GPU spectrum have some features in common with it, although Ageia's solution was the only complete one designed, marketed, supported, and placed within a system exclusively as a PPU.

General-purpose computing on graphics processing unit (GPGPU)

[edit]
Main article: General-purpose computing on graphics processing units

Hardware acceleration for physics processing is now usually provided by graphics processing units that support more general computation, a concept known as general-purpose computing on graphics processing units (GPGPU). AMD and NVIDIA provide support for rigid body dynamics computations on their latest graphics cards.

NVIDIA's GeForce 8 series supports a GPU-based Newtonian physics acceleration technology named Quantum Effects Technology. NVIDIA provides an SDK Toolkit for CUDA (Compute Unified Device Architecture) technology that offers both a low and high-level API to the GPU.[5] For their GPUs, AMD offers a similar SDK, called Close to Metal (CTM), which provides a thin hardware interface.

PhysX is an example of a physics engine that can use GPGPU based hardware acceleration when it is available.

Engines

[edit]

Real-time physics engines

[edit]

High precision physics engines

[edit]
  • VisSim - Visual Simulation engine for linear and nonlinear dynamics

See also

[edit]

References

[edit]
  1. ^ Millington, Ian (2007-03-07). Game Physics Engine Development. CRC Press. ISBN 978-1-4822-6732-7.
  2. ^ "Graphical Modeling and Animation of Brittle Fracture". Graphics.eecs.berkeley.edu. Retrieved 2012-09-01.
  3. ^ "Doc:Manual/Game Engine/Logic/Object type/Rigid body - BlenderWiki". Wiki.blender.org. 2009-11-20. Archived from the original on 2011-10-01. Retrieved 2010-08-16.
  4. ^ Erleben, Kenny; Sporring, Jon; Henriksen, Knud; Dohlmann, Henrik (2005). Physics-Based Animation.
  5. ^ "NVIDIA 8800 features page - Quantum Effects Technology". Nvidia.com. Retrieved 2010-08-16.
  6. ^ Jolt Physics GitHub Repository

Further reading

[edit]
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Physics_engine&oldid=1211311129"