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
drawback:
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?
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
Well, jME uses java.net 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 java.net 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
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
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 :)) . . .
