Page 1 of 1
Assertion in btConvexShape.cpp
Posted: Tue Jun 29, 2010 7:36 am
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.
Re: Assertion in btConvexShape.cpp
Posted: Tue Nov 01, 2011 2:38 am
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---
Re: Assertion in btConvexShape.cpp
Posted: Tue Jun 12, 2018 12:44 am
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
Re: Assertion in btConvexShape.cpp
Posted: Thu Jun 14, 2018 3:27 pm
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.
