BulletSim upgrade and fixes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

BulletSim upgrade and fixes

Mister Blue
An update to BulletSim has been checked into the OpenSimulator that
upgrades BulletSim with version 2.86 of the Bullet physics engine
<http://bulletphysics.org/> as well as fixing some known problems.

Mantis 8010 <http://opensimulator.org/mantis/view.php?id=8010> (“BulletSim
does not always call collision events on collisions”) was caused by
BulletSim not doing collision detection on all of the physics engine
sub-steps. This meant that fast moving objects (like bullets) could bounce
off of a target without reporting any collisions. For those into details,
any OpenSimulator <http://opensimulator.org/> physics engine is called
every tenth of a second to simulate the next tenth of a second of time.
BulletSim internally steps 10 times within that tenth of a second to do a
higher resolution physics simulation – a tenth of a second is a long
simulation step but that’s the way OpenSimulator
<http://opensimulator.org/> does
it.

Mantis 8011 <http://opensimulator.org/mantis/view.php?id=8011> (“BulletSim
fails to send land_collision messages on some terrain”) was caused by
BulletSim computing terrain height differently than the mesh in the physics
engine. So, an object on steep terrain could compute as underground to some
code while appearing above ground in other code. BulletSim prevents
physical objects from going underground by pushing them up when the do.
This check would sometimes cause a falling object to float over terrain
rather than colliding with the terrain.

The problem in Mantis 7132
<http://opensimulator.org/mantis/view.php?id=7132> (“Collisions stop for no
apparent reason on BulletSim”) hasn’t been explicitly fixed. Still looking
for that problem.

I found an additional problem that collision_end events don’t happen if the
colliding object does an llDie() on its collision. For instance, a target
object wouldn’t get a collision_end event for a bullet object that hits the
target and does an llDie() on its collision. It looks like the ODE and
ubODE physics engines don’t exhibit this problem because of the order that
collisions are reported to the simulator. The fix is some code
re-organization in SceneObjectPart.cs.

Still in the pipeline is the proper implementation of PhysicsShapeType and
then physics engine implementation of raycast.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: BulletSim upgrade and fixes

Mike Lorrey
I have found an interesting bug in Kitely with Bullet: when you torture a
prim, or scale a prim, that has hollow spaces, even a mesh with hollow
spaces, the object defaults to its non-hollow/non-cut collision mesh, UNTIL
region restart, whereupon the simulator seems to recalculate the collision
mesh accounting for any hollows/cuts/empty spaces in mesh.
There is also some difficulty in making doors/passages easy to go through
in mesh with Bullet, it often requires adding a number of rows of faces
inside the edge of the opening to make the physics engine recognise that
there is an opening there that avatars and other objects can pass through
without collisions.

On Tue, Aug 15, 2017 at 1:37 PM, Mister Blue <[hidden email]>
wrote:

> An update to BulletSim has been checked into the OpenSimulator that
> upgrades BulletSim with version 2.86 of the Bullet physics engine
> <http://bulletphysics.org/> as well as fixing some known problems.
>
> Mantis 8010 <http://opensimulator.org/mantis/view.php?id=8010> (“BulletSim
> does not always call collision events on collisions”) was caused by
> BulletSim not doing collision detection on all of the physics engine
> sub-steps. This meant that fast moving objects (like bullets) could bounce
> off of a target without reporting any collisions. For those into details,
> any OpenSimulator <http://opensimulator.org/> physics engine is called
> every tenth of a second to simulate the next tenth of a second of time.
> BulletSim internally steps 10 times within that tenth of a second to do a
> higher resolution physics simulation – a tenth of a second is a long
> simulation step but that’s the way OpenSimulator
> <http://opensimulator.org/> does
> it.
>
> Mantis 8011 <http://opensimulator.org/mantis/view.php?id=8011> (“BulletSim
> fails to send land_collision messages on some terrain”) was caused by
> BulletSim computing terrain height differently than the mesh in the physics
> engine. So, an object on steep terrain could compute as underground to some
> code while appearing above ground in other code. BulletSim prevents
> physical objects from going underground by pushing them up when the do.
> This check would sometimes cause a falling object to float over terrain
> rather than colliding with the terrain.
>
> The problem in Mantis 7132
> <http://opensimulator.org/mantis/view.php?id=7132> (“Collisions stop for
> no
> apparent reason on BulletSim”) hasn’t been explicitly fixed. Still looking
> for that problem.
>
> I found an additional problem that collision_end events don’t happen if the
> colliding object does an llDie() on its collision. For instance, a target
> object wouldn’t get a collision_end event for a bullet object that hits the
> target and does an llDie() on its collision. It looks like the ODE and
> ubODE physics engines don’t exhibit this problem because of the order that
> collisions are reported to the simulator. The fix is some code
> re-organization in SceneObjectPart.cs.
>
> Still in the pipeline is the proper implementation of PhysicsShapeType and
> then physics engine implementation of raycast.
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>



