dgCollisionCompound.cpp assert

[JernejL]

Yesterday I've built the newest newton from git and was running a new, longer-lasting game test, after hours, this assert had triggered:

Code: Select all

Program: J:\AppBuilder\Delfi\Top Down City\Game\Libraries\Newton.dll
File: ..\..\dgPhysics\dgCollisionCompound.cpp
Line: 252

Expression: separatingDistance > dgFloat32 (1000.0f)


This is in function dgCollisionCompound::dgNodeBase::BoxTest

I do not have a call stack yet because gdb cannot work with pdb on windows, i will post it when i run it in visual studio and see if it can be reproduced there.

[JernejL]

Ok - i got another issue in compound collision, this is from same (latest) build from git trunk, this is also related to dgCollisionCompound and might be connected:

Code: Select all

Debug Assertion Failed!

Program: J:\AppBuilder\Delfi\Top Down City\Game\Libraries\Newton.dll
File: ..\..\dgPhysics\dgContactSolver.cpp
Line: 1439

Expression: count0


Stack trace:

Code: Select all

>   newton.dll!dgContactSolver::CalculateContacts(point0={...}, point1={...}, normal={...}) Line 1439   C++
    newton.dll!dgContactSolver::CalculateConvexToConvexContacts() Line 1353   C++
    newton.dll!dgWorld::CalculateConvexToConvexContacts(proxy={...}) Line 2058   C++
    newton.dll!dgCollisionConvexPolygon::CalculateContactToConvexHullDescrete(world=0x18b55200, parentMesh=0x213d9760, proxy={...}) Line 758   C++
    newton.dll!dgWorld::CalculatePolySoupToHullContactsDescrete(proxy={...}) Line 2262   C++
    newton.dll!dgWorld::CalculateConvexToNonConvexContacts(proxy={...}) Line 2153   C++
    newton.dll!dgCollisionCompound::CalculateContactsToCollisionTree(pair=0x213dfb4c, proxy={...}) Line 2294   C++
    newton.dll!dgCollisionCompound::CalculateContacts(pair=0x213dfb4c, proxy={...}) Line 1558   C++
    newton.dll!dgWorld::CompoundContacts(pair=0x213dfb4c, proxy={...}) Line 1565   C++
    newton.dll!dgWorld::CalculateContacts(pair=0x213dfb4c, threadIndex=0, ccdMode=false, intersectionTestOnly=false) Line 1646   C++
    newton.dll!dgBroadPhase::CalculatePairContacts(pair=0x213dfb4c, threadID=0) Line 1082   C++
    newton.dll!dgBroadPhase::AddPair(contact=0x24d550e0, timestep=0.0166666675, threadIndex=0) Line 1131   C++
    newton.dll!dgBroadPhase::UpdateRigidBodyContacts(descriptor=0x1796fd84, timeStep=0.0166666675, threadID=0) Line 1557   C++
    newton.dll!dgBroadPhase::UpdateRigidBodyContactKernel(context=0x1796fd84, __formal=0x00000000, threadID=0) Line 1481   C++
    newton.dll!dgThreadHive::dgWorkerThread::RunNextJobInQueue(threadId=0) Line 224   C++
    newton.dll!dgThreadHive::dgWorkerThread::ConcurrentWork(threadId=0) Line 243   C++
    newton.dll!dgThreadHive::dgWorkerThread::Execute(threadId=0) Line 260   C++
    newton.dll!dgThread::dgThreadSystemCallback(threadData=0x18bf0044) Line 201   C++
    newton.dll!std::_Bind<1,void *,void * (__cdecl*const)(void *),dgThread *>::_Do_call<,0>(_Myfargs={...}, __formal={...}) Line 1149   C++
    newton.dll!std::_Bind<1,void *,void * (__cdecl*const)(void *),dgThread *>::operator()<>() Line 1138   C++
    newton.dll!std::_LaunchPad<std::_Bind<1,void *,void * (__cdecl*const)(void *),dgThread *> >::_Run(_Ln=0x01f5e770) Line 196   C++
    newton.dll!std::_LaunchPad<std::_Bind<1,void *,void * (__cdecl*const)(void *),dgThread *> >::_Go() Line 187   C++
    newton.dll!_Call_func(_Data=0x01f5e770) Line 28   C++
    newton.dll!_callthreadstartex() Line 376   C
    newton.dll!_threadstartex(ptd=0x18bf78d8) Line 359   C
    kernel32.dll!@BaseThreadInitThunk@12()   Unknown
    ntdll.dll!__RtlUserThreadStart()   Unknown
    ntdll.dll!__RtlUserThreadStart@8()   Unknown


