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 <[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>>
*To:* [email protected]
<mailto:[email protected]>
<mailto:opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
*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:[email protected]
<mailto:[email protected]>>
*To:* [email protected]
<mailto:[email protected]>
<mailto:opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
*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:[email protected]
<mailto:[email protected]>>
*To:* [email protected]
<mailto:[email protected]>
<mailto:opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
*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
<[email protected]
<mailto:[email protected]>
<mailto:jjustincc@googlemail.__com <mailto:[email protected]>>>
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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>__>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>__>__>>
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
[email protected] <mailto:[email protected]>
<mailto:Opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
<mailto:Opensim-dev@lists. <mailto:Opensim-dev@lists.>__be__rlios.de
<http://berlios.de/>
<mailto:Opensim-dev@lists.__berlios.de
<mailto:[email protected]>>>
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
[email protected] <mailto:[email protected]>
<mailto:Opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
<mailto:Opensim-dev@lists.__berlios.de
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
------------------------------__------------------------------__------------------------------__------------------------------
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
------------------------------__------------------------------__------------------------------__------------------------------
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_________________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-dev
<https://lists.berlios.de/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