--
Mike Lorrey
CEO Galactic Systems, Inc
VP Stokens Venture Capital
[hidden email] <[hidden email]>
[hidden email]
International Spaceflight Museum
[hidden email]
Skype: michael.lorrey
LinkedIn: https://www.linkedin.com/in/mikelorrey
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: BulletSim upgrade and fixes

Mister Blue
It sounds like it is not noticing the changes in the prim parameters to
recalculate the prim mesh. I'll look into that.

On Tue, Aug 15, 2017 at 11:20 AM, Mike Lorrey <[hidden email]> wrote:

> I have found an interesting bug in Kitely with Bullet: when you torture a
> prim, or scale a prim, that has hollow spaces, even a mesh with hollow
> spaces, the object defaults to its non-hollow/non-cut collision mesh, UNTIL
> region restart, whereupon the simulator seems to recalculate the collision
> mesh accounting for any hollows/cuts/empty spaces in mesh.
> There is also some difficulty in making doors/passages easy to go through
> in mesh with Bullet, it often requires adding a number of rows of faces
> inside the edge of the opening to make the physics engine recognise that
> there is an opening there that avatars and other objects can pass through
> without collisions.
>
> On Tue, Aug 15, 2017 at 1:37 PM, Mister Blue <[hidden email]>
> wrote:
>
> > An update to BulletSim has been checked into the OpenSimulator that
> > upgrades BulletSim with version 2.86 of the Bullet physics engine
> > <http://bulletphysics.org/> as well as fixing some known problems.
> >
> > Mantis 8010 <http://opensimulator.org/mantis/view.php?id=8010>
> (“BulletSim
> > does not always call collision events on collisions”) was caused by
> > BulletSim not doing collision detection on all of the physics engine
> > sub-steps. This meant that fast moving objects (like bullets) could
> bounce
> > off of a target without reporting any collisions. For those into details,
> > any OpenSimulator <http://opensimulator.org/> physics engine is called
> > every tenth of a second to simulate the next tenth of a second of time.
> > BulletSim internally steps 10 times within that tenth of a second to do a
> > higher resolution physics simulation – a tenth of a second is a long
> > simulation step but that’s the way OpenSimulator
> > <http://opensimulator.org/> does
> > it.
> >
> > Mantis 8011 <http://opensimulator.org/mantis/view.php?id=8011>
> (“BulletSim
> > fails to send land_collision messages on some terrain”) was caused by
> > BulletSim computing terrain height differently than the mesh in the
> physics
> > engine. So, an object on steep terrain could compute as underground to
> some
> > code while appearing above ground in other code. BulletSim prevents
> > physical objects from going underground by pushing them up when the do.
> > This check would sometimes cause a falling object to float over terrain
> > rather than colliding with the terrain.
> >
> > The problem in Mantis 7132
> > <http://opensimulator.org/mantis/view.php?id=7132> (“Collisions stop for
> > no
> > apparent reason on BulletSim”) hasn’t been explicitly fixed. Still
> looking
> > for that problem.
> >
> > I found an additional problem that collision_end events don’t happen if
> the
> > colliding object does an llDie() on its collision. For instance, a target
> > object wouldn’t get a collision_end event for a bullet object that hits
> the
> > target and does an llDie() on its collision. It looks like the ODE and
> > ubODE physics engines don’t exhibit this problem because of the order
> that
> > collisions are reported to the simulator. The fix is some code
> > re-organization in SceneObjectPart.cs.
> >
> > Still in the pipeline is the proper implementation of PhysicsShapeType
> and
> > then physics engine implementation of raycast.
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
>
>
>
> --
> Mike Lorrey
> CEO Galactic Systems, Inc
> VP Stokens Venture Capital
> [hidden email] <[hidden email]>
> [hidden email]
> International Spaceflight Museum
> [hidden email]
> Skype: michael.lorrey
> LinkedIn: https://www.linkedin.com/in/mikelorrey
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: BulletSim upgrade and fixes

