Assertion in btConvexShape.cpp

Post Reply
ca$per
Posts: 35
Joined: Fri May 21, 2010 2:48 pm

Assertion in btConvexShape.cpp

Post by ca$per »

Hi!
Can someone point me in direction on what can be the cause of this assertion?

Code: Select all

btConvexShape.cpp on line 108 in convexHullSupport() function:
btAssert(ptIndex >= 0);
ptIndex is "-1"
I just don't know what i did wrong, because i don't know what can lead to this error. I'm not doing any multithreading. Using only btConvexHullShape + btSphereShape and rigid bodies along with collision objects. This happens when i create about 30-40 projectiles all at once. They share the same btSphereShape (one for all) and each one is a rigid body with mask set the way they do not interact with each other. Only with colliders (btCollisionObject + btConvexHullShape with about 30-60 vertices each). Collisions are checked by traversing throught contact points list in tick simulation callback.
User avatar
jarno
Posts: 57
Joined: Tue Mar 16, 2010 1:42 am

Re: Assertion in btConvexShape.cpp

Post by jarno »

Maybe the convex shape has no points.
Or more likely, localDirOrg has invalid floating point values. That can happen if the convex shape has points with invalid values.

---JvdL---
PcChip
Posts: 33
Joined: Sun May 20, 2018 3:09 pm

Re: Assertion in btConvexShape.cpp

Post by PcChip »

Hi,

I know this is an old thread but I'm having the same issue,

the strange thing is the behavior of Bullet is seemingly random

one time when I run the program, everything will run perfectly
the next time, the objects will fall to the ground and start jiggling forever
the next time, I'll get this btAssert crash

m_floats contains:
[0] - nan
[1] - nan
[2] - nan
[3] - 0.00000000

is it possible that optimizeConvexHull() is returning slightly different optimized hulls each time the program is run?

picture: https://i.imgur.com/cOm9RiJ.png
User avatar
drleviathan
Posts: 849
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Assertion in btConvexShape.cpp

Post by drleviathan »

The assert in convexHullSupport() is often hit whenever nan has been introduced into the simulation. The initial nan can happen in many ways, but when you get one nan it tends to make everything else nan because:

Code: Select all

1 + nan = nan
2 * nan = nan
3 - nan = nan
4 / nan = nan
Alslo nan can introduce very strange logic bugs because all comparisons with nan evaluate to false:

Code: Select all

(1 > nan) = false
(1 < nan) = false
(1 == nan) = false
My guess: you have a pseudo-instability in your content. Sometimes it is introducing nan and the infection causes some collision logic to misfire. Sometimes it spreads until you hit that assert. How and where... dunno. You'll have to audit the code for places where you might be dividing by zero, or else add sanity-checking where your code sets any property of a RigidBody.

Besides introducing nan by setting values directly you can get it by doing the following:

Constrain or collide a very big massive object against a very small light one.
Provide too small of inertia tensor eigenvalues for the mass+shape of an object.
Post Reply