jME Physics redesign

Hi all,

I'm missing some major features in jME Physics that would require a redesign of the API and implementation:

  • physics engine independent API (to use e.g. NovodeX, PhysX, Newton… not only ODE)
  • composable physics representation (e.g. approximate a mesh with two spheres)
  • allow running physics without loading meshes (e.g. server side)
  • load/store physics representation
  • debugging mode showing physics representations (like with bounds currently)

    additional features/fixes:
  • proper handling of nested nodes (meshes in nested nodes)
  • placement of pivot/mass point
  • better integration with the scenegraph, as well as possible separation

  • API would change significantly

    non-functional benefit:
  • API could be included in jME

    Proposed new API:
  • physics objects and types get specified within the scenegraph like this:

There are PhysicsNodes (dynamic or static) that specify parts of the scenegraph that should be controlled by physics.
Replacing PhysicsType: the idea is that there have to be instances of PhysicsRepresentation (here PhysicsBox and PhysicsSphere) in each PhysicsNode that make up the collision bounds of the physical entities. The representation can be derived from bounds/mesh as before (depicted by the method invocation and creation of the green objects).
The classdiagram would look like this (excerpt):

- jme format gets extended to allow storage of such scenegraphs, a filter may be provided to store only physics/visuals
- Default implementation (ODE) will be provided separately (possibly not even in jME/jMEPhysics but new jme-ode project?)

Anyone knows important aspects (e.g. from other physics libraries) that cannot be regarded this way?

I'm curious to hear your opinions,

Good job Irrisor. I very much like your ideas here.

I personally would like to see a change in the way physical objects are handled.  For example, I would like to see materials make up objects and that be the default means by which collisions are handled.  For example, I could create a PhysicsSphere and set the material of that sphere to be SteelMaterial (which would simply be an implementation of a Material interface with properties) which would make its weight defined by volume and density (which in this case density would be very high).  This could be an easy default behavior and for people that want to "break the rules" of physics to have certain objects behave differently they could do something similar to onContact to change from the default behavior in specific circumstances.  This allows objects to behave as is expected in a world without having to do anything but instantiate the physical object and add it to the world.


Yes, introducing materials would be nice. The only actual material property that I can imagine actually is density. But one can make a table of other values: friction, bounciness, slip - defined for a pair of materials.

That looks very nice, but i'd suggest include the default implementation (ode) into jmex or similiar problems as with this cursed sourceforge cvs may arise and it's always nice to have all the goodies in one place.

The problem with that is for people who care nothing about physics would then be downloading a huge chunk of unnecessary code when they are just trying to check-out jME from CVS.  The abstract API should be in jME in my opinion because it should be quite small and has no implementation.  Also, if we were to include the ODE implementation we'd also have to include the Novodex implementation, the Newton implementation, the JOODE implementation, etc. :-p


Why in the world would anyone not want to have the outstanding jme physics implementations ???

… ok, kidding You're right but then it could maybe reside on the same cvs server as jme does ?

Well, jME uses for its CVS server and jME-Physics uses SourceForge.  We can switch to SourceForge or something else when we get ready to do that we should definitely look into an alternative.


Ok, started working on this today and requested a project for it. Whether this will contain the implementation only (and API in jME) or API plus implementation is still to be decided. Meanwhile I'm going to check in the API there. As soon as the project is approved you can get a glance at the new API :slight_smile:

Please surf to jgo board if you have an account there to vote for approval :slight_smile:

Ok, project is approved in 'general' as 'gaming' lacks admins :-o

Additional new features:

  • Debug mode to show physics collision geometires (like show boundings in jME), dynamics and center of mass
  • set center of mass

    Further status report:
  • Basic API is finished. Advanced geometries, geometry generation, materials and joints still pending.
  • First interactive test is working with ODE implementation.

    I hope I will get back to working on it on the weekend…

Great job Irrisor, I very much look forward to seeing this new API in action.


don't hesitate to…

cvs -d login

cvs -d checkout jmephysics

figure out the source folders :wink:

compile and execute com.jmetest.physics.TestBasicRepresentation


Already looked at some of the source code…looks promising.  I'll try to check it out and play with it some over the weekend if I get an opportunity.


Go Irrisor! cheering :slight_smile:

Ok, got a little bored and made a little game instead on the weekend. But at least materials are in, yay :slight_smile:

Next will be joints…

Update: first joints are in (single rotational or translational axis), most important thing missing atm: trimesh collision geometry… otherwise it starts getting usable, I think :slight_smile:

Do you think it has come to a point where new users should start using it instead of the old one?

Well, the features that are in there work fine, so they could be used. But it does not support all features of the old one yet.

API missing:

  • powered joints
  • attractor and other extensions
  • events (collision, thresholds etc.)

    ODE-Implementation missing:
  • multi axis joints (Ball,Universal,Hinge2,AMotor), powered joints
  • automatic generation of collision geometry (from boundings)
  • debug visualization of trimesh collision geometries

    Additionally I have a new native ode version from the new ode svn repository as there are many improvements (including dynamic trimeshes, cylinder etc.). I'll have to get that one compiled on MacOS, too - pretty hard without a mac (but possible :)) . . .

    So stay tuned

I was a long time away from jME, but what i have found here now is realy great :lol:

I am looking for the things that will come.

Good work irrisor.