Physics not applied even though collisions are triggered

Hello, i recently started with JME and came to a problem with Physics and collisions.

public void simpleInitApp() {
BulletAppState bulletAppState = new BulletAppState();

    Spatial groundModel = assetManager.loadModel("Scenes/groundScene.j3o");
    loadModel.setUserData("id", "floor");
    CollisionShape sceneShape = CollisionShapeFactory.createBoxShape((Node)loadModel);
    RigidBodyControl sceneControl = new RigidBodyControl(sceneShape,0f);
    Sphere sphere = new Sphere(8, 8, 0.1f);
    Geometry sphereGeo = new Geometry("sphere", sphere);
    Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
    mat.setColor("Color", ColorRGBA.Blue);
    sphereGeo.setLocalTranslation(5, 10, 0);
    sphereGeo.setUserData("id", "sphere");
    SphereCollisionShape sphereShape = new SphereCollisionShape(0.1f);
    RigidBodyControl sphereControl = new RigidBodyControl(sphereShape,0.1f);
    bulletAppState.getPhysicsSpace().addCollisionListener(new PhysicsCollisionListener() {
        public void collision(PhysicsCollisionEvent event) {
            Spatial nodeA = event.getNodeA();
            Spatial nodeB = event.getNodeB();
            System.out.println(nodeA.getUserData("id")+" with "+nodeB.getUserData("id"));
    Spatial glassBox = assetManager.loadModel("Models/glassBox.blend");
    glassBox.setLocalTranslation(5, 5, 0);
    glassBox.rotate(0.1f, 0, 0);
    glassBox.setUserData("id", "box");
    CollisionShape boxShape = CollisionShapeFactory.createMeshShape(glassBox);
    RigidBodyControl boxControl = new RigidBodyControl(boxShape,0f);


It is simple application with a sphere, box(with hole in it) and flat “terrain”. The box and terrain are static and not moving and sphere is dropping down by gravity. That works, but there is no Physics applied to this sphere when it is passing through the other two objects. What is weird is that collisions are actually registered by the collision listener with correct objects. But the sphere only drops straight down without bouncing off the box and terrain. Does anyone know what could cause this? I tried changing ccdThreshold, nonMesh colision shapes in RigidBodyControl like PlaneColisionShape,SphereColisionShape, tried lowering actual speed of BulletAppState, but that didnt solve the problem so far.


What i found out is that if im using basic SphereCollisionShape or BoxCollisionShape for the “ground” or the box it actually applies physics. But collision with collision shapes from CollisionShapeFactory does not. More precisely if i use createMeshShape method for the “box”, it creates collision shape that is same as my model, but no physics are applied. createDynamicMeshShape method on the other hand creates box-like collision shape (without the hole) and applies physics. So i guess the only solution for now is to use compound collision shape to combine the basic ones so it matches as close as possible and it should work.

What version of jme are you using? On which platform?
Try also to enable the debug: bulletAppState.setDebugEnabled(true);, and post a screenshot.

this is with debug enabled. and platform would be java 1.8 on jMonkeyEngine 3.1-beta1 version.

Sorry, i meant to say the OS.
And, i forgot to ask, are you using bullet native or jbullet?

Ok no problem, im currently running on Windows 7. And im using jm3-bullet library, i tried jm3-jbullet library, but that just causes java.lang.NoClassDefFoundError: com/bulletphysics/collision/dispatch/CollisionConfiguration on start on line, where i attach BulletAppState to stateManager.

Ok, the code and the screenshot looks fine to me. It might be related to this [SOLVED] Native Bullet x86 crash - #2 by RiccardoBlb .
Try to recompile it as suggested in that topic and see if it works.
Or if you want to use jbullet, you can search the forum for the error, it’s caused by missing libraries and it can be fixed easily.

Well that is nice suggestion, but not sure how it is related. The linked topic is about fatal error occuring with bullet library and it is related to wrong build for 32bit jre. I, on the other hand, have no errors and have 64bit jre, so i dont think these two are related, but anyway thank you for pointing that out.

In your code, I don’t see anywhere that boxShape is used? Is something missing or is that the issue?

No, i mean related to the fact that the build is broken because there was an issue in the build script, for both 64 and 32 bit.

My guess is that the current builds are not in sync with the bindings and this may cause all the weirdness you are experiencing and a lot more.

before i posted the code here i cleaned it of comments unused pieces of code from my tries to solve this including that line, which i forgot to delete.

So then your box has no shape?

How about you post the real code instead of the code that isn’t really real?

I dont know how you came to this conclusion. The code is real and the one that is being used. There was just a few unused lines i forgot to clean up. So yes i didnt use CollisionShape on neither box nor the floor. It is there because i tried to use them, but it didnt work and in some examples they didnt use them either. But i edited the post so it uses CollisionShape. It doesnt matter the problem still persists and physics are not applied, but collisionListener is triggered.

it looks like that it isnt caused by wrong build, because i was able to actually create collision and physics, but it seems that different collision shapes behave differently based on type of the object.
From this wiki page i cant have mesh shape interact with dynamic spatial. Is there other way to easily create precise collision shape other than compound shape made from basic shapes?

The wiki says you can’t use MeshCollisionShape for movable spatials, and that collisions between mesh accurate shapes can’t be detected (ie. Gimpact vs Gimpact & Gimpact vs MeshCollisionShape). The latter is not true with the latest source.

In your code, the box is static so it should work fine…
If you need to have it dynamic, you can either use gimpact shape with latest source, but it’s really heavy, or use my bindings for V-HACD (search the forum for them) that decompose the mesh in a compound shape made of many hull shapes that is fine unless you need 100% accuracy.

I’m stick to my initial theory though: it may be caused by the broken build. I say that because, i had a similar issues with mesh shapes, even though, for me it was happening randomly and from your post it seems it happens everytime to you.

Ok thank you. I tried to build whole SDK with gradlew but got error about unsuported major.minor version 51.0 of java, which is strange because “java -version” clearly states i have java 1.8 installed.

Do you have any idea, what could cause this? Do i need to establish my own gradle instalation? Would it be possible for you to upload the built library, if its some awkward problem, please?

Maybe you have another version installed and for some reason gradle is using it? I’m not familiar with windows… so i can’t really help much for this.

Note: the windows library is crosscompiled from linux, and it should work but i didn’t test it yet.

What is JAVA_HOME pointing to?

Thank you pspeed completely forgot that java 1.8 doesnt use java_home anymore and ofc old version was there.

well i tried the new build and it is the same as before. Could it be something wrong with the model of my box?

Hard to say without seeing the model… maybe wrong normals?

You could make a SSCCE ( ) if you want better help.