Physics doesnt work with latest revision

Hey everybody!

I updated today to the most recent revision of jME (4642), and physics just stopped to work. I get errors:

WARNING: Failed to use physics implementation 'com.jmex.physics.impl.ode.OdePhysicsSpace$OdeFactory' due to Exception while creating factory: java.lang.VerifyError: class com.jmex.physics.PhysicsCollisionGeometry overrides final method hasCollision.(Lcom/jme/scene/Spatial;Z)Z
java.lang.VerifyError: class com.jmex.physics.PhysicsCollisionGeometry overrides final method hasCollision.(Lcom/jme/scene/Spatial;Z)Z,


and then of course:

Exception in thread "main" java.lang.IllegalStateException: No physics implementation was registered nor found!

.
I dont know if it is just my problem or you changed the way how physics is being used. I hope someone sees this and answers.
Thanks.

Seems the latest changes introduced incompatibilities with jmephysics.

The question is, does someone fix jmephysics (which is inactive) or should jme2 remain compatible with jmephysics.



http://code.google.com/p/jmonkeyengine/source/detail?r=4640


Seems to me that "final" modifiers, added in the new revision of jME are the problem (didnt check for anything else though because I am too sleepy atm…).

Maybe they should just be removed, because those functions are extended in physics implementation.

Anyway, I tried to remove them and it actually helped, although I got another error about "final" modifier then, etc etc… I didnt manage to get it working but as I said, I need some sleep. :slight_smile:

Hopefully this matter will be fixed. :slight_smile:

And I would strongly suggest that you keep compatibility with physics (or at least get someone to update it if necessary), because its simple use is imho one of the strongest advantages of this engine.

I just decided to update to the lastest versions today.





and behold I run into this problem.



I really hope someone can fix it!! XD



lol

Core-Dump said:

Seems the latest changes introduced incompatibilities with jmephysics.
The question is, does someone fix jmephysics (which is inactive) or should jme2 remain compatible with jmephysics.

http://code.google.com/p/jmonkeyengine/source/detail?r=4640


If we were going to try to keep jMEPhysics current with jME, do you think we should see about integrating the packages?  It doesn't seem like SOO much source to integrate (not saying that it's easy or simple :p), but it should certainly be doable and would probably be easier to manage...

opinions?

btw, is irrisor out of jME for the most part these days?
sbook said:
(...) btw, is irrisor out of jME for the most part these days?
Yep. He's made it clear that if anyone would like to continue his work he would be okay with that though, so if some very capable successor would like to have full access to the repositories and so forth, it could be arranged, not to mention most appreciated!

Here's the patch for PhysicsCollisionGeometry.java:



Index: src/com/jmex/physics/PhysicsCollisionGeometry.java
===================================================================
--- src/com/jmex/physics/PhysicsCollisionGeometry.java   (revision 203)
+++ src/com/jmex/physics/PhysicsCollisionGeometry.java   (working copy)
@@ -153,17 +153,17 @@
     protected abstract void drawDebugShape( PhysicsNode physicsNode, Renderer renderer );
 
     @Override
-    public void findCollisions( Spatial scene, CollisionResults results ) {
+    public void findCollisions( Spatial scene, CollisionResults results, int requiredOnBits ) {
         // TODO: should this collide with other scenegraph objects?
     }
 
     @Override
-    public void findPick( Ray toTest, PickResults results ) {
+    public void findPick( Ray toTest, PickResults results, int requiredOnBits ) {
         // TODO: should this be pickable
     }
 
     @Override
-    public boolean hasCollision( Spatial scene, boolean checkTriangles ) {
+    public boolean hasCollision( Spatial scene, boolean checkTriangles, int requiredOnBits ) {
         // TODO: should this collide with other scenegraph objects?
         return false;
     }



I'll make a thread in the contribution depot for this, which will have more info on what caused the problem and why we're fixing this in jMEPhysics rather than in jME2

EDIT: See thread here in the contribution depot: http://www.jmonkeyengine.com/forum/index.php?topic=12002.0

As sbook has indicated, I made those methods final and documented how to update subclasses here:

http://www.jmonkeyengine.com/forum/index.php?topic=11903.msg89316#msg89316.



The reason I made them final is, this is a reliable and certain way to make sure that collision-related override methods explcitly handle or don’t handle the new collision bit masks, instead of ignorantly reverting to boolean collision behavior when the caller has specified a precise bit-mask.  If I left them public, third party apps could continue to silently implement bitmap collisions wrong for 10 years into the future.



If I am of the minority opinion here, you can remove the final modifiers or have me do it.  If you do it, please update the JavaDocs to make it very clear that subclasses should override only the bitmask-variants of the method.



For the reason described above, I think it would be better for both jME and third party apps, in the long run,  to leave these methods final.

blaine said:
If I am of the minority opinion here, you can remove the final modifiers or have me do it.  If you do it, please update the JavaDocs to make it very clear that subclasses should override only the bitmask-variants of the method.

For the reason described above, I think it would be better for both jME and third party apps, in the long run,  to leave these methods final.


I don't want to sidetrack this thread into a conversation on the commit in question, but I see no reason why they shouldn't be final other than having to update any subclasses.  Seems to me like a small price for the extra bit of self-protection.