[Opensim-dev] Mega Regions and PAL support in OpenSim?

[Dahlia Trimble]

Or, in perhaps less than accurate but more colloquial terms: a "taint" is a
signal to the physics engine that an object in the scene has been modified
by something outside of the context of the physics engine, and the physics
engine should take some action on that object when computing the next frame.

On Wed, Sep 30, 2009 at 7:44 PM, Teravus Ovares <teravus at gmail.com> wrote:

> Taints are there because many threads modify the properties of
> physicsactors.     The properties are also not inherently thread safe.
>   So, to ensure data integrity, you can lock the internal data types
> when setting them, or you can keep a list of tainted physics actors
> and send the changed values to the internal physics engine within the
> thread context of region's heartbeat thread.    This is especially
> important when dealing with unmanaged resources.  For example, with
> the OpenDynamicsEngine physics plugin, if the internal data was set by
> the properties directly, the server would quickly crash with a memory
> access violation or assert with, 'invalid operation for locked space;.
>
> So, what I do, generally, is maintain a plugin state and an internal
> physics engine state for each physics actor.    The region, when
> setting one of the properties, will taint physics actors by calling
> the method in the PhysicsScene with the Physics Actor that it tainted.
>  The next time the heartbeat thread steps the physics world, just
> before stepping the world and doing collision detection, the plugin
> state gets locked and applied to the internal physics engine.   This
> strategy keeps locking to a minimum while allowing multiple threads to
> change the state safely.
>
> Regards
>
> Teravus
>
> On Wed, Sep 30, 2009 at 9:35 PM, Robert A. Knop Jr. <rknop at pobox.com>
> wrote:
> > On Wed, Sep 30, 2009 at 06:23:56PM -0700, Dahlia Trimble wrote:
> >> We're watching PAL and may consider it when we find it to be sufficient
> for
> >> use with OpenSim. Another factor to consider is the majority of OpenSim
> >> developers are unpaid volunteers and it's difficult to find people who
> have
> >> the knowledge and expertise for implementing physics simulations and are
> >> willing to donate their time and services. If you have this expertise or
> >> know of someone else who would be willing to help implement PAL then
> please
> >> do consider creating a PAL module and donating it to the community.
> >
> > I fully understand (at this point) the MICASim Physics module and how it
> > interacts; thanks to ter_afk (on IRC-- I wish I knew his real name!) for
> > some pointers on getting the message back that the scene needs to get
> > updated info from the physics sim.
> >
> > I have figured out a bunch of what needs to happen, but not all of it.
> > Could somebody point me to where I'd look to understand what taints are
> > all about WRT a physics engine?
> >
> > I have various interests in physics engines, what with being a
> > physicist and the last one to hack the MICA code....
> >
> > --
> > --Rob Knop
> >  E-mail:    rknop at pobox.com
> >  Home Page: http://www.pobox.com/~rknop/
> >  Blog:      http://www.sonic.net/~rknop/blog/
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090930/56424063/attachment-0001.html>