Feature Request - getWorld method in PhysicsWorld

I would like to request that a method be added to PhysicsWorld:



public World getWorld() {

  return world;

}



I am currently writing a Client-Server networking API for OdeJava and I need to access the World directly to avoid having to write jME specific code in my API.



Thanks,



darkfrog

This would expose the ODE-stuff. Not a good idea. We should go the other way round: Hide the things like Contact and such from the jME application.

Why would you want to be ODE-specific but not jMEPhysics specific? It would be much better if the physics engine could be interchangeable…

Why would exposing the ODE objects be a bad idea?  Don't they synchronize to the graphics layers anyway?  If I directly manipulate the position or rotation information of an ODE object directly is it going to cause it to be out of sync with jME?



darkfrog

Oh, and I guess doing an ODE specific networking api is negotiable, but I figured that it would be more beneficial to the gaming community in general to be ODE-specific instead of jME-Physics specific.  This way those poor folks over at Xith could at least have some good element to use in their projects. :wink:



Besides, I don't know of any other physics engine currently being utilized standardly in the Java community, so just in case some other great project comes along that's even better than jME (I know…bite my tongue) developers should make the switch and still utilize the same networking API.  A valid argument would be that another really great physics engine could come along and jME-Physics would be able to switch to using it instead of ODE and the API would still work if I made it jME-Physics specific, but I think at this point that is somewhat less probable.



I would be happy to discuss this further if there are things I haven't considered.



darkfrog

As one would want to synchronize much more than only physics (e.g. ammo, shield, health…), I would suggest to design a universal interface to the applications entities. You should then be able to plug in any physics.

If you code an implementation for jMEPhysics first, it should require minimum efford to use ODE lateron in a possibly other engine.

That's actually a good idea.  Create a separation layer for the networking API and have some sort of Interface to do physics updating.



What I'm currently doing is running an instance of the physics world on the server (ODE only) and then just specifying the server as authoritative and the clients synchronize to it (rather, they get sent messages telling them to synchronize) and the client sends down action events of what the player is doing.  I am currently developing ways for it to be extended to have be able to maintain a variety of messages such as health, shooting, etc.



I'm getting pretty close to the first functional version of the API.  When I've got something working I'll be a little bit better off to determine what I've done right and what I've done wrong.  I'll also hopefully be able to get some good feedback from some people here as for the moment my main priority is providing this to the jME community.



Thanks,



darkfrog

Okay, so I decided to re-architect this networking API and in fact provide two APIs out of it.



The first API (which should be completed by this evening) is a simple Game Networking API that can be utilized for any game in Java.  The system is event driven with a server that can be instantiated on the client and/or server for listening on a port for incoming messages.  The API uses UDP and provides a JNGMessage abstract class that can be implemented for each message type that your game sends.  You can create listeners that receive the messages when the server receives them and then you can pass messages back to the sender.  So far this is working extremely well and I have a few JUnit tests already implemented and working.



The second API, which builds upon the first is the ODE Networking API.  I have updated the the PhysicsWorld with a getWorld() method that returns the underlying OdeJava World object and I utilize that to handle physics updates sent to the client.  I could have written this to be jME-Physics specific, but after careful consideration have decided that would add unnecessary overhead and at this point is not something I see the benefit of.  Further, there might be people on other graphics projects (Xith or maybe straight-up LWJGL and/or JOGL) that may want to use this as well and I don't want to exclude them without good reason.  Also, the jME-Physics requires that spatials be built and a DummyDisplay and that seems like WAY too much unnecessary overhead for the server to be taking on.



I still would like the getWorld() addition to be made to jME-Physics so I can use the straight source from the repository instead of having to update it myself.  I don't see any problems with exposing this as it should remain consistently in sync with the spatials based on the way OdeJava's API is designed and implemented in the jME-Physics project.



darkfrog

The problem is that it's really against the design of the jME-Physics API; we try to make PhysicsWorld be the world – not encapsulate another world.



Hrm… I can really see why you want it there though, so maybe we can throw it in anyway…



I guess that if we'd ever make jME-Physics able to handle physics engines in a plug-in manner, we could make that method specific for the ODE implementation.



Go with your customized version for the time being, and lets hear what Irrisor has to say when he comes back.

Great, thanks buddy. :slight_smile:



darkfrog

Ok, as you really want this method in, darkfrog, and it seems ok for Per, I have added it. I hope it's ok for you that it's marked deprecated:


    /**
     * @deprecated this is an ODE-specific method and may be removed (or moved) if other dynamics implementations are used
     * @return the ODEJava World object
     */
    public World getODEJavaWorld() {
        return world;
    }

It seems strange that you have a problem with this since getPhysicsEntity() on a DynamicPhysicsObject gives you back a Body.  How is this any different?



There needs to be some re-thinking about the jME-Physics project if you really plan on incorporating any other other physics engines in the future anyway.  You might just create jME-Physics as an abstract API and then create a jME-OdePhysics implementing API.  You could have getPhysicsEntity() return an Object that would have to be cast (or another way might be to leave it out entirely and the OdeDynamicPhysicsObject have a getBody() method) and the same could be true for PhysicsWorld and World.



As it stands it seems somewhat inconsistent to have the getPhysicsEntity() not deprecated and the getWorld() be deprecated…see my point?  Either both of them need to be (which I don't like that idea personally, but at least it would be consistent then) deprecated or both of them need to be not deprecated.



BTW, I would like to get developer access to the CVS repository for jME-Physics if possible as I would like to check-in my progress on the PhysicsGroup object.  I promise I won't remove "@deprecated" from PhysicsWorld unless you tell me too. :-p



darkfrog

darkfrog said:

It seems strange that you have a problem with this since getPhysicsEntity() on a DynamicPhysicsObject gives you back a Body.  How is this any different?

It's not different it's just bad, too, but cannot be removed at this time  :( (as you said the interface must be separated from the implementation first)
jmephysics is neither in a consistent nor in a clean state. But it should not get worse  ;)
Per and me are quite busy with reallife stuff, hopefully get's better again.

It's great that you are making progress with the PhysicsGroup! I would recommend posting in the forum first, so one can eventually discuss about it first.

I agree on that it's not necessary to call it deprecated –  just leave a comment saying it's usually a bad idea retrieving it because it's for special, ODE-specific, cases only.


BTW, I would like to get developer access to the CVS repository for jME-Physics if possible as I would like to check-in my progress on the PhysicsGroup object.  I promise I won't remove "@deprecated" from PhysicsWorld unless you tell me too. :-p


Done (but you already knew that) :)