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.
[java]
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.
Index: PhysicsCollisionEvent.java
— PhysicsCollisionEvent.java Remotely Modified (Based On HEAD)
+++ PhysicsCollisionEvent.java Locally Modified (Based On LOCAL)
@@ -53,6 +53,9 @@
public PhysicsCollisionEvent(int type, PhysicsCollisionObject nodeA, PhysicsCollisionObject nodeB, long manifoldPointObjectId) {
super(nodeA);
-
this.type = type;<br /> -
this.nodeA = nodeA;<br /> -
this.nodeB = nodeB;<br />
this.manifoldPointObjectId = manifoldPointObjectId;
}
[/java]
Again, this is only in the native version of bullet. jBullet already has this included.
@normen
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).