Jbullet-jme CollisionShape.ShapeTypes.MESH assertion failure

Afternoon all,



I've come across some quirky behaviour using the MESH collision shape in jbullet-jme.



I'll start by describing the scenario, it's a simple game and a Spatial is loaded from a url to an XML file.



Spatial groundMesh = XmlModelLoader.loadModel( MeshFile.Ground.url );



That all works fine - it's standard JME stuff, next to create the physics bounds


CompoundCollisionShape composite = new CompoundCollisionShape();
composite.addChildShape( new MeshCollisionShape( (TriMesh) groundMesh ), new Vector3f( 0f, 0f, 0f ) );
PhysicsNode ground = new PhysicsNode( groundMesh, composite, 0f );



Creating a compound shape consisting of only a MeshCollisionShape works fine.

...However, when the physics node creation is done with the following line instead:


PhysicsNode ground = new PhysicsNode( groundMesh, CollisionShape.ShapeTypes.MESH, 0f );



or


PhysicsNode ground = new PhysicsNode( groundMesh, new MeshCollisionShape( (TriMesh) groundMesh ), 0f );



Despite the lines being semantically similar to the composite shape (chiefly, creating a mesh collision shape from the TriMesh) there is this problem when assertions are turned on:

SEVERE: Main game loop broken by uncaught exception
java.lang.AssertionError
       at com.bulletphysics.collision.shapes.TriangleMeshShape.calculateLocalInertia(TriangleMeshShape.java:140)
       at com.jmex.jbullet.collision.shapes.CollisionShape.calculateLocalInertia(CollisionShape.java:58)
       at com.jmex.jbullet.nodes.PhysicsNode.preRebuild(PhysicsNode.java:232)
       at com.jmex.jbullet.nodes.PhysicsNode.rebuildRigidBody(PhysicsNode.java:220)
       at com.jmex.jbullet.nodes.PhysicsNode.createCollisionShape(PhysicsNode.java:746)
       at com.jmex.jbullet.nodes.PhysicsNode.<init>(PhysicsNode.java:139)

Cause in jBullet, TriangleMeshShape line 140


@Override
public void calculateLocalInertia(float mass, Vector3f inertia) {
   // moving concave objects not supported
   assert (false);
   inertia.set(0f, 0f, 0f);
}




Invoking method from jbullet-jme


public void calculateLocalInertia(float mass, javax.vecmath.Vector3f vector){
   if(cShape==null) return;
   cShape.calculateLocalInertia(mass, vector);
}



This is all fine, it looks like a precaution in jbullet to prevent the problem of having to apply forces to mesh shapes, which is understandable, as frankley they could look like anything

Hi,



the MESH collision shape type is not meant to be dynamic. For dynamic meshes the GIMPACT collision shape type should be used. Note however that it only works correctly in the SVN version of jbullet-jme yet.



Using this forum is just fine.



Cheers,

Normen

Right, it's good to know there's the GIMPACT to support dynamic mesh shapes.



The MESH collision shape is meant for static objects then?



I ask because the assertion error was with a static MESH collision shape - not a dynamic one.

A collision shape being made static by setting mass as 0f (from a comment in a test class stating that by setting the mass as 0f the collision mesh is assumed to be static), is this the right way of making the collision shape static? - if so, wouldn't be expecting to encounter the assert problem.





Good stuff, I'll continune to post 'ere  :smiley:




Did you try the svn version? I recently changed some errors in the mesh converter that never made any problems because the data in question is never used by the mesh collision shape type. Maybe when they get asserted problems arise.

Yes, I'm working from the SVN (Checked out revision 488)



I develop with the assertions enabled (-ea flag for the JVM), I've read that by default assertions are disabled, so unless you explicitly put the '-ea' in the VM options, it looks like assertions will be ignored.



The stacktrace identifies the problem line in jbullet code as

com.bulletphysics.collision.shapes.TriangleMeshShape.calculateLocalInertia(TriangleMeshShape.java:140)


assert (false);


So it makes perfect sense that you'll only get the problem with assertions enabled, so unless you enable them for the run VM options you are not going to encounter this problem.

The cause is from jbullet-jme calling cShape.calculateLocalInertia() that causes the assertion problem. I'm not claiming to know anything about that method, but having downloaded the jbullet SVN I do know the source (that assert line).

The jbullet method jbullet-jme is calling just sets the values held by the given reference to zero


      inertia.set(0f, 0f, 0f);


jme-jbullet wise it may be worth overriding the calculateLocalInertia() in MeshCollisionShape with something like this:


    public void calculateLocalInertia(float mass, javax.vecmath.Vector3f vector){
        if(cShape==null) return;

   assert mass == 0f: :

I added a fix to the svn to avoid calling of setLocalInertia() for mesh collision shapes. That should fix the assertion error.

Cheers,

Normen

Norman, I've just checked the latest SVN, works a treat - no more assertion failure  :smiley: thanks for the prompt replies and swift fix!



Regards

Chris