[Opensim-dev] Prospective ODE physics changes
Justin Clark-Casey
jjustincc at googlemail.com
Thu Jan 5 23:23:35 UTC 2012
On 05/01/12 12:19, AJLDuarte wrote:
> Hi,
> Reading back my previus posts, They may look a bit unfriendly.
> If so please consider it just resulting from of my non-native english nature.
Hi Ubit. No problem. If my own tone is occasionally terse and robust that's because I have to read/write lots of
e-mails quickly :). I do value your input and opinion.
> Regards,
> Ubit
>
> ----- Original Message -----
> *From:* AJLDuarte <mailto:ajlduarte at sapo.pt>
> *To:* opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
> *Sent:* Thursday, January 05, 2012 12:04 PM
> *Subject:* Re: [Opensim-dev] Prospective ODE physics changes
>
> Hi again,
> Forgot to mention that you can find working code at https://github.com/UbitUmarov/Ubit-opensim where i did tried to
> fix those and other issues
> You may see, use, adapt and of course improve.
Thanks, I'll certainly bear that in mind.
> Regards,
> Ubit
>
> ----- Original Message -----
> *From:* AJLDuarte <mailto:ajlduarte at sapo.pt>
> *To:* opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
> *Sent:* Thursday, January 05, 2012 11:39 AM
> *Subject:* Re: [Opensim-dev] Prospective ODE physics changes
>
> Hi,
> Justin, before thicking about reducing the size of the array passed to ode collide function to receive the
> colision contacts information, maybe you should remember what i told you about managed versus unmanaged memory
> use in the ode plugin.
> Maybe you should think about what is being done by framework to convert the array from managed memory space to
> unmanaged and then back again on each call.
I did review those changes but I'm not convinced that we aren't already using pinned memory. For instance
public static extern int Collide(IntPtr o1, IntPtr o2, int flags, [In, Out] ContactGeom[] contact, int skip);
has the contact parameter with both [In and Out] attributes. According to the ms docs that I've read, this means that
pinned memory will be used - though I find the available docs really quite hard to read. Is this incorrect? A similar
thing is true for
public static extern IntPtr JointCreateContact(IntPtr world, IntPtr group, ref Contact contact);
where the Contact is a ref and so occupies pinned memory, according to my interpretation of ms docs.
> If you do that (or just remember the details i told you) maybe you will see how to save some cpu without
> reducing the stability of the simulation to a useless state.
Isn't 'useless state' a bit strong? Reduce the collisions all the way down to 1 had no noticeable effect in my tests,
even with physical objects. I'm not advocating this number - it's just an illustration.
I think there has to be a balance between physical fidelity and the need for a given sim to be able to host more
avatars. On balance, I think people would prefer avatars. In any case, one can always adjust those parameters in config.
> Also before doing hard testing with diferent ode supporting libs, maybe you should also review managed/unmanaged
> issues on other parts of the plugin. JointCreateContact ? GeomHeightfieldDataBuildSingle ? ....
I have already done actual stress testing. The reason for my conclusions is that ODE does not fail on a single sim, as
shown by the thousands of hours that it now doesn't crash on osgrid, for instance. If there was a problem with freeing
memory due to misuse of p/Invoke. I would except this scenario to crash as well.
However, two regions does crash and different OdeScene classes have no common data (e.g. static variables) at the C#
level, whilst the mailing list messages I've read do suggest that they share a global cache on the ODE level.
Moreover, GIMPACT does not crash with two regions. If there was a p/Invoke issue wouldn't we expect this collider to
probably have the same problem?
Having said that, it's certainly not impossible that there could be a complicated interaction with p/Invoke and ODE with
multiple regions. But I simply lack the time to test every scenario when there's a solution that appears to work and
can be reversed if it turns out to be bad. Development is a learning process.
Regards,
Justin
> Best Regards,
> Ubit Umarov
>
> ----- Original Message -----
> *From:* Teravus Ovares <mailto:teravus at gmail.com>
> *To:* opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
> *Sent:* Wednesday, January 04, 2012 7:53 PM
> *Subject:* Re: [Opensim-dev] Prospective ODE physics changes
>
> ODE Documentation and examples :)
> Regards
>
> Dan
>
> On Wed, Jan 4, 2012 at 2:46 PM, Justin Clark-Casey <jjustincc at googlemail.com
> <mailto:jjustincc at googlemail.com>> wrote:
>
> Hi Teravus, nice to hear from you again!
>
> Yes, more testing is needed, hopefully on OSGrid. But it seems there may be a tradeoff between having
> super smooth physics objects and being able to get more avatars in a scene without encountering cpu
> limits. My perception is having more avatars is a more common use case then lots of physics objects,
> particularly as OpenSim's current ODE use does not seem to provide a good physics simulation). Anybody
> who does want to try for better physics could always turn the collision number back up.
>
> In any case, what was the rationale for choosing 80 as the default?
>
>
> On 03/01/12 22:30, Teravus Ovares wrote:
>
> With ODE, it depends on the physics situation.
> With Tri-Mesh and the heightfield collider specifically, ODE generates lots of small effect contacts
> and then the
> stepper integrates them all into a contact resolution force. With tri-mesh and the heightfield,
> depending on how an
> object collides with another, there could be 20 or 30 contacts that all factor into getting the
> object to react
> normally. So, to test, you're going to want to use a stack of 'active'(physical in the client)
> tri-mesh objects. You
> may also want two or more trimesh LINKSETS to see how they react.
> My guess, is the first thing that you're going to notice is that a tri-mesh object sitting on
> another object will become
> more unstable (vibrate more). Each mini-contact represents a part of the force to keep the object
> from rotating from
> the other parts of the contact resolution force. As the effect gets worse, you're going to notice
> 'rotation anomolies'
> that occur when objects collide.
> Think of it like... you have a cube shaped trimesh... and the cube's corners are touching a flat
> ground. In
> theory, that would generate 4 contact points for each of the vertices touching the flat ground. If
> you cut one off,
> then only three of the corners are being held above ground. On a larger scale, If you do that
> enough, then the
> object will partially fall through the ground and then bounce back up from an excessive contact
> resolution force
> creating instability and vibrating.
> Those are the indicators that I would use to determine if it's OK to make that change. Are 8
> contacts enough for ODE
> to react properly in our usage? That remains to be seen :).
> Regards
> Teravus
>
> On Tue, Jan 3, 2012 at 4:58 PM, Adams, Robert <robert.adams at intel.com
> <mailto:robert.adams at intel.com> <mailto:robert.adams at intel.com <mailto:robert.adams at intel.com>__>>
> wrote:
>
> > ...
> > According to [2], the maximum reported scripting collision contacts is 8.
> >
> > Testing with 8 on Wright Plaza today in the Tuesday meeting seemed to greatly reduce physics
> scene time compared to
> > previously without any apparent loss of required fidelity (50ms with 18 avatars, albeit mostly
> sitting down -
> > unfortunately I didn't record previous week's numbers but they were higher. Nebadon tested one of
> his vehicles).
>
> Looking at the code, contacts_per_collision is the number of collision points reported by ODE for
> each collision --
> like a prim sitting on rough terrain and touching multiple places on the ground. Reducing the count
> to 8 means that
> no more than 8 contact points will be reported by ODE and, if there are more, you can't be sure you
> get the 'best' ones.
>
> I suspect that most of the time there are only a few contact points so it doesn't make sense that
> reducing the
> number from 80 to 8 would significantly reduce the compute time. If it is the number of contact
> points causing the
> computation overhead then ODE must be normally returning more than 8 contact points. Is this really
> the case? Or is
> something else going on?
>
> -- ra
> _________________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> <mailto:Opensim-dev at lists.__berlios.de <mailto:Opensim-dev at lists.berlios.de>>
> https://lists.berlios.de/__mailman/listinfo/opensim-dev
> <https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
>
>
>
>
> _________________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/__mailman/listinfo/opensim-dev
> <https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
>
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
> _________________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/__mailman/listinfo/opensim-dev
> <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
>
> ------------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
More information about the Opensim-dev
mailing list