Assert line 8014 of dgminowskiconv

[Slick]

I am hitting the assert here and does it mean that there is a problem with my 3d terrain? Could it be caused if there was a little gap in the terrain?

Code: Select all

dgContactPoint* contactOut = proxi.m_contacts;
      for (dgInt32 i = 0; i < count; i ++) {
         _ASSERTE ((dgAbsf(contactOut[i].m_normal % contactOut[i].m_normal) - dgFloat32 (1.0f)) < dgFloat32 (1.0e-5f));
         contactOut[i].m_body0 = proxi.m_referenceBody;
         contactOut[i].m_body1 = proxi.m_floatingBody;
         contactOut[i].m_collision0 = proxi.m_referenceCollision;
         contactOut[i].m_collision1 = proxi.m_floatingCollision;
      }

[Julio Jerez]

It means that a normal magnoth is no one, you can check contactOut[i].m_normal in the debugger and see if the values are correct,

[Slick]

From memory I think it was 1.01 or close to that. I realized it was > 1.0f.

I guess the question is what is the fix? Is there something in my mesh or what could be the reason for the assert kicking in?

[Julio Jerez]

the fix is to allow for a higher tolerance in the check. this things some time happens when doing float arithemetic with floats operating on large number and small numbers simultaneuslly.
what it means is the they is some face with a oblond aspect ratio.
you can simple do this
_ASSERTE ((dgAbsf(contactOut[i].m_normal % contactOut[i].m_normal) - dgFloat32 (1.0f)) < dgFloat32 (1.0e-2f));

If the problem still keeps happening over and over then it needs to be addressed.

[Slick]

I see so I could rebuild with that change to allow more tolerance.

So it is not necessarily a problem as such it seems. It is just that it is triggering a break when I am debugging. If I can reduce the tolerance a little without any bad effects that seems like a win.

For reference it seems to happen sometimes when an oblong type object moves over an edge of another oblong type object. I guess the shape isn't necessarily oblong but good enough to illustrate.

thanks