Physics - Revision history

MakoBot: Robot: Cosmetic changes

2012-03-04T03:54:40Z

Robot: Cosmetic changes

MakoBot: Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

2011-06-10T23:33:30Z

Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

Dale Mahalko: what collision geometry is, how modern game engines make use of it, and how Second Life doesn't. OpenSim could allow it.

2010-04-04T09:37:34Z

what collision geometry is, how modern game engines make use of it, and how Second Life doesn't. OpenSim could allow it.

Dale Mahalko: the problem of holes, gaps, slots, tortured prims, and linksets in causing physics engine lag and dragging sims to a standstill

2010-04-04T09:20:15Z

the problem of holes, gaps, slots, tortured prims, and linksets in causing physics engine lag and dragging sims to a standstill

Dale Mahalko: more about how collisions work. objects causing continuous high resolver load can be defensively turned phantom by some physics engines

2010-04-04T08:50:00Z

more about how collisions work. objects causing continuous high resolver load can be defensively turned phantom by some physics engines

Dale Mahalko: Flesh out this important but empty article: OpenSim resolves against the ground only by default. Role of physics engine vs simulator db engine. Importance of gravity and the surface patch in realism.

2010-04-04T08:34:08Z

Flesh out this important but empty article: OpenSim resolves against the ground only by default. Role of physics engine vs simulator db engine. Importance of gravity and the surface patch in realism.

Ideia Boa at 00:06, 22 May 2009

2009-05-22T00:06:37Z

Klyick: Removing all content from page

2008-01-16T03:53:22Z

Removing all content from page

Krisbfunk at 17:45, 15 January 2008

2008-01-15T17:45:59Z

Teravus: /* Physics / Collision */

2008-01-15T14:17:12Z

‎Physics / Collision

@@ Line 15: / Line 15: @@
 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.
+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.

@@ Line 1: / Line 1: @@
 __NOTOC__
-{{Template:Quicklinks}}
+{{Quicklinks}}
 <br />
 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]].

← Older revision		Revision as of 09:37, 4 April 2010
Line 43:		Line 43:

	Free open source engines may not provide the same collision resolving features as the commercial Havok engine.		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.

← Older revision		Revision as of 09:20, 4 April 2010
Line 28:		Line 28:

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

@@ Line 13: / Line 13: @@
 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.
 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.

← Older revision		Revision as of 08:34, 4 April 2010
Line 2:		Line 2:
	{{Template:Quicklinks}}		{{Template:Quicklinks}}
	<br />		<br />
		+	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.
		+
		+	== Gravity and the ground ==
		+	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.
		+
		+	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.

← Older revision	Revision as of 00:06, 22 May 2009
Line 1:	Line 1:
−	+	__NOTOC__
	+	{{Template:Quicklinks}}
	+	<br />

@@ Line 1: / Line 1: @@
-== Physics / Collision ==
-<table border="1" cellpadding="5" cellspacing="0">
-  <tr>
-    <th width="150">&nbsp;</th>
-    <th width="150">basicphysics</th>
-    <th width="150">POS</th>
-    <th width="150">OpenDynamicsEngine</th>
-    <th width="150">modified_BulletX</th>
-    <th width="150">RealPhysX</th>
-  </tr>
-  <tr>
-    <td>walk on ground</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="yellow">partially working (ground is very slippery)</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>fly</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>sit on ground</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="red">not working</td>
-  </tr>
-  <tr>
-    <td>sit on object</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="yellow">partially working (autopilot has trouble getting to the right spot 'try phantom prim')</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>walk on object</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>bump into object</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>Avatar Land on Prim</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>prim physics</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="red">not working</td>
-    <td bgcolor="lime">OK</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-  <tr>
-    <td>cut/hollow/dimpled prim (non)collisions</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-    <td bgcolor="grey">unknown</td>
-  </tr>
-</table>
-[[Category:Development]]

← Older revision		Revision as of 17:45, 15 January 2008
Line 82:		Line 82:
	</tr>		</tr>
	</table>		</table>
		+	[[Category:Development]]