Upcoming Bullet 2.81 release, please test trunk version

Post Reply
User avatar
Erwin Coumans
Site Admin
Posts: 4230
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Upcoming Bullet 2.81 release, please test trunk version

Post by 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
User avatar
majestik666
Posts: 66
Joined: Tue Mar 02, 2010 6:13 am

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by majestik666 »

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

Cheers
Francois
Yildiz-online
Posts: 3
Joined: Wed Sep 26, 2012 3:08 pm

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by Yildiz-online »

Nothing broken for me till rev 2602, i mainly use rigid bodies, ghost and raycast for collision and dynamics.
rtrius
Posts: 43
Joined: Sat May 26, 2012 1:09 am

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by 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.
Attachments
Sphere issue; large box not displayed
Sphere issue; large box not displayed
btSphereShape-btBoxShape_collsion2.jpg (63.8 KiB) Viewed 5704 times
Sphere issue; large box displayed
Sphere issue; large box displayed
btSphereShape-btBoxShape_collsion1.jpg (105.56 KiB) Viewed 5704 times
User avatar
Erwin Coumans
Site Admin
Posts: 4230
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by Erwin Coumans »

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

Thanks everyone for testing!
Erwin
Laurent Coulon
Posts: 29
Joined: Tue Oct 05, 2010 9:36 pm

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by 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.
User avatar
godlike
Posts: 20
Joined: Fri Feb 19, 2010 7:09 pm
Contact:

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by 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
Posts: 43
Joined: Sat May 26, 2012 1:09 am

Re: Upcoming Bullet 2.81 release, please test trunk version

Post by rtrius »

Laurent Coulon wrote: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
Post Reply