Physics engine

Template:Needs Translation/de Template:Needs Translation/es Template:Needs Translation/el Template:Needs Translation/fr Template:Needs Translation/he Template:Needs Translation/it Template:Needs Translation/ja Template:Needs Translation/ko Template:Needs Translation/nl Template:Needs Translation/hu Template:Needs Translation/no Template:Needs Translation/da Template:Needs Translation/sv Template:Needs Translation/tr Template:Needs Translation/pl Template:Needs Translation/pt Template:Needs Translation/ru Template:Needs Translation/th Template:Needs Translation/uk Template:Needs Translation/zh-Hans Template:Needs Translation/zh-Hant

A physics engine is a program that simulates Newtonian object collisions and interactions in a mathematically and computationally simulated virtual environment. A physics engine is capable of simulating gravity, elasticity, and the conservation of momentum between colliding objects, but these features are not its core purpose in Second Life.

At its most basic level the physics engine is used in Second Life to determine empty space from filled space. Without the physics engine, an avatar in the 3D environment would simply move straight through anything in its path, and would fall through the ground and fall forever if gravity were applied to their avatar.

It is the physics engine that makes sure that the avatar walks up and down hills with the terrain, and that if there are stairways or walkways above the ground, the avatar can stand upon those structures with confidence of their solidity.

Havok and alternate engine options

Linden Lab initially chose to use the Havok1 engine to construct their first virtual environment. The Havok engine is a commercial product for which LL paid several hundred thousand dollars for the privilege to use in Second Life, and if at some point the simulator code were to become open source, Havok could not be freely included with the simulator.

While other free and open source physics engine are now available, the Second Life has so far been so deeply tied to Havok that substitution of a different engine is currently not possible. With the recent work towards upgrading from Havok1 to Havok4, some work has been done to create an abstraction layer between the simulator engine and the physics engine, so that at some point it may be possible to use other physics engines with the simulator.

Collision Geometry

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.

Second Life is somewhat unusual in this regard in that the actual shape of the primitive is also usually its collision geometry, and that when multiple primitives are linked together, they combine to form a very complex collision geometry. This means that Second Life geometry is highly precise compared to most games, but the high precision comes at a cost of comparatively slow collision processing.

Through prim torture it is possible to create complex overlapping collision geometries which collide with themselves or to create inverted geometries. Such objects have been used in the past with Havok1 for griefing purposes to cause intentional simulator slowdowns, but the geometry processing has been revised under Havok4 so as to no longer have these problems.

As part of the new Havok4 engine, spheres now use a mathematically precise spherical geometry that is faster to calculate than the complex multifaceted surface of a rough sphere. This both increases the engine speed, and also helps to eliminate past annoyances with slow-moving spheres that stop rolling because they are insufficiently smooth.

CPU conservation

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

Under Havok1, this conservation was so extreme that if a physical object was placed on top of another, and the physical object stopped moving, the object underneath could be removed without the physical object "waking up". This results in odd situations where physics objects would become permanently fixed in midair until directly pushed or touched. Havok4 now handles this situation better, so that removing the supporting object wakes up the physical object and it correctly falls to the ground.

Math precision and simulation speed

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.

Framerate vs Moving-Object Speed

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.

External References

• Limitations of 3D Physics Engines: Unintended Explosion Google Video demonstration of calculation errors, in a Second Life island sandbox.