assert in dgContactSolver::ReduceTetrahedrum

Report any bugs here and we'll post fixes

Moderators: Sascha Willems, Thomas

assert in dgContactSolver::ReduceTetrahedrum

Postby JoeJ » Wed Jul 05, 2017 4:44 am

Hi Julio,

i got this assert (end of function) two times the last two days.
It happens on a swinging two body IP, when my controller gets mad and probably generates huge forces (or maybe even NaNs) for the joint.

I've just added check to prevent NaNs and will see if it contiunues to happen.
Currently i have no idea how to reproduce this. So just to let you know.

Code: Select all
DG_INLINE dgBigVector dgContactSolver::ReduceTetrahedrum (dgInt32& indexOut)
{
   const dgBigVector p0(m_hullDiff[0]);
   const dgBigVector p1(m_hullDiff[1]);
   const dgBigVector p2(m_hullDiff[2]);
   const dgBigVector p3(m_hullDiff[3]);
   const dgBigVector e10(p1 - p0);
   const dgBigVector e20(p2 - p0);
   const dgBigVector e30(p3 - p0);

   const dgFloat64 d0 = sqrt (e10.DotProduct4(e10).GetScalar());
   if (d0 > dgFloat64(0.0f)) {
      const dgFloat64 invd0 = dgFloat64(1.0f) / d0;
      const dgFloat64 l10 = e20.DotProduct4(e10).GetScalar() * invd0;
      const dgFloat64 l20 = e30.DotProduct4(e10).GetScalar() * invd0;
      const dgFloat64 desc11 = e20.DotProduct4(e20).GetScalar() - l10 * l10;
      if (desc11 > dgFloat64(0.0f)) {
         const dgFloat64 d1 = sqrt(desc11);
         const dgFloat64 invd1 = dgFloat64(1.0f) / d1;
         const dgFloat64 l21 = (e30.DotProduct4(e20).GetScalar() - l20 * l10) * invd1;
         const dgFloat64 desc22 = e30.DotProduct4(e30).GetScalar() - l20 * l20 - l21 * l21;
         if (desc22 > dgFloat64(0.0f)) {
            const dgFloat64 d2 = sqrt(desc22);
            const dgFloat64 invd2 = dgFloat64(1.0f) / d2;
            const dgFloat64 b0 = -e10.DotProduct4(p0).GetScalar();
            const dgFloat64 b1 = -e20.DotProduct4(p0).GetScalar();
            const dgFloat64 b2 = -e30.DotProduct4(p0).GetScalar();

            dgFloat64 u1 = b0 * invd0;
            dgFloat64 u2 = (b1 - l10 * u1) * invd1;
            dgFloat64 u3 = (b2 - l20 * u1 - l21 * u2) * invd2 * invd2;
            u2 = (u2 - l21 * u3) * invd1;
            u1 = (u1 - l10 * u2 - l20 * u3) * invd0;
            if (u3 < dgFloat64(0.0f)) {
               // this looks funny but it is correct
            } else if (u2 < dgFloat64(0.0f)) {
               m_hullSum[2] = m_hullSum[3];
               m_hullDiff[2] = m_hullDiff[3];
            } else if (u1 < dgFloat64(0.0f)) {
               m_hullSum[1] = m_hullSum[3];
               m_hullDiff[1] = m_hullDiff[3];
            } else if (u1 + u2 + u3 > dgFloat64(1.0f)) {
               m_hullSum[0] = m_hullSum[3];
               m_hullDiff[0] = m_hullDiff[3];
            } else {
               return dgBigVector::m_zero;
            }
            indexOut = 3;
            return ReduceTriangle(indexOut);
         }
      }
   }
   // this is a degenerated tetra. this should never happens
   dgAssert (0);
   return dgBigVector::m_zero;
}
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: assert in dgContactSolver::ReduceTetrahedrum

Postby Julio Jerez » Wed Jul 05, 2017 11:14 am

ok that's not a bug, that's a special case that is so rare that I have never have it happen to me.
this use to happen a lot more in previous version.
what the mean is that closest distance can't determine of the two shapes are colliding or separated because they are so closed that they can be considered touching each other but not intersecting.

the cost of that is that the collision system will resolve it by calculating a full convex hull of the Minkowski difference of the two shape to check if the origin is inside or outside the shape.
then the code will see that the origin is outside and report no collision.

In general, I place assert like that in places that are hard to debug because they are very rare, it has never happen to me, but this was common in 3.13 an lower. I am glad at least one person have it happening.
you can comment the assert out, I will in next version. all it mean that a collision will do the long path in very rare occasions maybe one in less that 10 or 100 million times.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles


Return to Bugs and Fixes

Who is online

Users browsing this forum: No registered users and 7 guests

cron