Physics
From OpenSimulator
 |
Languages: |
|
By default, Open Simulator uses an extremely simple physics engine which only allows you to stand on the ground. All objects using the basic physics engine appear to be phantom, and the only way to make them act as solids is to use some other more sophisticated physics engine, such as the Open Dynamics Engine.
Note that physics processing is one of the biggest sources of region simulator lag. If you use a better engine to make objects appear to be solid, you will most likely want to isolate the region simulator and physics engine on its own physical hardware so that lag in the physics engine does not also slow down your asset and inventory servers.
The role of the physics engine
One of the primary functions of the simulator is to provide an experience that approximates real life. This typically requires making the objects in the 3D world appear to be solid and real.
As far as the simulator database engine is concerned, it simply knows the positions of objects in the simulated 3D space and knows the references to textures for each surface of the objects. The database engine does not know anything about gravity, pushes, or collisions.
It is technically possible to connect to a simulator without a physics engine, but the avatars would appear to float in space without gravity and can pass through any object including other avatars, and move in any direction to the coordinate limits of the simulated space.
The primary task of the physics engine is to move objects affected by forces and to resolve collisions. Collisions occur when two physical objects collide or are simply touching each other.
Most objects in the simulator are pinned in space and do not move. They do not normally require any physics processing time. However, when a physical moving object collides with a pinned object, the pinned object is temporarily treated as if it were physical and collisions are calculated against it. Since it cannot move, the only resolving forces are applied to the movable object.
In certain unresolvable situations (described below) a physical moving object causing continuous high simulator load may be defensively changed by the simulator into a nonphysical or phantom object, so that the simulator does not become stuck in a continuous high-load state.
Gravity and the ground
The single biggest force in the simulator is gravity, which causes physical objects to move downward (Z axis in the 3D coordinate system), typically following Earth-based experience of accelerating to a terminal falling velocity of 9.81 meters per second.
There is also a deformable plane surface in each sim which is the lowest point any object can descend. We call this the ground or the surface patch. If the ground did not exist, physical objects in the simulator would simply fall to the lowest possible Z axis coordinate value of zero and simply stop, apparantly suspended above/in nothingness. This is outside our normal experience so we have the ground in the simulator to make the simulated world seem more like real life.
When objects affected by gravity collide with the ground in the simulator, the physics engine resolves the collision by pushing back on the colliding object, causing it to rise up out of the ground against the force of gravity. If the forces are treated as springs, and the object is elastic while the ground is hard and resilient, the simulator can apply an opposite upward force equal to the downward force to cause a fast moving object to "bounce" upward again.
As mentioned above, the default basic physics engine included with Open Simulator only resolves collisions with the ground, and makes no attempt to make object primitives appear to be solid. As a result, a basic install of Open Simulator will tend to have a mostly flat world layout following the ground surface because that is the only place where people can walk around in a realistic looking manner. Walking around in the second floor of a house made from primitives suspended in midair above the ground for example is not possible.
Holes, gaps, and simulator lag
The most basic form of collision resolving involves two objects which are overlapping, due to forces having caused them to move towards each other in previous calculation phases. Once the objects are overlapping, the goal of the physics engine is to apply forces so that the objects move in such a manner that they no longer overlap.
For two simple solid objects this involves merely pushing the objects apart so that they are further away from each other.
But the collision resolving task is much harder if there are holes in one object or the other. Rather than merely pushing the objects apart, the ideal goal would be to push the objects towards the open spaces within each other. This is where the math becomes incredibly difficult for complex or tortured primitives, and even for certain simple objects such as hollow spheres.
Due to the linking of objects in a simulator, and linked sets of objects being allowed to become physical, even simple linked objects made from non-hollow primitives may combine to form 3D shapes that contain holes and interior spaces that are difficult or impossible for the physics engine to resolve.
In the past, the early Second Life simulators using the Havok 1.0 physics engine were often attacked by lag-causing objects with collisions that could not be resolved. A large number of these objects would cause a simulator to drag to a standstill.
The upgraded Havok 4.0 engine in Second Life will attempt to work with holes in objects at first, but if the collisions can not be resolved in a reasonably short amount of time, the engine will revert to treating the objects as solid and cause the objects to separate until they do not touch. The Havok 4.0 engine goes further if that does not work, and will render one or more objects phantom to stop the objects from causing further unresolvable physics engine lag.
Free open source engines may not provide the same collision resolving features as the commercial Havok engine.
Collision geometry
In most modern game engines, physical objects are often constructed from two very different shapes. There is the visible shape of an object which may be very complex and detailed. And there is a second invisible shape that is often very simple, used by the physics engine to calculate collisions. This allows the physics engine to conserve processing power while still making the 3D environment appear complex and detailed.
Second Life in its current form does not allow content creators to make use of collision geometry separate from primitives. Instead the exact shape of the primitive or linkset is always its collision geometry, which leads to unnecessary complexity in the physics processing.
Open Simulator tends to follow the standards originally set by Second Life. While Open Simulator could allow for the use of separate simple collision geometry for complex objects, it would do so against the standards of Second Life, and the collision geometry would not be usable when an avatar and its objects move directly from an Open Simulator grid to the Second Life grid.
