Upcoming Bullet 2.81 release, please test trunk version

[Erwin Coumans]

Hi,

I'm preparing a Bullet 2.81 release. Can you please download and try out the latest trunk and report if there are issues?

http://code.google.com/p/bullet/downloads/list

Thanks a lot,
Erwin

[majestik666]

Been running r2593 since you posted it,
and seems pretty solid, didn't notice any regression so far.

Cheers
Francois

[Yildiz-online]

Nothing broken for me till rev 2602, i mainly use rigid bodies, ghost and raycast for collision and dynamics.

[rtrius]

Update:
Using Visual Studio 2008;
the problem does not appear in debug mode, only in release mode.

Issue appears to occur around:
btSphereBoxCollisionAlgorithm.cpp:
btSphereBoxCollisionAlgorithm::getSphereDistance(), lines 112-123:

Code: Select all

	
	// Determine the closest point to the sphere center in the box
	btVector3 closestPoint = sphereRelPos;
	closestPoint.setX( btMin(boxHalfExtent.getX(), closestPoint.getX()) );
	closestPoint.setX( btMax(-boxHalfExtent.getX(), closestPoint.getX()) );
	closestPoint.setY( btMin(boxHalfExtent.getY(), closestPoint.getY()) );
	closestPoint.setY( btMax(-boxHalfExtent.getY(), closestPoint.getY()) );
	closestPoint.setZ( btMin(boxHalfExtent.getZ(), closestPoint.getZ()) );
	closestPoint.setZ( btMax(-boxHalfExtent.getZ(), closestPoint.getZ()) );
	
	btScalar intersectionDist = fRadius + boxMargin;
	btScalar contactDist = intersectionDist + maxContactDistance;
	normal = sphereRelPos - closestPoint;

//Original post below
There may be some issues with btSphereShape-btBoxShape collision.
On occasion, the normal appears to point in the opposite direction.


Edit BasicDemo.cpp:

Replace line 28:
#define START_POS_Y -5
with:
#define START_POS_Y -30 //Causes rigid bodies to spawn within the large box rigid body

Change lines 141 and 142 from:
btCollisionShape* colShape = new btBoxShape(btVector3(SCALING*1,SCALING*1,SCALING*1));
//btCollisionShape* colShape = new btSphereShape(btScalar(1.));
to:
//btCollisionShape* colShape = new btBoxShape(btVector3(SCALING*1,SCALING*1,SCALING*1));
btCollisionShape* colShape = new btSphereShape(btScalar(1.));


When btBoxShape is used, the boxes are always pushed out of the large box.

When btSphereShape is used, some spheres move downwards into the large box and others oscillate.
Eventually, the spheres still embedded in the large box are put to sleep.

[Erwin Coumans]

@ rtrius, I disabled the btSphereBoxCollisionAlgorithm again in latest trunk,

Thanks everyone for testing!
Erwin

[Laurent Coulon]

Found the problem. It is one of those annoying situations where floating point math simply fails in release builds.
Essentially the situation was that sphereRelPos.y == closestPoint.y in btSphereBoxCollisionAlgorythm line 122
but sphereRelPos.y - closestPoint.y is not zero, just some small float error.

Replacing line 134
if (dist2 == 0.0f)
by
if (dist2 <= FLT_EPSILON)
fixes the problem.

It is actually pretty cool to see the cube of spheres get shot up and then land back in exactly the same position and reform on top of the box. Much more precise than with convex/convex. Not sure why the different columns of spheres are not all in synch though. I'll have to look into that some day.

[godlike]

I seem to have some CMake issues on linux. For some reason CMake cannot find opengl and glut. I am very sorry I don't have more concrete info. I will try to investigate

-- Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY)
OPENGL NOT FOUND
-- WARNING: you are using the obsolete 'GLU' package, please use 'OpenGL' instead
GLUT NOT FOUND

[rtrius]

Replacing line 134
if (dist2 == 0.0f)
by
if (dist2 <= FLT_EPSILON)

Confirming that this fixes the issue.

Seems to be a floating point rounding error; using /fp:precise
or /fp:strict instead of /fp:fast on BulletCollision(not App_BasicDemo)
also works.

Changing the rounding precision with
e.g. _controlfp_s(&controlWord, _PC_24, MCW_PC) for Visual Studio
also supports this hypothesis.

See also:
http://stackoverflow.com/questions/4682 ... 34#4956334
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323