As David said earlier, it would be great to have the needed PE interfaces for Magicosm.
That, added to the interfaces of Shawn’s applications will be a good starting base of the port.
DZ
After struggling with not-so-trivial things like convex hull collision and response, I can wholeheartedly say that a generic library to take away some of the heavy maths would be a great help.
Keeping it API/renderer independant would be great, nailing it down to one platform would only restrict the number of people who would actually get to use it. Assuming the math isn’t over my head I’d be more than willing to lend a hand. 
Little idea to allow easy integration/usage of 3rd party modules in Xith3d:
Define a abstract class “ThirdPartyGroup” or something (in the xith api); the physics engine then provides an implementation of this class, which you could e.g. plug in the scenegraph on top of the model you want to control/collide/whatever.
this way xith would be clean of any 3rd party stuff and intrgeration should be pretty easy.
this could be used for other stuff like sound/music systems or particle emitters. (or even (ab)used for gamelogic?)
It is nice to see these discussions from you people, many relevant points.
One thing I would like to add at this point, it is realism. I am new to modern 3d, also new to Physics engines, but not new to project management or Java. In my opinion ODE is somewhat tested, feature rich and complete package for production uses, this effort can take a long time to do again.
I think that it is a huge work to do same thing ground up, also the porting (+upkeeping) ODE sounds a big job. I would like to stick to the facts that mostly we developers tend to stare a bit too much of a beatiful structures and designs if there are no factual deadlines (like Xith?). Don’t get me wrong, I would definately like to see native Java ODE library, but I am a realist and an pessimist on this case I feel that creating ODE capable physics engine from ground up just to get rid of single native library and to get nicer Java API does not justify the risks and big work. Think of all the resources that are drawn away from some other things. At least, I would like to see Xith3d people concentrating on Xith3d, it seems such a great project!
It’s whole other case if people need fewer or different features than ODE provides. It is just that making the wheel over and over again does sound too familiar to me.
Anyway, have to see what a flop / success odejava is going to be, just waiting for the dev.java.net people to approve this project… If this takes too long I will put it to downloadable package on some website, after all the project is simple and single INSTALL file is sufficient for most people. There is no magic on this one, it just does the trick, at least on my cases.
BTW I have tested various boxes (long sticks and boxes) and spheres on various structures with this, also I have tested most joints. I have also applied various forces to objects etc. Basic simulations act as they should.
Hi,
I agree with Jani_Laakso. The question is ability to use physics engine in production in some reasonable time, and pure-java/native issues are just matter of deployment. Xith3D, like other JOGL-based engines, anyway have to rely on native code deployment, so I personally think that one more native lib is not a big deal, at least if it is tested well.
[quote]…just waiting for the dev.java.net people to approve this project… If this takes too long I will put it to downloadable package on some website, after all the project is simple and single INSTALL file is sufficient for most people.
[/quote]
I think there is no reason to wait until the project is approved - there is already a big interest for that [I believe], so why should we delay more?
I think we can easily arrange space on some web site [say, xith.org - hopefully William Denniss will support me] to start playing with physics stuff, and then continue on java.net. Also I think most of the peolpe here are technically experienced enough to compile/install things without nice interactive installer, so I don’t see this as a problem also.
Yuri
Ok, I try to snatch some time in a day to put a reasonable package available on some www-site.
Ps. Don’t use your time to set up anything on xith3d.com, I have suitable sites that I can use for this.
[quote]I would provide the default reference implmentaiton of the pure java PE, good enough to support objects moving with mass and velocity colliding with other objects (with callbacks), basically the bare bones of a PE. I would not expect to do something as nice as ODE and provide springs and tension and complex resolution of multiple impacting objects (use a simpler method which should still look good).
Thoughts?
[/quote]
Your thoughts sound very interesting and I would definitely like to see this implemented in Xith3D. As mentioned by other people in older threads it is not possible to create a physics engine which fits every game. It is part of the philosophy of Xith3D to be as flexible as possible and not to rely on a certain API except the JRE (sound: JavaSound/Joal, render: Jogl/LWJGL). How complicated is it to have several physics engines within Xith3D? Following your thoughts it seems that your physics engine interacts very closely with the scenegraph.
[quote]One thing I would like to add at this point, it is realism. I am new to modern 3d, also new to Physics engines, but not new to project management or Java. In my opinion ODE is somewhat tested, feature rich and complete package for production uses, this effort can take a long time to do again.
I think that it is a huge work to do same thing ground up, also the porting (+upkeeping) ODE sounds a big job.
[/quote]
I certainly wasn’t suggesting to recreate a ODE capable Java API. I have a working soft and partial rigid body physics system myself, and yes it’s a fair chunk of code (but then again it’s not as big as a render engine…). But ODE is better supported, open source C++, and a port to Java is “not that bad” ™. It doesn’t use Win libs that would need recreated functionality, etc. etc,.
In any case, I just wanted to make clear that I am talking port, not new art. And this wouldn’t stop anyone from using generated wrappers in any way.
[quote]I agree with Jani_Laakso. The question is ability to use physics engine in production in some reasonable time, and pure-java/native issues are just matter of deployment.
[/quote]
My knowledge of JNI and ODE is vauge at best, but how realistic is it to do a version with ‘just’ a binding to the native library, then gradually convert this to pure java?
[quote]…
I would like to stick to the facts that mostly we developers tend to stare a bit too much of a beatiful structures and designs if there are no factual deadlines (like Xith?). Don’t get me wrong, I would definately like to see native Java ODE library, but I am a realist and an pessimist on this case I feel that creating ODE capable physics engine from ground up just to get rid of single native library and to get nicer Java API does not justify the risks and big work. Think of all the resources that are drawn away from some other things. At least, I would like to see Xith3d people concentrating on Xith3d, it seems such a great project!
[/quote]
A few more notes…
If you think that I don’t know how to make deadline, you don’t know me
I’m not working on Xith3D, so you lose no resources if I was involved in an ODE port project. In fact, this is one way I can finally help out the Xith team IF they choose to use the port. In additional many other people who aren’t working on Xith3D many wish to have a Java ODE port for unimaginable reasons. (Even 2D rendered web games can use 2D/3D physics to cool effect)
Perhaps discussion of this port should be moved from the Xith3D forums.
This is actually a very reasonable idea. Once you have agreed on what the Java interfaces look like you could even parallelize the projects. The JNI based one is likely to get done quicker. The Java based one will be portable and MAY even be a bit faster depending on how much in the way of Java to C context switches the JNI version had to do.
My off the cuff, non-scientific analysis says:
“100% Java implementation guaranteed faster than JNI version” ;-)"
After all my attempts for my faster math chapter, the 1.4.2 JVM JIT beats any JNI that is not seriously batched ( like say for example large ByteBuffers of floats for 3D vertices ).
To make ODE be like that would require a different interface and layer to accept batched up (ByteBuffers) data for C-side ODE processing.
[quote]A porting project for ODE is something I can work with the Xith3D folks on, and both our engines could use it.
This is also one way to make sure that utils/etc are clean and without dependancies to other engines.
[/quote]
I think this is definitely the best approach. There was some complaints in a general thread about duplication of work - and a standard Physics API is much better than all of us making our own sub-standard ones instead. That’s the benefit of open source after all.
I too would like to see Xith3D stay 100% java as it currently is with third-party libraries handling the native code bits (this makes it easier to maintain for us). As Jens said, the Xith3D model is currently a very strong and sound idea, in most cases the developer can choose what underlying library (if any - eg for sound) to use. I would like see this philosophy continue for the physics aspects. There are some smaller projects which may not need Physics or sound and these ones currently don’t need to carry any extra bloat and I’d be good if it could stay that way.
BTW - to get the project approved you have to go though some bureaucracy, see here: https://games.dev.java.net/ and here: https://games.dev.java.net/govern.html
Will.
[quote]My off the cuff, non-scientific analysis says:
“100% Java implementation guaranteed faster than JNI version” ;-)"
[/quote]
lol. I think thats a first… the developers are less conservative then me
I agree with Yuri that pluging ODE will seem like “just adding native libs” to the project but I had bad experience with libs before.You keep having lots of problems depending on the versions of the lib, patches applied, OS, etc… (mainly Windows).
If you check the forum, you can see there’s a lot of problems coming from jogl (OpenGL versions, hardware not supporting versions, few Linux probs, etc…) and I bet that the forum will have few questions about problems with the ODE native libs.
100% Java PE will remove this probs and Xith3D team will spend more time on Xith3D dev than answering question about why the ODE lib causing probs.
It seems that:
- Xith3D needs a PE quite rapidly according to Yuri: “The question is ability to use physics engine in production in some reasonable time”
- most people on this forum agree that a 100% Java PE will be great for Xith3D.
I guess the best approach for this is to (as said Orangy Tang and Jeff):
1/ define the PE interfaces
2/ plug the actual C++ ODE to Xith3d
3/ open a parallel project which will “port” and not “re-create” ODE in Java.
4/ when JavaODE is finished/tested/approved, we switch.
This will allow the Xith3D dev team to have the PE functonal rapidly and concentrate on Xith3D while others (like Shawn, Orange Tang, myself or others) try to port ODE in Java.
If the port is not done or takes a very long time for X reasons , Xith3D will not be stalled.
DZ
quote I had bad experience with libs before.You keep having lots of problems depending on the versions of the lib, patches applied, OS, etc… (mainly Windows).
If you check the forum, you can see there’s a lot of problems coming from jogl (OpenGL versions, hardware not supporting versions, few Linux probs, etc…) and I bet that the forum will have few questions about problems with the ODE native libs.
100% Java PE will remove this probs and Xith3D team will spend more time on Xith3D dev than answering question about why the ODE lib causing probs.
[/quote]
Fully agreed.
Native libs for Java applications are always painfully and in particular they break the Java philosophy “write once run everywhere”. You’re going to depend on the grace of those guys who deliver you with a natively compiled version of the bindings for a particular platform. If they don’t - you’re stuck. Better: free choice of the platforms on which all Java apps shall run.
JOGL is the maximum case of a native lib I am willing to bear with Java applications at the moment, knowing that several “guys” who maintain it are from SUN so it’s not just a hobby project who could disappear tomorrow and leave you sining in the rain…
Strongly tied to the hope that SUN will include direct OpenGL support into a future J2SE. So that we’re going to be able to say: for our OpenGL/Xith3d app/game/bla you just need a Java 1.6 enabled platform and there you are.
We all know SUN will support/use OpenGL on non-windows JVMs but the ultimate goal should be something like JOGL in the J2SE.
As you say: it’s already a hassle to provide people with the neccessary JOGL native libs when you want to show/test your JOGL applications (without JWS) to just a few people who own different computers at different places… (A friend of mine works with a HP UX with Java 1.4 and OpenGL but won’t be able to run any JOGL program. 
Jeff said: “the Java based one {PE} will be portable and MAY even be a bit faster depending on how much in the way of Java to C context switches the JNI version had to do.” It’s the performance tuning book Jeff who says this, so … do we need to discuss further? 
PS: The reason I’m writing again so eagerly is because I’m sure there will be many occasions where Java developers could use a (Java) physics engine in future games/applications.
Hi,
I think this is realistic, and I believe this is a way to go. This ensures that physics library will stay independent of Xith3D and will be usable in other projects/engines, and will keep oportunity to make Xith3D 100% pure Java.
…and as I understand this implicitly means keeping the PE API similar to original one, so in future we can replace native version with Java version.
I think we should go in parallel. Defining the PE intergration with Xith3D is one part, making a bindings is a second, and ODE -> Java port is the 3rd. So, I generally agree with the summary made by djazia. …and we don’t want to loose your efforts!
Yuri
I just wrote to dev.java.net community as I need to justify why the project should be added into games.dev.java.net section.
Message below might be of interest to some people.
Here is my project description along with other information for Java Games Community to consider.
- Project
- Description
The javaode project allows using Open Dynamics Engine (ODE) through Java. It should be easy to plug in on any 3d library like Xith3d or jME. ODE is a free library for the simulation of Rigid Body Dynamics (see http://q12.org/ode/ for more information). Interface is built using swig tool and therefore it is almost one to one with ode’s c++ interface.
- License
BSD
- Other information
I and my friend have tested most aspects of ODE using odejava interface with Java3d, Xith3d, jME and OpenMind projects. Same interface has been used for over a year now and now I feel that it is time to share this project with everyone. There are no known problems with odejava, although testing has been quite simple. However I strongly feel that this binding is suitable for contributing Java games instantly to the next level. There exists a need for good physics engine now and developing new one completely with Java takes some time. This project would boost 2d and 3d java game development today and hopely raise more interest for getting people to develop their own physics engines with pure Java. Odejava community should work together with other Java physics engine projects, in order to smoothen transition from odejava into java physics engine when time is appropriate.
Project’s core consists of single interface file. This file is used to construct Java classes and methods into ODE counterparts, in other words the important result is odejava.dev.java.net package. Odejava uses swig as it’s tool for creating bindings into ODE. The package contains also Java 3d demos done using Xith3d library and an sample world class that shows how easy it is to plug into any existing Java 3d renderer.
The downsides. This project needs single native library. I have compiled only win32 odejava.dll (256kb), but my friend is using same package under linux. In any case odejava compiling is extremely simple if one knows how to compile ODE. Odejava first priority is to get most precompiled libraries for mac and linux into the package, so that it is as simple as possible to get started with physics engine on Java.
I am not planning to make big modifications on this project because currently there are only a few things that need to be changed, this just works in all it’s simplicity. I am looking forward for the community to come up with good ideas on how to develop this project further, especially creating better physics API on the Java side. There already exists good documentation and active mailing list on ODE www-site. You can get started with odejava just by adding single native library to JVM’s arguments and importing odejava.dev.java.net classes.
Here is a thread that I posted on Xith3d forums three days ago. Xith3d is also dev.java.net project. This thread is popular and there certainly seems to be demand for adopting ODE in Java.
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1069584768
Yours sincerely, Jani Laakso.
I want to say that it is great you have made the ODE wrappers and started the odejava.dev.java.net .
Undoubtly, we will use it and it will become the benchmark for some time.
There is a critical motivation on our part to have an all Java version though, and that is for server-side game computation in networked games.
Nearly all servers run pure Java or can easily be added since this one of the places Java is heavily supported.
However, most servers are headless (little-to-no graphics) and have many possible machine architectures and OSes combinations which makes using a native library a hastle in most cases and impassable in others. This was a major reason years ago we had to write our own seperate collision system from Java3D, because Java3D CAN NOT run headless at all (i.e. you can’t even start a J3D app on a system without OGL or D3D support, such as a server)
So we will be requiring pure Java in the end for any server-side networked project. So this is why we will ultimately be pursuing pure Java ODE library.
The project has my +1, that’s for sure.
I havn’t got that email yet. Did you join the mailing list before sending? It will reject emails sent by any email address not registered on the list.
Will.