jME Physics

Me and DP are going to post updates concerning the physics system (demoed here) on this thread.



Discussions should also be kept here :slight_smile:



EDIT: See the PhysicsSimpleTest on how to set up a PhysicsSystem and adding objects to it.



EDIT2: Download zip from here

Some changes made to PhysicsObject/contact handling.



package com.jme.jmephysics.contact created, containing a class called ContactHandler.



It should be used together with PhysicsObject, which now has a setContactHandler(ContactHandler).



The purpose of this is to make contact handling (e.g. bouncing) user definable.



http://www.myjavaserver.com/~digiwired/physicsSystem.zip

This is so you dont have to create like 8 different PhysicsObjects for 1 player just to handle different contacts in one level. You need 1 PhysicsObject and a different contactHandler for each level…alot simpler :slight_smile:

This adds the terrainblocks of a terrainpage to the physics system:

for(int i = 0; i < terrainPage.getQuantity(); i++) {
    TerrainBlock tb = (TerrainBlock) terrainPage.getChild(i);
    new SimplePhysicsObject( (Geometry) tb ); // SimplePhysicsObject from jmetest.physics
}



I suggest you look at the PhysicsSimpleTest to see how to set up the physics system and to add objects to it.

Per, i think we should have TerrainPage support built in. Il work on that now.



DP

How about a Utilities class? It could have static methods like:


public static void addToPhysicsSystem(TerrainPage tp) {
    for(int i = 0; i < tp.getQuantity(); i++) {
        TerrainBlock tb = (TerrainBlock) tp.getChild(i);
        new SimplePhysicsObject( (Geometry) tb );
    }
}

TerrainPages can be made up of four TerrainBlocks or four TerrainPages.



So, careful with the casting, you need to check the children as you might have to travel down the quadtree a few levels.

True true… it maybe could work like this then:

public static void addToPhysicsSystem(TerrainPage tp) {
    for(int i = 0; i < tp.getQuantity(); i++) {
        if (tb instaneof TerrainBlock {       
            TerrainBlock tb = (TerrainBlock) tp.getChild(i);
            new SimplePhysicsObject( (Geometry) tb );
        }
        else addToPhysics( (TerrainPage) tp.getChild(i) );
    }
}



or something? :)


tp instaneof TerrainBlock



hehe, but tp will never be an instance of TerrainBlock as it is a terrainPage :)

Per, dont worry, im on it...Im also working on giving a "Spatial" which can be a node and applying a new PhysicsObject to each of Geometries in that node. So it doesn't matter if its a TerrainPage, a TerrainBlock or a 7 Headed Dragon with wings as seperate physical objects...it will all be accounted for. And it will be fast, so no performance hit either...

DP :)

hehe, but tp will never be an instance of TerrainBlock as it is a terrainPage icon_smile.gif

Hehe, by bad :)

public static void addToPhysicsSystem(TerrainPage tp) {
    for(int i = 0; i < tp.getQuantity(); i++) {
        if (tp.getChild(i) instaneof TerrainBlock) {       
            TerrainBlock tb = (TerrainBlock) tp.getChild(i);
            new SimplePhysicsObject( (Geometry) tb );
        }
        else addToPhysics( (TerrainPage) tp.getChild(i) );
    }
}



Im also working on giving a "Spatial" which can be a node and applying a new PhysicsObject to each of Geometries in that node

Sounds good :)

The engine currently can not do static meshes because ode dose not support them. Is there any way to tell ode to use jme’s collision detection to validate the ode collision.


The engine currently can not do static meshes because ode dose not support them. Is there any way to tell ode to use jme's collision detection to validate the ode collision.


Umm...yes it does support static meshes.....perhaps you mean something else?

And yes, there is a way to use jME's triangle accurate collision detection to furthur collide them to make the contacts appear more realistic. There is a class now called ContactHandler that this will go into.

The new release will show you an example of how to use jME's collision detection with ODE's...

DP

:// It was a typo, I meant dynamic. ://

umm…you might be super embarrased now when you find out that ODE does support dynamic objects. And thats why you have ball that moves due to gravity :slight_smile:



But we dont support super dynamic objects like cloth because cloth absorbs some energy from the momentum of the object, so its going to be a tiny weeny bit difficult to do cloth simulation.



But im sure we can do it… :slight_smile:



DP

I guess you mean dynamic meshes, like in models. If that’s the case, are you sure it isn’t enough passing its bounding volume as the geometry?

"Per" wrote:
I guess you mean dynamic meshes, like in models. If that's the case, are you sure it isn't enough passing its bounding volume as the geometry?

No. There are cases where the bounding volumes collide when the dynamic meshes do not. For example, in my game, one moving object should be able to move through holes in anther.
"kevglass" wrote:
I think he/she means any moving object represented by a TriMesh. There currently not working in ODEjava since we don't have that transform updating thing yet.

Kev

I'm also interested in this. Is it currently possible? ie:
How to update a user controlled object in a JME physics enabled system so ODE is in sync with the translations/rotations from the player? (at a collision detection level of triangles).

pc

Hello all, I’m new on this forum! :smiley:

I’m currently using jME for building a simple space shooter game.



The jME and ODE integration looks very promising!

I’m switching to using it instead of plain javaode, but have some questions / suggestions:





PhysicsObject does not have a reference to the ODE Body object. Is there some reason for this?



Currently updating the forces affecting a body has to be done though PhysicsSystem, which looks up the body object (based on it’s name, so it also requires all objects to have unique names - which my game doesn’t have at the moment).



It seems the most object oriented way would be to be able to tell a PhysicsObject directly the new force, torque, etc. to use. I also foresee a need to query things like the velocity of a PhysicsObject.





I’ll probably make these changes locally to my copy of the code in any case, should I submit them somewhere if this design approach is acceptable?





Best regards,

I like the idea of being able to apply forces directly to a physics object. We’ll probably release a new version of the physics system any day now with small fixes and optimizations, so it might be included very soon.



should I submit them somewhere if this design approach is acceptable?


Post them on Code Review, and we'll include them if they turn out to be good :)

How to update a user controlled object in a JME physics enabled system so ODE is in sync with the translations/rotations from the player? (at a collision detection level of triangles).


As kev said, dynamic TriMeshes don't work yet. If you can bare with approximating your player to its bounding volume, you can do this to sync the PhysicsObjects ODE representation to its jME counterpart:


PhysicsSystem.updateODEAccordingToGeometry(myPhysicsObject.getjMEGeometry(), true)



The true at the end resets all forces.