JOODE vs OdeJava

My investigation into whether JOODE was usable for game development through jME has brought some startling results.



My test:

package test;

import jmetest.*;
import jmetest.input.controls.*;

import com.jme.bounding.*;
import com.jme.image.*;
import com.jme.math.*;
import com.jme.scene.shape.*;
import com.jme.scene.state.*;
import com.jme.system.*;
import com.jme.util.*;
import com.jmex.game.*;
import com.jmex.game.state.*;
import com.jmex.physics.*;

public class StressPhysics {
   public static void main(String[] args) throws Exception {
      StandardGame game = new StandardGame("Stress Physics");
      game.getSettings().setVerticalSync(false);      // We want to see what FPS we're running at
      game.start();
      
      // Move the camera
      game.getCamera().setLocation(new Vector3f(0.0f, 50.0f, -100.0f));
      game.getCamera().lookAt(new Vector3f(0.0f, 0.0f, 0.0f), new Vector3f(0.0f, 1.0f, 0.0f));
      
      // Create a DebugGameState to give us the toys we want
      DebugGameState debug = new DebugGameState();
      debug.setActive(true);
      GameStateManager.getInstance().attachChild(debug);
      
      // Create our GameState
      PhysicsGameState physics = new PhysicsGameState("PhysicsState");
      GameStateManager.getInstance().attachChild(physics);
      
      // Create the floor
      Box visualFloor = new Box("Floor", new Vector3f(), 100.0f, 0.5f, 100.0f);
       visualFloor.getLocalTranslation().set(0.0f, -25.0f, 0.0f);
       TextureState wallTextureState = DisplaySystem.getDisplaySystem().getRenderer().createTextureState();
        wallTextureState.setTexture(TextureManager.loadTexture(TestChooser.class.getResource("data/texture/wall.jpg"), Texture.MM_LINEAR, Texture.FM_LINEAR));
        visualFloor.setRenderState(wallTextureState);
       // Create the physics for the floor
        StaticPhysicsNode floor = physics.getPhysicsSpace().createStaticNode();
        floor.attachChild(visualFloor);
        floor.generatePhysicsGeometry();
        physics.getRootNode().attachChild(floor);
       
        // Create falling boxes
        TextureState ts = game.getDisplay().getRenderer().createTextureState();
       Texture t = TextureManager.loadTexture(TestSwingControlEditor.class.getClassLoader().getResource("jmetest/data/images/Monkey.jpg"), Texture.MM_LINEAR_LINEAR, Texture.FM_LINEAR);
       t.setWrap(Texture.WM_WRAP_S_WRAP_T);
       ts.setTexture(t);
        int boxes = 100;
        for (int i = 0; i < boxes; i++) {
           Box box = new Box("Box" + i, new Vector3f(), 5.0f, 5.0f, 5.0f);
           box.setModelBound(new BoundingBox());
           box.updateModelBound();
           box.setRenderState(ts);
          DynamicPhysicsNode node = physics.getPhysicsSpace().createDynamicNode();
          node.attachChild(box);
          node.generatePhysicsGeometry();
          node.setLocalTranslation((float)(Math.random() * 100.0f) - 50.0f, (float)(5.0f + (Math.random() * 50.0f)), (float)(Math.random() * 100.0f) - 50.0f);
          physics.getRootNode().attachChild(node);
        }
       
        // Update the rootNode
        physics.getRootNode().updateRenderState();
       
        // Wait to activate the scene until we're all done
        physics.setActive(true);
   }
}



OdeJava ran that test pretty well staying consistently above 300fps.  However, when I switched out for JOODE it tried to start, showed me the one frame or two frames and essentially gave me the middle finger and died:

java.lang.ArrayIndexOutOfBoundsException: 50
   at net.java.dev.joode.collision.collider.BoxBoxCollider.collideBoxes(BoxBoxCollider.java:443)
   at net.java.dev.joode.collision.collider.BoxBoxCollider.collide(BoxBoxCollider.java:38)
   at net.java.dev.joode.collision.collider.Colliders.dCollide(Colliders.java:132)
   at net.java.dev.joode.collision.collider.GeomTransformCollider.collide(GeomTransformCollider.java:56)
   at net.java.dev.joode.collision.collider.Colliders.dCollide(Colliders.java:120)
   at net.java.dev.joode.collision.collider.GeomTransformCollider.collide(GeomTransformCollider.java:56)
   at net.java.dev.joode.collision.collider.Colliders.dCollide(Colliders.java:132)
   at com.jmex.physics.impl.joode.JoodePhysicsSpace.call(JoodePhysicsSpace.java:590)
   at net.java.dev.joode.space.Space.collideAABBs(Space.java:309)
   at net.java.dev.joode.space.octtree.OctTreeNode.collide(OctTreeNode.java:241)
   at net.java.dev.joode.space.OctTreeSpace.collide(OctTreeSpace.java:69)
   at com.jmex.physics.impl.joode.JoodePhysicsSpace.computeTimeStep(JoodePhysicsSpace.java:598)
   at com.jmex.physics.impl.joode.JoodePhysicsSpace.update(JoodePhysicsSpace.java:517)
   at test.PhysicsGameState.update(PhysicsGameState.java:21)
   at com.jmex.game.state.GameStateNode.update(GameStateNode.java:71)
   at com.jmex.game.StandardGame.update(StandardGame.java:268)
   at com.jmex.game.StandardGame.run(StandardGame.java:169)
   at java.lang.Thread.run(Thread.java:619)



