[Opensim-dev] Prospective ODE physics changes
Justin Clark-Casey
jjustincc at googlemail.com
Fri Jan 6 21:43:31 UTC 2012
Thanks Teravus. I did quickly grep the ODE example code and wiki manual for "80" but came up with nothing. But that's
certainly not a thorough check - I'll have a closer look soon.
On 06/01/12 01:05, Teravus Ovares wrote:
> Just to elaborate a bit on my previous comment about it being from documentation and examples...
> I want to be clear... I didn't actually add that configuration parameter. Jhurliman did. The default configuration
> setting and, it looks like he used the size of the collision array for the default setting.
> The size of the collision array is what is in examples and documentation.
> Regards
> Teravus.
>
> On Thu, Jan 5, 2012 at 6:23 PM, Justin Clark-Casey <jjustincc at googlemail.com <mailto:jjustincc at googlemail.com>> wrote:
>
> 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 <mailto:ajlduarte at sapo.pt>>
> *To:* 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>>
> *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
> <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 <mailto:ajlduarte at sapo.pt>>
> *To:* 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>>
> *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 <mailto:teravus at gmail.com>>
> *To:* 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>>
> *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>
> <mailto: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>__> <mailto: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>>
> <mailto:Opensim-dev at lists. <mailto:Opensim-dev at lists.>__be__rlios.de <http://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>
> <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> <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>
>
> <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> <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>
> <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>
>
>
> ------------------------------__------------------------------__------------------------------__------------------------------
>
>
> _________________________________________________
> 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 <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
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
More information about the Opensim-dev
mailing list