ODE Documentation and examples :) Regards
Dan On Wed, Jan 4, 2012 at 2:46 PM, Justin Clark-Casey <[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]**>> 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:Opensim-dev@lists.**berlios.de<[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<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] > 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
