Null Objects in Collision Callbacks on Android Resolved

I finally found some time to look into why native bullet collision callbacks were being executed when the TYPE was set to TYPE_ADDED (which is an int = 0).

There are 2 ways that the PhysicsCollisionEventFactory gets creates a collision event. If the queue is empty, it creates a new PhysicsCollisionEvent by calling the contructor of PhysicsCollisionEvent with the parameters of the type and the objects. The other way is to reuse the event from the queue if the queue is not empty by calling the refactor method of the event.

When the refactor method is used, the parameters of type and objects are set, but if the new event is created using the constructor of PhysicsCollisionEvent, the parameters given to the constructor are not set. Therefore, the default values of the PhysicsCollisionEvent are used and returned to the PhysicsCollisionEventFactory. The default value of the type is 0, which is the same as TYPE_ADDED and the collision objects are returning null.

If you look at the jBullet version, the constructor has code to set the PhysicsCollisionEvent internal variables to the parameters given to the constructor. The native version of bullet, however, does not have these lines. Below is a patch file with the missing code in the constructor.


This patch file was generated by NetBeans IDE

Following Index: paths are relative to: D:UserspotterecDocumentsjMonkeyProjectsjME3srcbulletcomjme3bulletcollision

This patch can be applied using context Tools: Patch action on respective folder.

It uses platform neutral UTF-8 encoding and n newlines.

Above lines and this line are ignored by the patching process.


— Remotely Modified (Based On HEAD)

+++ Locally Modified (Based On LOCAL)

@@ -53,6 +53,9 @@

public PhysicsCollisionEvent(int type, PhysicsCollisionObject nodeA, PhysicsCollisionObject nodeB, long manifoldPointObjectId) {


  •    this.type = type;<br />
  •    this.nodeA = nodeA;<br />
  •    this.nodeB = nodeB;<br />

this.manifoldPointObjectId = manifoldPointObjectId;



Again, this is only in the native version of bullet. jBullet already has this included.


While figuring this out, I could never get the change to work on Android while the changes took effect on the PC version. I finally figured out that the mobile-impl.xml was replacing my jME3-bullet.jar file from the classpath with the one from the SDK install even though I already had in included in my classpath via the project library page. Would it be possible to only copy the file from the SDK classpath when the file is not already included in the project classpath? The only way I could use my modified jar for bullet was to either modify the global library for jme3-android (which I did not do) or modify the mobile-impl.xml file (which I did). If someone downloads the engine and compiles the engine with the SDK, I’m not sure how they can use the modified/updated engine instead of the original one sent with the SDK without modifying the global library classpath which I’m not sure is a good idea (I think you’ve told me not to do that in the past).



Thanks. You have to change the build script if you want to change the default behavior.

1 Like

Ok. What was interesting was the fact that I don’t have to change the build script when I modify parts of the android system (harness, context, etc.), just the native bullet java code.

Is it possible to get someone to check in the change for me? I don’t have permissions.

Just a reminder for someone to include the patch above so it doesnt get forgotten. Thanks.

@normen <3 x


could you look at the patch above and see if it’s appropriate to commit for me? It’s my last outstanding patch and removing the npe’s when using the native bullet collision callback on Android unless you check for the TYPE in the event.

@normen are you ok with this patch?



Thanks @iwgeric

1 Like