[Julio Jerez]

that's not really an error. the assert can be safely removed.
what happen there is that when two convex shapes collide the steps to calculate the contacts are this.
1-Get the minimum translation distance that resolve the collision by translating the bodies along that distance.
2-with this translation distance, two 2d polygons are calculated by clipping the two convex shapes.
3-the contacts points are the intersection points of these two 2d polygons.

that assert happens on step 3, what it means is that the two shapes are closed enough that the translation distance exist and the two 2d polygon also exist. but the two 2d polygons do not intersect.

The reason for this are many, the shapes can be close enough but the are not touching, they can be touching but the distance is a edge case that one or both 2d polygon are degenerated, or also pure numerical errors in ther clipping routines.
The assert is a recovery function that try to recover from any of those cases and still fail to get an intersection. I have never had the case when it happens. this is a very rare case that will have less than on in a million and that's conservative estimate.

the reason is there was that I was planning to make it that if this was a frequent event, then the routine can return the minimum transaction distance and the normal of the 2d plane as the one single contact. but since I have never seem it, there is not need to that.
I will simply comment out the assert. and put this assert instead.
dgTrace (("If this is a frequent event, this routine should return the translation distance as the contact point\n"))

[JernejL]

Ok, i will remove that assert, what about this other assert, i also got this one once:

File: ..\..\dgPhysics\dgCollisionCompound.cpp
Line: 252

[Julio Jerez]

That one is a sign of something going really wrong

Code: Select all

bool dgCollisionCompound::dgNodeBase::BoxTest (const dgOOBBTestData& data) const
{
   dgFloat32 separatingDistance = data.UpdateSeparatingDistance (data.m_aabbP0, data.m_aabbP1, m_p0, m_p1);
   if (dgOverlapTest (data.m_aabbP0, data.m_aabbP1, m_p0, m_p1)) {
      dgAssert (separatingDistance > dgFloat32 (1000.0f));


The is no AABB vs AABB or OBB vs OBB check in newton, instead all pairs for close objects are formed when each pair is in the same sector of the broad phase, then the closest distance of that pair is calculated when the contact joint is formed.
then after that, for each pair a closest distance is updated by the relative velocity of the two bodies, each time the distance is reduced by some value, the closest distance is recalculated. and the procedure keep going. when the distance is small enough then the joint is activated and contacts are calculated.

a distance of 1000 between a pair does not mean is wrong, but could be a sign of something wrong.
for example is possible a body enter a very big body, which is hollowed and the close distance is very big. in that case this is normal. But is also possible that a bug happen and an explosion made a body gain a huge velocity and the distance becomes huge.
what the reason is, is difficult to tell without more information.

Next time is happened, check the debug output and see if you see warning print out of bodies gaining huge velocities. For now we let that go.

[JernejL]

Ok, i will ignore this assert for now, i can confirm that before this assert, there were velocity warnings in debug log, i will report if i can find a way to reliably reproduce this.

Interesting that newton has no aabb/oobb check and it still outperforms other engines, it is simply not worth having that check or is performance it gains negligible?

[Julio Jerez]

Having aabb/obb checks is good for discrete collision and keeps the smallest number of pairs.

But it is of very limited usage when the an engine start dealing with ccd or with thousand of bodies.

For such large scenes the cleverness of advanced containers start adding extra burden and the small cost and simplicity of flat arrays of pairs make up for the extra cost of complex data structures.

This is why a changed to a flat arrays and we are having all these problems.
Think about, a scene of say 1000 boxes all colliding, will have on average about 12 to 20 pair per boxes, let us is say is 20, so we get 20000 pair to check.

Using obb those 20 thousand are reduced to about 10 thousand, and that's what the solver and the narrow collision system deal with, however the high lever broad phase end up making testing those extra 10000 every frame.

Not using obb, the 20000 are form and the distance between them is calculated,
Them the distance is integrated by their relative velocity, and when the distance is reduced by the diagonal, it is recalculated again.
This process is data parallel and produces the 10000 active pairs the obb system produces.
All we need is one extra thread and to be equal to an obb system, but in return the system is
scalabled and deal naturally with ccd.

hey I jult realized that assert is actually a bug, there is not reason that the distance between two aabb or two obb should be large than 1000.0 or any finite number.
in fact the distance always come to be zero, my guess is that the meant to be a positive value not some as arbitrary as 1000.
I am removing the assert.

[JernejL]

Thanks for the indepth explanation, ofcourse with multithreaded architecture approach has to change,i am still learning the multithreaded paradigm.

The assert - no crashes and so far, no problems whatsoever