<div>Just to elaborate a bit on my previous comment about it being from documentation and examples... </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>The size of the collision array is what is in examples and documentation.</div>
<div> </div>
<div>Regards</div>
<div> </div>
<div>Teravus.<br><br></div>
<div class="gmail_quote">On Thu, Jan 5, 2012 at 6:23 PM, Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im">On 05/01/12 12:19, AJLDuarte wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Hi,<br>Reading back my previus posts, They may look a bit unfriendly.<br>If so please consider it just resulting from of my non-native english nature.<br>
</blockquote><br></div>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.<br><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im">Regards,<br>Ubit<br><br> ----- Original Message -----<br></div> *From:* AJLDuarte <mailto:<a href="mailto:ajlduarte@sapo.pt" target="_blank">ajlduarte@sapo.pt</a>><br> *To:* <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.<u></u>berlios.de</a>><br>
*Sent:* Thursday, January 05, 2012 12:04 PM<br> *Subject:* Re: [Opensim-dev] Prospective ODE physics changes
<div class="im"><br><br> Hi again,<br> Forgot to mention that you can find working code at <a href="https://github.com/UbitUmarov/Ubit-opensim" target="_blank">https://github.com/UbitUmarov/<u></u>Ubit-opensim</a> where i did tried to<br>
fix those and other issues<br> You may see, use, adapt and of course improve.<br></div></blockquote><br>Thanks, I'll certainly bear that in mind.<br><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im"> Regards,<br> Ubit<br><br> ----- Original Message -----<br></div> *From:* AJLDuarte <mailto:<a href="mailto:ajlduarte@sapo.pt" target="_blank">ajlduarte@sapo.pt</a>><br> *To:* <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.<u></u>berlios.de</a>><br>
*Sent:* Thursday, January 05, 2012 11:39 AM<br> *Subject:* Re: [Opensim-dev] Prospective ODE physics changes
<div class="im"><br><br> Hi,<br> Justin, before thicking about reducing the size of the array passed to ode collide function to receive the<br> colision contacts information, maybe you should remember what i told you about managed versus unmanaged memory<br>
use in the ode plugin.<br> Maybe you should think about what is being done by framework to convert the array from managed memory space to<br> unmanaged and then back again on each call.<br></div></blockquote>
<br>I did review those changes but I'm not convinced that we aren't already using pinned memory. For instance<br><br>public static extern int Collide(IntPtr o1, IntPtr o2, int flags, [In, Out] ContactGeom[] contact, int skip);<br>
<br>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<br>
<br>public static extern IntPtr JointCreateContact(IntPtr world, IntPtr group, ref Contact contact);<br><br>where the Contact is a ref and so occupies pinned memory, according to my interpretation of ms docs.
<div class="im"><br><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"> If you do that (or just remember the details i told you) maybe you will see how to save some cpu without<br>
reducing the stability of the simulation to a useless state.<br></blockquote><br></div>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.<br>
<br>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.
<div class="im"><br><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"> Also before doing hard testing with diferent ode supporting libs, maybe you should also review managed/unmanaged<br>
issues on other parts of the plugin. JointCreateContact ? GeomHeightfieldDataBuildSingle ? ....<br></blockquote><br></div>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.<br>
<br>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.<br>
<br>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?<br><br>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.<br>
<br>Regards,<br><br>Justin<br><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im"> Best Regards,<br> Ubit Umarov<br><br> ----- Original Message -----<br></div> *From:* Teravus Ovares <mailto:<a href="mailto:teravus@gmail.com" target="_blank">teravus@gmail.com</a>><br>
*To:* <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.<u></u>berlios.de</a>><br>
*Sent:* Wednesday, January 04, 2012 7:53 PM<br> *Subject:* Re: [Opensim-dev] Prospective ODE physics changes
<div class="im"><br><br> ODE Documentation and examples :)<br> Regards<br><br> Dan<br><br> On Wed, Jan 4, 2012 at 2:46 PM, Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a><br>
</div>
<div>
<div class="h5"> <mailto:<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.<u></u>com</a>>> wrote:<br><br> Hi Teravus, nice to hear from you again!<br><br> Yes, more testing is needed, hopefully on OSGrid. But it seems there may be a tradeoff between having<br>
super smooth physics objects and being able to get more avatars in a scene without encountering cpu<br> limits. My perception is having more avatars is a more common use case then lots of physics objects,<br>
particularly as OpenSim's current ODE use does not seem to provide a good physics simulation). Anybody<br> who does want to try for better physics could always turn the collision number back up.<br>
<br> In any case, what was the rationale for choosing 80 as the default?<br><br><br> On 03/01/12 22:30, Teravus Ovares wrote:<br><br> With ODE, it depends on the physics situation.<br>
With Tri-Mesh and the heightfield collider specifically, ODE generates lots of small effect contacts<br> and then the<br> stepper integrates them all into a contact resolution force. With tri-mesh and the heightfield,<br>
depending on how an<br> object collides with another, there could be 20 or 30 contacts that all factor into getting the<br> object to react<br> normally. So, to test, you're going to want to use a stack of 'active'(physical in the client)<br>
tri-mesh objects. You<br> may also want two or more trimesh LINKSETS to see how they react.<br> My guess, is the first thing that you're going to notice is that a tri-mesh object sitting on<br>
another object will become<br> more unstable (vibrate more). Each mini-contact represents a part of the force to keep the object<br> from rotating from<br> the other parts of the contact resolution force. As the effect gets worse, you're going to notice<br>
'rotation anomolies'<br> that occur when objects collide.<br> Think of it like... you have a cube shaped trimesh... and the cube's corners are touching a flat<br>
ground. In<br> theory, that would generate 4 contact points for each of the vertices touching the flat ground. If<br> you cut one off,<br> then only three of the corners are being held above ground. On a larger scale, If you do that<br>
enough, then the<br> object will partially fall through the ground and then bounce back up from an excessive contact<br> resolution force<br> creating instability and vibrating.<br>
Those are the indicators that I would use to determine if it's OK to make that change. Are 8<br> contacts enough for ODE<br> to react properly in our usage? That remains to be seen :).<br>
Regards<br> Teravus<br><br> On Tue, Jan 3, 2012 at 4:58 PM, Adams, Robert <<a href="mailto:robert.adams@intel.com" target="_blank">robert.adams@intel.com</a><br></div>
</div> <mailto:<a href="mailto:robert.adams@intel.com" target="_blank">robert.adams@intel.com</a><u></u>> <mailto:<a href="mailto:robert.adams@intel.com" target="_blank">robert.adams@intel.com</a> <mailto:<a href="mailto:robert.adams@intel.com" target="_blank">robert.adams@intel.com</a><u></u>>__>>
<div class="im"><br> wrote:<br><br> > ...<br> > According to [2], the maximum reported scripting collision contacts is 8.<br> ><br> > Testing with 8 on Wright Plaza today in the Tuesday meeting seemed to greatly reduce physics<br>
scene time compared to<br> > previously without any apparent loss of required fidelity (50ms with 18 avatars, albeit mostly<br> sitting down -<br> > unfortunately I didn't record previous week's numbers but they were higher. Nebadon tested one of<br>
his vehicles).<br><br> Looking at the code, contacts_per_collision is the number of collision points reported by ODE for<br> each collision --<br> like a prim sitting on rough terrain and touching multiple places on the ground. Reducing the count<br>
to 8 means that<br> no more than 8 contact points will be reported by ODE and, if there are more, you can't be sure you<br> get the 'best' ones.<br><br> I suspect that most of the time there are only a few contact points so it doesn't make sense that<br>
reducing the<br> number from 80 to 8 would significantly reduce the compute time. If it is the number of contact<br> points causing the<br> computation overhead then ODE must be normally returning more than 8 contact points. Is this really<br>
the case? Or is<br> something else going on?<br><br> -- ra<br></div> ______________________________<u></u>___________________
<div class="im"><br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.<u></u>berlios.de</a>><br>
</div> <mailto:<a href="mailto:Opensim-dev@lists." target="_blank">Opensim-dev@lists.</a>__<a href="http://berlios.de/" target="_blank">be<u></u>rlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.<u></u>berlios.de</a>>><br>
<a href="https://lists.berlios.de/__mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/__<u></u>mailman/listinfo/opensim-dev</a><br> <<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a>><br>
<br><br><br><br><br> ______________________________<u></u>___________________
<div class="im"><br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.<u></u>berlios.de</a>><br>
</div> <a href="https://lists.berlios.de/__mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/__<u></u>mailman/listinfo/opensim-dev</a>
<div class="im"><br> <<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a>><br><br><br><br> --<br>
Justin Clark-Casey (justincc)<br> <a href="http://justincc.org/blog" target="_blank">http://justincc.org/blog</a><br> <a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
</div> ______________________________<u></u>___________________
<div class="im"><br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.<u></u>berlios.de</a>><br>
</div> <a href="https://lists.berlios.de/__mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/__<u></u>mailman/listinfo/opensim-dev</a><br> <<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a>><br>
<br><br> ------------------------------<u></u>------------------------------<u></u>------------------------------<u></u>------------------------------
<div class="im"><br><br> ______________________________<u></u>_________________<br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br><br></div> ------------------------------<u></u>------------------------------<u></u>------------------------------<u></u>------------------------------
<div class="im"><br><br> ______________________________<u></u>_________________<br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br><br></div> ------------------------------<u></u>------------------------------<u></u>------------------------------<u></u>------------------------------
<div class="im"><br><br> ______________________________<u></u>_________________<br> Opensim-dev mailing list<br> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
<br><br><br>______________________________<u></u>_________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
</div></blockquote>
<div class="HOEnZb">
<div class="h5"><br><br>-- <br>Justin Clark-Casey (justincc)<br><a href="http://justincc.org/blog" target="_blank">http://justincc.org/blog</a><br><a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
______________________________<u></u>_________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>