Android bullet vehicle through walls - Resolved

Running into a problem and hoping you could help :D:

My vehicles go through walls on my android version of my lil game.
Doesn’t happen when I run the same code on desktop windows 64.
Developed, built and run using the sdk and jMonkeyEngine 3.0.10.
Target android: Samsung G3 I8190 mini using android 4.1.2.

On my side, the only change when running that version on android is a different input listener. A part from one initialization process run once that can’t have an influence here.

I’ve tried:

  • smaller circuit triangles
  • changing accuracy
  • changing maxSubSteps
  • playing with CcdMotionThreshold (and the sphere method)
  • tried making a bigger collision shape for the hull of the vehicles

Basically, the wheels stay on the track fine, but whenever the hull collides, it just goes through and the wheels follow through.

Doesn’t require a big speed or a big torque, low fps or anything such.
I don’t see any errors in the logs.

At this point, all I can think of is an appState checking distances to determine when a vehicle is out of the circuit, making a boom and putting it back on pretending nothing happened :D. But it really doesn’t fit my agenda.

Any idea? Is the bullet used by android doing something special I should know of? I suspect accuracy changed might not be taken into account, but this is deeper than that.

Any information would be great (such as what bullet is used etc), because I’m pretty out of solutions.

Thanks for any help.

Do you use jbullet or native?
What happens on android if you use the other one?

Android always uses bullet, jbullet is butt slow on androids “VM”.

1 Like

I don’t know :D.

These are the libraries used. They were inserted there by the sdk (dunno if helps):

Thx :slight_smile:

Got ninjaed. Ok, so using bullet.

Thx normen

But i also see the jbullet binding there, so desktop version might use jbullet instead?

1 Like

I haven’t changed anything so I guess it’s using the standard sdk bullet implementation… if I had to guess, I’d say JBullet.

So I guess it might be due to a difference between Bullet and JBullet?

Could also be you mistakenly used a MeshCollisionShape for the car, jbullet is more forgiving when making that mistake.

I use a BoxCollisionShape added to a CompoudCollisionShape:

