fuzzyZero assertion error

[axelf]

After jumping around my level for a random amount of time the code always breaks on an assertion error at btVector3.h:300 with the vague message:

Assert d:\program files\bullet3-bullet-2.83-alpha\src\linearmath\btVector3.h:300
(!fuzzyZero())

I feel like there's nothing else I can do other than to post here, as I've searched Google for long periods only to find nothing. I don't think a bit of documentation would hurt this project.

I too realize that I sound like an idiot, but looking at that message and the line where it happens doesn't help me a slightest bit.

/Axel

EDIT: version 2.83
EDIT2: the code breaks at world->stepSimulation(1 / 100.f, 100);

[c6burns]

Everyone wants documentation but no one actually does any documenting.

First, it would help if you opened the code to the assert. I'm in 2.82 but I assume it's close enough I am seeing the same thing. Are you normalizing a zero vector?

[axelf]

Everyone wants documentation but no one actually does any documenting.

First, it would help if you opened the code to the assert. I'm in 2.82 but I assume it's close enough I am seeing the same thing. Are you normalizing a zero vector?

This is the code in question. I updated the question with my version: 2.83, sorry.

Code: Select all

/**@brief Normalize this vector 
   * x^2 + y^2 + z^2 = 1 */
	SIMD_FORCE_INLINE btVector3& normalize() 
	{
		
		btAssert(!fuzzyZero()); <--

I'm not using Bullet's LinearMath library for any of my own math, but my own library. That is what confuses me; I have no idea what kind of vector is being normalized.

[kingchurch]

I just changed it to return the vector itself if it's close to zero. Because most of time when you call Normalize() you expect it to do nothing if the vector is almost a 0 vector. Returning a infinitely large value is rarely a good idea.

Everyone wants documentation but no one actually does any documenting.

First, it would help if you opened the code to the assert. I'm in 2.82 but I assume it's close enough I am seeing the same thing. Are you normalizing a zero vector?

This is the code in question. I updated the question with my version: 2.83, sorry.

Code: Select all

/**@brief Normalize this vector 
   * x^2 + y^2 + z^2 = 1 */
	SIMD_FORCE_INLINE btVector3& normalize() 
	{
		
		btAssert(!fuzzyZero()); <--

I'm not using Bullet's LinearMath library for any of my own math, but my own library. That is what confuses me; I have no idea what kind of vector is being normalized.

[xexuxjy]

Actually it's probably a bad idea to return a 'near-zero' vector from a call to normalise, as you expect in code to have a normal vector as a result of the call. blowing up in the call to normalise will at least give you a chance to figure out how/why/where you're trying to normalise a zero vector rather than getting lots of NaN's later in your code.

[lunkhound]

The problem is in the calling code. Some code in Bullet somewhere is normalizing a zero or nearly zero vector. We really need to see a call-stack to diagnose this further.

[Silverlan]

I apologize for resurrecting this fairly old thread, but I'm using the bullet 3 svn (State: 2015-07-30) and I'm having the same issue.
I have a capsule character controller and a bunch of static triangle meshes, and at completely random times the fuzzyZero-assertion axelf has mentioned occurs.
This is the call-stack:

Code: Select all

>	shared.dll!btVector3::normalize() Line 300	C++
 	shared.dll!btQuantizedBvh::walkStacklessTreeAgainstRay(btNodeOverlapCallback * nodeCallback, const btVector3 & raySource, const btVector3 & rayTarget, const btVector3 & aabbMin, const btVector3 & aabbMax, int startNodeIndex, int endNodeIndex) Line 493	C++
 	shared.dll!btQuantizedBvh::reportBoxCastOverlappingNodex(btNodeOverlapCallback * nodeCallback, const btVector3 & raySource, const btVector3 & rayTarget, const btVector3 & aabbMin, const btVector3 & aabbMax) Line 805	C++
 	shared.dll!btBvhTriangleMeshShape::performConvexcast(btTriangleCallback * callback, const btVector3 & raySource, const btVector3 & rayTarget, const btVector3 & aabbMin, const btVector3 & aabbMax) Line 228	C++
 	shared.dll!btCollisionWorld::objectQuerySingleInternal(const btConvexShape * castShape, const btTransform & convexFromTrans, const btTransform & convexToTrans, const btCollisionObjectWrapper * colObjWrap, btCollisionWorld::ConvexResultCallback & resultCallback, double allowedPenetration) Line 691	C++
 	shared.dll!btCollisionWorld::objectQuerySingle(const btConvexShape * castShape, const btTransform & convexFromTrans, const btTransform & convexToTrans, btCollisionObject * collisionObject, const btCollisionShape * collisionShape, const btTransform & colObjWorldTransform, btCollisionWorld::ConvexResultCallback & resultCallback, double allowedPenetration) Line 580	C++
 	shared.dll!btGhostObject::convexSweepTest(const btConvexShape * castShape, const btTransform & convexFromWorld, const btTransform & convexToWorld, btCollisionWorld::ConvexResultCallback & resultCallback, double allowedCcdPenetration) Line 142	C++
 	shared.dll!btKinematicCharacterController::stepForwardAndStrafe(btCollisionWorld * collisionWorld, const btVector3 & walkMove) Line 371	C++
 	shared.dll!btKinematicCharacterController::playerStep(btCollisionWorld * collisionWorld, double dt) Line 668	C++
 	shared.dll!btKinematicCharacterController::updateAction(btCollisionWorld * collisionWorld, double deltaTime) Line 110	C++
 	shared.dll!btDiscreteDynamicsWorld::updateActions(double timeStep) Line 617	C++
 	shared.dll!btDiscreteDynamicsWorld::internalSingleStepSimulation(double timeStep) Line 517	C++
 	shared.dll!btSoftRigidDynamicsWorld::internalSingleStepSimulation(double timeStep) Line 97	C++
 	shared.dll!btDiscreteDynamicsWorld::stepSimulation(double timeStep, int maxSubSteps, double fixedTimeStep) Line 457	C++
 	shared.dll!PhysEnv::StepSimulation(float timeStep, int maxSubSteps, float fixedTimeStep) Line 214	C++
 	[...] (Application Code)
 	[External Code]	

I've only been able to reproduce it when there's meshes with btBvhTriangleMeshShape-shapes in the scene.