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.ad...@intel.com
<mailto:robert.ad...@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@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
