jME-Physics Utilizing ODE?

I'm trying to finish up the ODENetworking project and get it released but as I was pulling out jME-Physics from it to truly make it independent to OdeJava I realized that there are some serious complications with this.



There are some changes made to the ODE wrapper specific to jME that make the ODENetworking virtually impossible to use with jME-Physics at its current state.  For example, in jME-Physics you have:



body.setQuaternion(Quaternion);



in OdeJava you have:



body.setQuaternion(Quat4f);



Not exactly sure why we've swapped this out except to maintain consistency with the rest of jME's utilization of Quaternion.  Further, this brings another question.  Why are we using Quaternion instead of the Quat4f provided in the VecMath API?



I would personally think it best to completely remove the org.odejava package from the jME-Physics project and rely on the released JAR by OdeJava.  If this is bad please explain why. :slight_smile:



If we have good reason not to go this route the alternative for functionality would be to add the body.setQuaternion(Quat4f) method back into our modified OdeJava wrapper API.  Just trying to get this all out in the open so we can get it right.



darkfrog

Because jME has it's own "VecMath" packages.



jME-Physics is more or less a binding to ODE nowadays, not to ODE-Java. It did evolve from ODE-Java, but if I'm not mistaken there are actually many fixes in "jME-ODE" that are not even in ODE-Java (yet?).

Hmmm, well this creates a couple serious issues dealing with trying to create an API from the other side.



So this would mean there is no way to provide full integration as OdeJava utilizes Quat4f that is not available in jME and jME-Physics utilizes Quaternion that is not available in OdeJava.



Correct me if I'm wrong but this basically cuts my idea of writing an OdeJava compliant networking API that would also work with jME-Physics impossible?



Okay, so if the response to the former question is "yes", then how much overhead would adding a DummyDisplaySystem with jME-Physics add to a server above the foundational elements of just using OdeJava?



darkfrog

There was some talk in the past about reunifying ODE-Java and jME-Physics. I think, ideally, it would be ODE-Java that's modified to work with different "vec math" packages… unless there will be some kind of major unification on that front any time soon.



The current system of having different forks for different engines seems to have worked out fine, but with an api extention like yours, you can see what the problem is with the approach.

You're not making me feel any better. :-p



Well, I have not done a whole lot of research into all the vecmath APIs out there and didn't really even realize there was more than one being used.  I guess this is really the primary problem I have as this is what it boils down to.  I would suggest we try to push some of this code back up to the OdeJava project instead of holding onto it ourselves and perhaps even push them to use the jME vecmath package if possible?



darkfrog

We chose to remove odejava's dependencies on log4j and vecmath to make jme-physics easier to distribute, and to make it work more closely with jME. It is, after all, jME-Physics.



The problem is the route jME has taken; having it's own logging library and math library instead of using already existing, standard, ones. This makes it hard to write libraries for both jME and other engines.



So, I guess very bad news for you and the rest of us who were looking forward to use your library :frowning:

Well, don't feel too bad, this just forces me into a corner I didn't want to end up in.  It won't work out badly for the rest of you, it just puts a restriction on my networking API I didn't want to end up with.



I guess it's going to end up with me having to support jME-Physics instead of ODE.  I might just work on adding my networking API directly to jME-Physics and try to keep updating the ODENetworking project as well, but this forks my code and puts me in a bad position having to update two projects anything I change anything.  I don't like that. :o



However, won't this issue sort of resolve itself if we move away from jME-Physics being specifically an implementation of OdeJava and make it physics engine indepenedent?  Sure, we have our own version of OdeJava that they may or may not want back, but for the implementation of the ODENetworking we utilize it and perhaps even move back to using the vecmath dependency in the original OdeJava.  Thoughts?



darkfrog

However, won't this issue sort of resolve itself if we move away from jME-Physics being specifically an implementation of OdeJava and make it physics engine indepenedent?  Sure, we have our own version of OdeJava that they may or may not want back, but for the implementation of the ODENetworking we utilize it and perhaps even move back to using the vecmath dependency in the original OdeJava.  Thoughts?


Nah, they won't take our version of odejava -- it would mean that they would be dependant on jME :D

I don't like the idea of reverting back to vecmath and log4j either -- I like the close way jME-Physics is being coupled to jME, and odejava is the only physics engine available to plug in.

What about Newton?



Even if there were no other options we should always develop like there as one day perhaps we might even create a wrapper for the Havok engine or some other commercial engine.



darkfrog

Sorry, expressed myself a bit clumsy there. What I meant was that if jME-Physics's ODE implementation were to use vecmath and log4j, it'd infact be as if jME-Physics itself would be dependant on those packages as ODE would be the only engine implemented/available. I totally agree on having physics engines pluginnable – I actually wanted it that way way back when jME-Physics was taking form (it still is, but even more so ;)).



Newton hasn't got a Java binding AFAIK.

Mojo or Renanse will have to answer on this one, but I think they wanted jME to be as independant on other packages as possible. Like an all-in-one solution.



I also would have liked it better if jME just used existing libraries such as log4j and javax.vecmath.

One of the advantages is of course you can make changes in the code if it's your own. AFAIK javax.vecmath API spawned from Java3D and thus the reference implementation inhereted it's bizzaro licensing schemes. I hope there's a non-reference implementation around these days that the Java ODE binding use and that you use. Because for using the reference implementation you either have to be a "research project" or pass TCK testing, under it's dual licensing scheme:



https://vecmath.dev.java.net/

https://java3d.dev.java.net/jrl.html

https://java3d.dev.java.net/jdl-java3d.pdf



Now see how many words in there you fully understand, and compare that to the jME license.

It's a JSR in progress I believe. Though "progress" is a relative term.