protected CollisionShape createCollisionShape(VehicleData vehicleData, Vehicle vehicle) {
        CompoundCollisionShape compoundShape = new CompoundCollisionShape();
        BoxCollisionShape collisionShape = new BoxCollisionShape(vehicleData.getVector3f("CollisionVector"));
        compoundShape.addChildShape(collisionShape, new Vector3f(0, 1, 0));
        return compoundShape;
//        return CollisionShapeFactory.createDynamicMeshShape(vehicle.getVehicleGeometry());

But I tested with a MeshShape too just in case.

My circuit is made of a MeshCollisionShape. I’m going from the idea that the circuit can be a MeshCollisionShape if the vehicle is a simple shape?

I’m using a CompoundCollisionShape because I haven’t found another way to translate the BoxCollisionShape upwards so it doesn’t touch the surface.

do you ever move the circuit? as that invalidates the whole MeshCollisionShape.
Also how many polygons does it have? bullet can be a pit picky for larger meshes.

CompundCollision shape should be fine. Btw maybee a hullcollisionshape would be more usefull for a car, anyway that should not be the problem.

createDynamicMeshShape in the ColisionShapeFactory creates a Hull shape.

I’ve tried using margins too, but didn’t help.

@ - Empire_Phoenix
I don’t move the circuit. It is procedurally built where I want it.

Some parts have long triangles, but it fails in the curbs and when meeting obstacles, and those are made of small triangles.

I use a BoxCollisionShape for better performances. I would use it without a CompoundCollisionShape but using that CompoundCollisionShape is the only way I found (well copy pasted from the tutorial :D) to move the collision shape upwards.

@ - normen:
I tried with that method and have the same results. You might have been pointing to that and I missed it.

Tried collisions with a simple RigidBodyControl (no vehicleControl) and it then works fine with a BoxCollisionShapeand and a CompoundCollisionShape.
I also gave impulses following touchs to those boxes and it worked fine (box was blocked by walls).

Grumpf, this is an elusive problem :D.

Tried an even bigger CollisionShape to no result, still, at 1/20th of the speed it goes on fine with desktop, it doesn’t bump on a vertical wall, it goes through it and ends up flying in space.

To me it seems that the wheels work fine but the hull collision shape is messed up when using a vehicleControl.

Sorry, me again, still investigating (well, took a week off) my physical problem under android.

So I ran a debug under desktop and android.

The following elements are the same (or near):

  1. desktop:
    physicsSpace.getRigidBodyList().iterator().next(); = (CarVehicleController) #3098
    spatial = (Node) #3100
    space = (PhysicsSpace) #3095
    enabled = (boolean) true
    added = (boolean) true
    physicsSpace = (PhysicsSpace) #3095
    wheels = (ArrayList) “size = 4”
    tuning = (VehicleTuning) #3102
    joints = (ArrayList) “size = 0”
    motionState = (RigidBodyMotionState) #3107
    mass = (float) 400.0
    kinematic = (boolean) false
    userObject = (Node) #3100
    collisionShape = (CompoundCollisionShape) #3123
    collisionGroup = (int) 1
    collisionGroupsMask = (int) 1
  2. android:
    physicsSpace.getRigidBodyList().iterator().next(); = (CarVehicleController) #830049364280
    spatial = (Node) #830050179456
    space = (PhysicsSpace) #830047605656
    enabled = (boolean) true
    added = (boolean) true
    physicsSpace = (PhysicsSpace) #830047605656
    wheels = (ArrayList) “size = 4”
    tuning = (VehicleTuning) #830049138456
    joints = (ArrayList) “size = 0”
    motionState = (RigidBodyMotionState) #830050074784
    mass = (float) 400.0
    kinematic = (boolean) false
    userObject = (Node) #830050179456
    collisionShape = (CompoundCollisionShape) #830054189544
    collisionGroupsMask = (int) 1
    collisionGroup = (int) 1

The following elements are somewhat different:

  1. desktop:
    vehicle = (RaycastVehicle) #3101
    rayCaster = (DefaultVehicleRaycaster) #3103
    constructionInfo = (RigidBodyConstructionInfo) #3105
    rBody = (RigidBody) #3106
    tempVec = (Vector3f) #3108
    tempVec2 = (Vector3f) #3111
    tempTrans = (Transform) #3112
    tempMatrix = (Matrix3f) #3113
    localInertia = (Vector3f) #3121
  2. android:
    objectId = (long) 1515974832
    vehicleId = (long) 1520065520
    rayCasterId = (long) 1517657112

Posting this in case someone has a spark… because I’m kind of lost.

This is the only problem I’m (completely) stuck with. I don’t know what to do from there.
After that, I can focus on the visuals, making nice tracks and easy stuff.

I’ll build a shrine to anybody that can give me a good pointer :smiley: .

Do you move the terrain shape after you add it to the physics space?

I don’t normen.

I’m very sorry for having wasted you peeps time… I’m a friggin idiot! And it’s genetic, not behavioural… was really careful, but seems at some point I removed a call to setCollisionGroup and setCollideWithGroups. I’ve checked that multiple times but seems I checked it moronically.

As I was told, jBullet can be more forgiving, and probably by defaults makes all objects collide while bullet doesn’t and that’s why the problem only occurred under android.

It now works… thx to all that gave ideas, and very sorry for wasting your time.

Actually the bullet version does that check (collision group vs collide with group) wrong, it was contributed at some point and I didn’t get to fix it yet. But it would have helped to know that you use it at all :wink:

I don’t know what to say haha… I really checked it because it was an obvious potential culprit… would be nice to have some brain unit tests to check it’s working correctly before using it to check assumptions XD.

Anyway, it’s working now perfectly and I’m dancing in circles giggling like an old fool.