Rigid body gaining energy

[Sweenie]

Hi.

Not sure if this is the same bug you've been chasing in which the body can gain energy when colliding with a collision tree(the "popping" bug) but
when I drop a rigid body (box collider with the dimensions 1x1x4) onto a thin box(tree collider) the rigid body gains alot of energy and fly away.
This only seem to happen when the thin box hits the rigid body close to it's center.

Here is a demo of it, if you would like to debug it.
http://www.svenberra.net/test.zip
As before, just run the app and hit ~(key below escape) and type load world/inertia
If you need to reload the scene, just press up arrow in the console to repeat the last command.
Type newtondebug to render the colliders.

[Julio Jerez]

yes that is what cause the popping bug. it seem they is a bug somewhere that is adding energy to the inland.
I am adding debug code that will validate the conservation of energy before and after collision so that I can determine when exactly happens.

The function I added in not correct yet, because it is measure the energy before, and after but it is also adding the energy added by the external force.
And conservation of momentum in a collision is only valid when the external forces and torque are zero.

I will complete the rest tonight and see where the bug is, because it is not easy to debug it.

I have being debugging it the entire week, and I can clearly see that that it happen freely but it is still hard to debug it this is why I am adding the conservation of momentum after collision check.

[Julio Jerez]

Oh fix a bug in the ray cast, and now my tes set uop does not match.
It turn out that whenb a ray start vey far away form a coinve shape, the minscousky distance theorem can fail, just because of round off errors cnaultion dot product and cross products.
to fix that in eth conev hull ray cast, inetad of testion teh ray again teh BBox of the hull, I cast teh ray again the box of thr hull.
then is the ray hit the ray start form a much closest point to teh shape an dthsi make teh calculation local.
This made convex and ray cast not only more reliable but also much faster.

However this bug alter sligtly the original position of teh bodies in the demo and now the test doe no reproduce the bug

I will try your demo, maybe I get better luck with it.

[Julio Jerez]

Oh wow, your demo is exactly what I needed, awesome

[Julio Jerez]

I think you have to update to svn and link to the new dll.
I think the new changes make it incompatible with you .exe

[Sweenie]

Ok, synced to rev 2373.
Just redownload the demo.

When i slow down the simulation it looks like the body only gain an extreme angular velocity though it's hard to tell when it happens so fast.
I guess proper debugging is the only way to really know.

[Julio Jerez]

Oh I was debug wit teh wrong dll, I got it now, and this reproduce veryg acurarlly every time.
I beleieve I can debuged it. properlly now.
you are rignt it gain a tremedous amound of energy during ther very first collision.

[Julio Jerez]

I think I figured out, it is not the solver, it has to do with the fact that I seprated the collsion funtion tha calculate conc for roudn shape and contact for poygoinal faces.

in teh case of boxes, conve hull and cylinders, they use the same collsion funtion that was use in core 200,
however in teh prosses I commnet pout an very imprtnt funtion that filet the contact putput makin sure they are valid for physiocs simulation.

Basically contact in newton are calculate by usin closest mism diff threrom for conce objects. In most case thi made be that conave distance may no generta the best contact.

In this aparticaul example I see that teh contact calculatoir find 4 good contacts point in the direction (0, 0, 1)
but the it also find 3 more in direction (1, 0, 0) and tow in diretion (-1, 0, 0) it si teh last 5 contacts tha generete the bad bug
These last conat are diametrially opposed an dther form a sysme mass matrix with a very high condition numeber.
The solve solver blow up, the reason that it does is that it run out of iterations an exist with a bad solution that add energy to the system

This is a very very big problem I has alwy stroggle with.
In newton 1.0 teh way I solved was by srunn a mini single value decompasition on each contac joint and elimination teh contact that generar teh worse condition number.
This is elegant and very rubust, but is can be slow.

in newton 2.00 I remuve that and I adde a contact clipping function

Code: Select all

