[Opensim-dev] Prospective ODE physics changes
Teravus Ovares
teravus at gmail.com
Fri Jan 6 01:05:49 UTC 2012
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
> 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>
>> *To:* opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.**
>> berlios.de <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>
>> *To:* opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.**
>> berlios.de <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 <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 <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 <Opensim-dev at lists.berlios.de>>
>> <mailto:Opensim-dev at lists.__be**rlios.de<http://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>
>> <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 <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 <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
>> 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>
>>
>> ------------------------------**------------------------------**
>> ------------------------------**------------------------------
>>
>>
>> ______________________________**_________________
>> 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>
>>
>>
>>
>> ______________________________**_________________
>> 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/20120105/795deab7/attachment-0001.html>
More information about the Opensim-dev
mailing list