Bullet 2.81

Development
1

@normen



Hey, I tried to update bullet from 2,80 to the svn version.

Just to save you some time, when you do, (and anyone else attempting this for whatever reason).



Their cmakefile is not compatible with mingw under windows anymore, you will have to override a few if’s (mostly anywhere where it tests for _MSC_VER define), since else you will get no btMultiThreaded.a and no debug support (eg assertions).





Also I found after getting btAssert to work, that always a call to shape->calculateLocalInertia(mass, localInertia); is done, for all shapes that are only allowed to be static, this causes assertions being thrown,



eg.

Code:
void btTriangleMeshShape::calculateLocalInertia(btScalar mass,btVector3& inertia) const { (void)mass; //moving concave objects not supported btAssert(0); inertia.setValue(btScalar(0.),btScalar(0.),btScalar(0.)); }

This would be simple but effective solution, since all statics are mass=0 and dont need a initia because of this
Code:
/* * Class: com_jme3_bullet_objects_PhysicsRigidBody * Method: createRigidBody * Signature: (FJJ)J */ JNIEXPORT jlong JNICALL Java_com_jme3_bullet_objects_PhysicsRigidBody_createRigidBody (JNIEnv *env, jobject object, jfloat mass, jlong motionstatId, jlong shapeId) { jmeClasses::initJavaClasses(env); btMotionState* motionState = reinterpret_cast<btMotionState*>(motionstatId); btCollisionShape* shape = reinterpret_cast<btCollisionShape*>(shapeId); btVector3 localInertia = btVector3(); if(mass != 0){ shape->calculateLocalInertia(mass, localInertia); } btRigidBody* body = new btRigidBody(mass, motionState, shape, localInertia); body->setUserPointer(NULL); return reinterpret_cast<jlong>(body); }
5 Likes
2

Cool, thanks. The local inertia shouldn’t do any harm, but its true that its silly to compute it for static collision shapes. I hope the cross-compile still works but anyway theres not many changes in 2.80 that I’d want. The GPU pipeline isn’t done yet anyway so maybe they fix it with 2.81 or so :wink: Having to apply patches to the source would be quite hackish…

3

Yes, it does no harm, but disables the possibility to use btAssert for debugging.



Else than taht i found no difference between the version that is relevant for us.



The only (reliable) way with the source i would see, is to maintain a adjusted branch for jme3 if it does not solve itself.

4
@EmpirePhoenix said:
The only (reliable) way with the source i would see, is to maintain a adjusted branch for jme3 if it does not solve itself.

Yikes, nah, wanna avoid that at all cost.
5

Actually i found another thing that should probably be checked on the java side



btAssert(triangleIndex < (1<<(31-MAX_NUM_PARTS_IN_BITS)));

in btOptimizedBvh, wich in turn we use from the MeshCollisionShape.



In short we should do a check that no more than 2097152 indexes are used. (in a single shape)

Code:
// 10 gives the potential for 1024 parts, with at most 2^21 (2097152) (minus one // actually) triangles each (since the sign bit is reserved #define MAX_NUM_PARTS_IN_BITS 10

they use a single unsigned int, to store a partid from the treestuff and the actuall index it refers to.
2 Likes