dgInt32 dgWorld::CalculatePolySoupToHullContactsDescrete (dgCollisionParamProxy& proxy) const
{
   dgCollisionBoundPlaneCache planeCache;

   dgInt32 count = 0;
   _ASSERTE (proxy.m_floatingCollision->IsType (dgCollision::dgCollisionMesh_RTTI));
   _ASSERTE (proxy.m_referenceCollision->IsType (dgCollision::dgCollisionConvexShape_RTTI));

   dgCollisionInstance* const polysoupInstance = proxy.m_floatingCollision;
   const dgPolygonMeshDesc& data = *proxy.m_polyMeshData;

   _ASSERTE (data.m_faceCount);
   dgFloat32* const faceSize = data.m_faceMaxSize;
   dgInt32* const idArray = (dgInt32*)data.m_userAttribute;
   dgInt32* const indexArray = (dgInt32*)data.m_faceVertexIndex;

   _ASSERTE (idArray);
   dgCollisionConvexPolygon polygon (m_allocator);
   dgCollisionInstance polyInstance (*polysoupInstance, &polygon);

   polygon.m_vertex = data.m_vertex;
   polygon.m_stride = dgInt32 (data.m_vertexStrideInBytes / sizeof (dgFloat32));

   dgInt32 reduceContactCountLimit = 0;
   dgInt32 countleft = proxy.m_maxContacts;

   dgInt32 indexCount = 0;
   proxy.m_floatingCollision = &polyInstance;
   dgContactPoint* const contactOut = proxy.m_contacts;

   for (dgInt32 j = 0; (j < data.m_faceCount) && (countleft > 0); j ++) {
      polygon.m_count = data.m_faceIndexCount[j];
      polygon.m_index = &indexArray[indexCount];

      if (data.m_faceNormalIndex) {
         polygon.m_normalIndex = data.m_faceNormalIndex[j];
         polygon.m_adjacentNormalIndex = (dgInt32*) &data.m_faceAdjencentEdgeNormal[indexCount];
      } else {
         polygon.m_normalIndex = 0;
         polygon.m_adjacentNormalIndex = NULL;
      }
      
      polygon.m_faceId = idArray[j];
      polygon.m_faceClipSize = faceSize ? faceSize[j] : dgFloat32 (0.0f);

      proxy.m_maxContacts = countleft;
      proxy.m_contacts = &contactOut[count];
      dgInt32 count1 = CalculateConvexPolygonToHullContactsDescrete (proxy);
      if (count1) {

// this is want causes the high energy collsion bug
          //count1 = polygon->ClipContacts (count1, &contactOut[count], soupMatrix);
         count += count1;
         countleft -= count1;
         reduceContactCountLimit += count1;
         if ((reduceContactCountLimit > 24) || (countleft <= 0)) {
            count = ReduceContacts (count, contactOut, proxy.m_maxContacts >> 2, dgFloat32 (1.0e-2f));
            countleft = proxy.m_maxContacts - count;
            reduceContactCountLimit = 0;
         }
      }
      indexCount += data.m_faceIndexCount[j];
   }

Basically the funtion uses teh hewristic that all cotact sopdul pint in teh same hiemsphere direction, so it remove contact tah fall ouside, it is no as robust as a SVD analysis but is was relativally correct.
the problem is that is no loneg waor afte I intruduct Genral scale, so I commbete out and I forget to write the new function.
To test this I am going to re enable the function and since this test has unit scale, then the bug should go away.
I am also considerinhg addin teh SBD analisi fo contact, maybe as an option.

[Julio Jerez]

hurray!!, I found the bug, wow that was there since I added the conic collision shape.
It has to do with the mesh welding feature, that somehow is failing in some places and given positive how are false to the contact solver.
I added a Hack that that disallow the aggressive contact calculation and uses the minkousky. This always find the contact and the normal that minimizes the contact penetration, and it can fail too, but it is much, much rare.
It is only when the edge information is accurate that contact fo polygonal mesh can be calculated correctly.
I do not have more time to explain now, I do later, but the solution is to find why the collision tree did no welded the mesh correctly.

there are few reasons that are legitimate for that.
-The face is a detached face in the mesh
-The face is double face
-The face has an edeg that is shared but more that one other face making a non manifold mesh

It does not look like the mesh has any of these case, so there must be a bug there.


Please sinc to svn and try to see if it works for you now?

[Sweenie]

Awesome!
No more explosion, the body lands nicely on the tree collider.

[Julio Jerez]

Remember this is a hack to prove that that was the cause of the bug.
Basically not having the edge weld information is allowing the collision system to generate contacts tha produce ill condition mass matrices.
The hack can make other collision shape to malfuntion until I fix it for real.

The only way to have it working is by having each face indication if the share face alne each edge form part of a convex turn or a concave turn.
convex turn can generate edge contacts that can only be on the voronoi region formed by the edge and the two faces,
concave turn can cannot generate edge or vertex contact. The hack disabled that for now.

[Julio Jerez]

Ok sweenei I think that I completed the basics collision routine and fix teh hack to go around this bad contcat generation bug.

I was going to test it wit thi demo you provided, but it no linger work because teh funtion to crate a newtor body now create a dynamics body.
if you can make the change and test this later alpha, tah will be great.
I has not stress test the code a lot but I beleiev it is more robust overall that core 200, and more imprtant is faster in all counts.


now I have the support fo compelte the convex cast and player kenematic palyer controller demo/feature.

[Sweenie]

Updated my test demo and it looks good.
You can download it again if you want to test it yourself.

[Bird]

I was going through the Newton demos today (build 2538 ) and saw intermittent high energy poppers while running the "Scaled mesh collision" demo several times. They happen with 1 thread but happen more often when using 8 threads.

-Bird

[Julio Jerez]

Oh I was wondering wher that was and nwo I see it it.
I am fixing it, thanks.
This bug is like a turd that do not flush, I had to fix this for good.

edit: the good thing is that I insulated one very simple cae of on e simple cylider faliing down by gravity , in one step the veliocity increase by 33 m/s and is happen every time.
I have an idea wat teh bug is, so now I will work on it.