Mike Lorrey
Thanks, this only seems to be a problem for 0.8.1.2 in Kitely. It doesn't
exist on other grids of the same OS version, and Kitely insists they are
using vanilla Bullet for this version.


On Tue, Aug 15, 2017 at 2:53 PM, Mister Blue <[hidden email]>
wrote:

> It sounds like it is not noticing the changes in the prim parameters to
> recalculate the prim mesh. I'll look into that.
>
> On Tue, Aug 15, 2017 at 11:20 AM, Mike Lorrey <[hidden email]>
> wrote:
>
> > I have found an interesting bug in Kitely with Bullet: when you torture a
> > prim, or scale a prim, that has hollow spaces, even a mesh with hollow
> > spaces, the object defaults to its non-hollow/non-cut collision mesh,
> UNTIL
> > region restart, whereupon the simulator seems to recalculate the
> collision
> > mesh accounting for any hollows/cuts/empty spaces in mesh.
> > There is also some difficulty in making doors/passages easy to go through
> > in mesh with Bullet, it often requires adding a number of rows of faces
> > inside the edge of the opening to make the physics engine recognise that
> > there is an opening there that avatars and other objects can pass through
> > without collisions.
> >
> > On Tue, Aug 15, 2017 at 1:37 PM, Mister Blue <[hidden email]>
> > wrote:
> >
> > > An update to BulletSim has been checked into the OpenSimulator that
> > > upgrades BulletSim with version 2.86 of the Bullet physics engine
> > > <http://bulletphysics.org/> as well as fixing some known problems.
> > >
> > > Mantis 8010 <http://opensimulator.org/mantis/view.php?id=8010>
> > (“BulletSim
> > > does not always call collision events on collisions”) was caused by
> > > BulletSim not doing collision detection on all of the physics engine
> > > sub-steps. This meant that fast moving objects (like bullets) could
> > bounce
> > > off of a target without reporting any collisions. For those into
> details,
> > > any OpenSimulator <http://opensimulator.org/> physics engine is called
> > > every tenth of a second to simulate the next tenth of a second of time.
> > > BulletSim internally steps 10 times within that tenth of a second to
> do a
> > > higher resolution physics simulation – a tenth of a second is a long
> > > simulation step but that’s the way OpenSimulator
> > > <http://opensimulator.org/> does
> > > it.
> > >
> > > Mantis 8011 <http://opensimulator.org/mantis/view.php?id=8011>
> > (“BulletSim
> > > fails to send land_collision messages on some terrain”) was caused by
> > > BulletSim computing terrain height differently than the mesh in the
> > physics
> > > engine. So, an object on steep terrain could compute as underground to
> > some
> > > code while appearing above ground in other code. BulletSim prevents
> > > physical objects from going underground by pushing them up when the do.
> > > This check would sometimes cause a falling object to float over terrain
> > > rather than colliding with the terrain.
> > >
> > > The problem in Mantis 7132
> > > <http://opensimulator.org/mantis/view.php?id=7132> (“Collisions stop
> for
> > > no
> > > apparent reason on BulletSim”) hasn’t been explicitly fixed. Still
> > looking
> > > for that problem.
> > >
> > > I found an additional problem that collision_end events don’t happen if
> > the
> > > colliding object does an llDie() on its collision. For instance, a
> target
> > > object wouldn’t get a collision_end event for a bullet object that hits
> > the
> > > target and does an llDie() on its collision. It looks like the ODE and
> > > ubODE physics engines don’t exhibit this problem because of the order
> > that
> > > collisions are reported to the simulator. The fix is some code
> > > re-organization in SceneObjectPart.cs.
> > >
> > > Still in the pipeline is the proper implementation of PhysicsShapeType
> > and
> > > then physics engine implementation of raycast.
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > [hidden email]
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> > >
> >
> >
> >
> > --
> > Mike Lorrey
> > CEO Galactic Systems, Inc
> > VP Stokens Venture Capital
> > [hidden email] <[hidden email]>
> > [hidden email]
> > International Spaceflight Museum
> > [hidden email]
> > Skype: michael.lorrey
> > LinkedIn: https://www.linkedin.com/in/mikelorrey
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>



--
Mike Lorrey
CEO Galactic Systems, Inc
VP Stokens Venture Capital
[hidden email] <[hidden email]>
[hidden email]
International Spaceflight Museum
[hidden email]
Skype: michael.lorrey
LinkedIn: https://www.linkedin.com/in/mikelorrey
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev