Posts
Search
Contact
Cookies
About
RSS

JavaFX with Ode4J (physics!)

Added 16 Apr 2015, 2:51 p.m. edited 19 Jun 2023, 3:05 a.m.

jfxOde4j


Well I have to say I was quite disappointed when looking round for a pure Java physics library and I'm most grateful for the quality of Ode4j ! It seems to fit in quite nicely :) Despite initial misgivings about lambda's I have to say I'm now a convert! Not just with JavaFX but take this example of doing a collision callback in ODE   Normally you'd do this...

    public void partOfAnUpdateMethod() {
        if (!pause) {
            space.collide(null, nearCallback);
        }    
        ...
    }
        
    private static DNearCallback nearCallback = new DNearCallback() {
        @Override
        public void call(Object data, DGeom o1, DGeom o2) {
            nearCallback(data, o1, o2);
        }
    };
    
    private static void nearCallback (Object data, DGeom o1, DGeom o2) {    
        ...
Not quite as horrid as an anonymous class (embedded in a parameter) but still a little unwieldy! Using a Lambda you can instead do this... (Can you tell I'm not a fan of anonymous classes!)
    public void partOfAnUpdateMethod() {
        if (!pause) {
            space.collide(null, (d,o1,o2)->nearCallback(d,o1,o2));
        }    
        ...
    }
    
    private static void nearCallback (Object data, DGeom o1, DGeom o2) {    
        ...
Now I know the syntax could be better -> doesn't mean anything in English, and so makes it less accessible to the novice, but I know which code I'd prefer to read and maintain. I ended up making a nice little PhysObj class to "weld" JavaFX and Ode4J components together. It builds on my earlier JavaFX work and utilises my Pivot class so you can hang multiple visuals onto it and they will all be effected by the Ode4j body in the PhysObj. Encapsulating a new shape type (for example a triangle mesh) is just a case of extending PhysObj and should (famous last words?) be fairly trivial, I've supplied three extended classes to encapsulate boxes, spheres and cylinders. And speaking of cylinders I'm guessing this version (of Ode4j) is using the CCD collider by default as cylinders actually collide, and generally behave as you'd expect! (but I guess that's a problem from long ago) Indeed with just 24 iterations per step, the simulation was stable and well behaved with 50 odd primitive shapes in proximity enough to give plenty of collisions everything looks good and solid... Updating the visual objects with their Ode4J counterparts was really simple too, while just copying the whole 4x4 matrix would probably have been more efficient I ended up just using the Ode4J bodies rotational quaternion and position... One minor issue (and issue is probably a bit strong!) was that Ode4J's quaternions and vectors don't have named "gets" like getX,getZ etc but instead have get0(), get2() so I had guess which was W as some people use a W,X,Y,Z order and some use an X,Y,Z,W order... and it was late... One thing JavaFX should do in future is allow for much tighter and lightweight frameworks and a lot less library path nightmares! You can grab the full example code here jfxOde4j.tar.gz