[Opensim-dev] Prospective ODE physics changes

[AJLDuarte]

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.

Regards,
Ubit

  ----- Original Message ----- 
  From: AJLDuarte 
  To: 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.
      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.

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

      Best Regards,
  Ubit Umarov


    ----- Original Message ----- 
    From: Teravus Ovares 
    To: 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> 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>> 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>
           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

      _______________________________________________
      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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20120105/72774a59/attachment-0001.html>