Physics engine: Difference between revisions
→High precision physics engines: Added AgX to list of high precision engines. |
→Closed source/limited free distribution: Added Phun to list. |
||
Line 87: | Line 87: | ||
*[http://trueaxis.com/ True Axis] |
*[http://trueaxis.com/ True Axis] |
||
*[[PhysX]] (formerly NovodeX and incorporating [[Meqon]]) |
*[[PhysX]] (formerly NovodeX and incorporating [[Meqon]]) |
||
*[http://phun.at Phun] |
|||
==== Commercial ==== |
==== Commercial ==== |
Revision as of 09:36, 2 May 2008
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 (or dynamic simulations) 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 will have to simplify its calculations and lower their 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 actual physics simulation component responsible for solving the forces affecting the simulated objects. There are three major paradigms for physics simulation:
- 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 1980's 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, 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[1][2] 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, with ATI claims X1900 XT should deliver 9 X the performance of an Ageia 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 AGEIA PhysX SDK, or a completely separate engine.[3]
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.
See also
- Game physics
- Ragdoll physics
- Procedural animation
- Rigid body dynamics
- Soft body dynamics
- List of physics-based computer and video games
- Physics processing unit
- Cell microprocessor
Real-time physics engines
Open source
- Box2D
- Bullet
- Chipmunk
- JigLib
- Open Dynamics Engine
- OPAL
- OpenTissue
- PAL
- Tokamak physics engine
- Farseer Physics Engine - 2D physics engine for Microsoft XNA and Silverlight
- Physics2D.Net A 2 dimensional rigid body physics engine written in C#. That can be used with any Renderer including XNA, OpenGL, and SilverLight.
- Glaze
- Blaze A 2D game dyamics engine written in the D programming language.
Closed source/limited free distribution
- Newton Game Dynamics
- Simple Physics Engine
- True Axis
- PhysX (formerly NovodeX and incorporating Meqon)
- Phun
Commercial
- Havok
- nV Physics SDK
- Vortex from CMLabs Simulations
- Agx Multiphysics from Algoryx Simulation
High precision physics engines
- Agx Multiphysics from Algoryx Simulation
- Mechanica from Parametric Technologies Corporation.
- Working Model, from Design Simulation Technologies. (2D only)
- Falling Bodies, from Animats. (Ragdoll physics)
Further reading
- Bourg, David M. (2002) Physics for Game Developers. O'Reilly & Associates.
External links
- Chris Hecker's "Rigid Body Dynamics" tutorial
- Adrian Boeing's physics engine list
- Open Dynamics Engine
- PhysicsAndMathLibrary This library is royalty-free for hobby use and an inexpensive alternative for commercial developers.
- Newton Game Dynamics Newton is a free physics engine for commercial and hobby use, supports multiple platforms, SDK is contained as well.
- PGNX Physics, a versatile physics engine with haptic capabilities
- Bullet Physics Library Open Source, free for commercial use collision detection and rigid body dynamics library.
- True Axis Physics SDK
- 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.
Racing physics:
- FastCar Library
- Atlas F1 technical forum
- Racer Free Car Simulation Physics
- Racing Physics and Maths forums at rscnet.org
References
- ^ 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.
- ^ 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.
- ^ NVIDIA 8800 features page - Quantum Effects Technology