[Opensim-dev] Prospective ODE physics changes

[Teravus Ovares]

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<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<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<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20120104/a3dac122/attachment-0001.html>