So, if JOODE can't handle a simple test like this I think it's pretty obvious it's not going to work for a game.  However, if I bump it down to 10 boxes instead of 100 it goes ahead and runs just to let me know that it can still do the basics. ;)

I just ran it again with 20 boxes and it runs for about 10 seconds and then gives the exact same exception.



@Irrisor, any updates from JOODE that you haven't applied per chance? :wink:

Also, I know a few people had mentioned wanting a PhysicsStandardGame type of thing and may have seen my pretty PhysicsGameState…it's really basic, but if anyone wants to use it feel free:


import com.jmex.game.state.*;
import com.jmex.physics.*;

/**
 * <code>PhysicsGameState</code> provides physics encapsulation into a GameState.
 *
 * @author Matthew D. Hicks
 */
public class PhysicsGameState extends BasicGameState {
   private PhysicsSpace physics;
   
   public PhysicsGameState(String name) {
      super(name);
      physics = PhysicsSpace.create();
   }
   
   public void update(float tpf) {
      super.update(tpf);
      physics.update(tpf);
   }
   
   public PhysicsSpace getPhysicsSpace() {
      return physics;
   }
}



I'm probably going to write a more advanced version of this that maintains its own thread instead of via update(), but still is a GameState...let me know if anyone is interested in me posting that.

I'm very interested. I've been waiting 6 months for JOODE to come far enough along so that I could give it a serious try. I'm excited to see someone's working on trimesh/trimesh collisions. I have a really cool rock crawling simulator going with ODEJava but put it aside until I could switch to JOODE. :wink:

darkfrog said:

@Irrisor, any updates from JOODE that you haven't applied per chance? ;)

test it with the joode svn version :)
in case it's still not working you should report it over at jgo

I'll try to give that a shot tonight.

@darkfrog: I'd love to get my hands on your revised PhysicsGameState if and when you update it. Please bear me in mind when you do!

Thanks.



(By the way, why is everybody interested in JOODE over ODEJava? Must be better?)

I've been reading about various physics impementations all over this forum and it just seems that everybody is having problems in some form or another. I get the impression a lot of people are finding themselves bodging the physics together, creating innefficient wrapers, just to get around what should be trivial issues. Then I came across someones semi-faked simple physics alternative (simplephysics-octree).  Like yourself and others I dont need full physics, just basic bouncing around from collisions, no rotation - so I think it might be worth checking out.

I am finding jME-Physics well suited for what I'm doing, but anything extreme or complex I wouldn't trust ODE to handle.

Haha, I

I think he would readily agree that ODE is just not capable of handling too much or too precise scenarios. He's done a great job on jME-Physics and it's no reflection on that, but rather ODE that he decided to wrap around.  If we could get jME-Physics to wrap around PhysX or another good one then jME-Physics would be awesome for any circumstance.

nods

Well if you want to use my binding feel free.

I believe eventually we shall, but probably after everything jME-Physics needs to be functional has been completed.  :slight_smile:



In fact, you might consider creating a jME-Physics implementation using it yourself since I know you're a jME'er anyway and what better way to utilize your PhysX implementation than with jME-Physics? :wink:

Yes I'm a JME'er but unfortunately I started my project long before I've heard of JME physics or even JME (I used Java3d). I used raw Odejava

which I'm now in the process of replacing with PhysX.

So I prop would not have any time to implement this but I will of course keep implementing the

binding itself.




Oh come on…you know you want to…I'll be your best friend…if you really cared for jME you'd do it…okay, I'm out of manipulative arguments.



Seriously though, it would probably save you a lot time in game coding if you were using jME-Physics. :wink:



…so that was still partially manipulative, but well-reasoned at the same time.



Anyway, once you are much further along I might be interested in working on the jME-Physics implementation for it, so keep us updated as to the progress.

LOL ! Ok you have me convinced I'll do it when I get the time.

YAY! :slight_smile:

cool :slight_smile: