Is ODE good for games ?

[divzero]

DP,

Thanks for the update, I wasn’t aware – but that certainly explains why you never send through the patches four months ago Thank you anyway.

swpalmer,

Fair enough, and I agree. I also should clarify, what I meant by “here” was more java-gaming.org in general, not this thread or sub-forum. Time and time again there are discussions mooted of new ideas with people indicating that they would be happy to help and there’s all this apparent enthusiasm and energy, then when someone says “ok, lets do it - who will help” – poof all of a sudden everyone vanishes and all you can hear is the sound of a cricket chirping Nothing at all wrong with discussing possible ideas I guess, but sometimes it would be nice for a dedicated group of people to form who will go and implement the good ideas

Cheers,

Will.

[eMKa]

@William Denniss

Don’t swich your opinion based on those of others, if it worked for you, say so and be proud of it.

I would be really joyful to learn that all bugs in my project that uses ODEJava are only due to my bad programmation practices, awful tuning and artifical uses of physics.

Personally I think a pure-Java port of ODE would be the way to go. I am using ODE in my game and have managed to work around most of the limitations. I find the XODE format very useful (I should since I created it), and it’s getting more so as more people support it in their loaders. Odejava has been around for a few years now and the Java side at least is fairly stable. Unless someone on the project were to be a physics guru, I think the best way would be to do a near 1:1 port of the code just removing pointers, so it wouldn’t be O-O, but then we’ve got the O-O interface working already with it. That way future ODE patches can also be evaluated and encorporated. For the record, there is no engineering reason why Odejava has to be an interface to native code (just a maintenance one).

One of the drawbacks aired previously about a pure-java port of ODE is that we would have to keep the java sources up to date with the ODE ones. This is becoming much less of an issue of late as the rate of ODE patches has slowed considerably (the sign of a fairly mature library I guess).

Are we sure to eliminate most crashes following this way ? One thing I want to know is : Are the bugs in the ORIGINAL C++ VERSION or are they due to the Java binding ? As I can see in the ODE Mailing list, most peoples are happy using ODE and as I can see on this forum many peoples complain about it or simply don’t use it. Note that :

• I don’t imply anybody, it’s just a constation. So Will, please don’t feel insulted, really I admire you maintaining Xith3D and ODEJava and still succeed to have a “normal” life. Really.
• Happy users of ODEJava maybe forget to say that they use it without problems

Regarding Odejava in it’s present state, DarkProphet, you mentioned that you had worked on the stability and improved it for your project and were going to submit some patches to Odejava – we’d love to have those patches

Personnally I’d like to know who is actually responsible of jME-physics.

I will be happy to devote time to a pure-java port of ODE. However, I am quite sick of carrying these projects on my own when the original creators become occupied with other things. It seems many people here are prepared to talk the talk, but not walk the walk. If you are seriously interested in this project meaning you can devote many hours in the short term and are intending to stick around long term, then lets talk.

If you know me a bit, you will know I always involve myself into so many projects, and sooner or later have finished to abandonate them. Fortunately, it actually seems that it tends to be “latest”.
The problem is :

• I’m really interested in contributing to Xith3D :
  • Implements a GUI system
  • (Maybe) implements different optimizations techniques
• I’m really interested in having a useable dynamics engine for games :
  • Port ODEJava
    (or)
  • Make a binding of Newton Dynamics
• I’m really interested in having a good java animation library :
  • Make a port of Cal3D -> JCal3D
• It’s essential to have a good modelization/animation tool for games :
  • Use Blender3D
    (or)
  • Implements Cal3D import/export feature in MM3D
• I really wants to continue improving the Gamma Game development framework :
  • Embed a scripting system
  • Make scripts editable by GUI ?
  • And a ton of other things
• I’m making a game, as it was my original intention, when learned Java

So you see, there’s a LOT of things to do. And I’m not having the half of the time I need to do that.
I can’t do all theses things alone. As I can see, many Java Games members are simply not interested by what we’re discussing, as they’re use LWJGL to make their games.
Is it possible to evaluate the cost in hour/developer to port ODEJava to pure java ? If yes, we could know how many people we need to do this in a reasonable period of time.
Now we need names.

[swpalmer]

So, after saying I have no time to help… I went and downlaoded the ODE C/C++ source and started converting it all to Java…
Ouch! Lots and lots of pointers to pointers… Many double * … which point to vector, matrix, list of vectors, whatever - difficult to find the appropriate translation to Java… e.g. array of doubles, or arrays of Vector3d etc…

Ah the pain…

I wish I was familiar enough with all the math… I think it would be easier for someone that knows the math to start from scratch!

[dsellars]

Thats what I thought when I had a look at it a while ago. Even a port is not simple I had trouble just trying to work out what was goign on Unfortunatly I don’t know the maths well enough either.

[erikd]

@swpalmer

So, after saying I have no time to help… I went and downlaoded the ODE C/C++ source and started converting it all to Java…
Ouch! Lots and lots of pointers to pointers… Many double * … which point to vector, matrix, list of vectors, whatever - difficult to find the appropriate translation to Java… e.g. array of doubles, or arrays of Vector3d etc…

Ah the pain…

I wish I was familiar enough with all the math… I think it would be easier for someone that knows the math to start from scratch!

It probably won’t make sense to port C++ code like that straight to java anyway. Of course it can be done, but chances are you’ll end up with an unmaintainable underperforming pile of unreadable ‘un-java like’ code…
Better to either stick with interfacing to the native code, or create a new physics library. My 2 cts

[divzero]

To answer your question: will this elimate all the problems?

It should eliminate all native crashes. This is the biggest PITA for Odejava. You do not want native libraries which crash - ever. Java crashes on the other hand are generally so much easier to fix. In my experiance with two Odejava based projects, it is possible to work around and mitigate the risk of crashes, but not possible to remove them entirely which is. As for the other problems? Well the physics problems we will need a physics expert to solve but the non-physics ones we should be able to fix.

Is there a need for a pure-java physics library?

Yes, I think so. This is not Xith3D or JOGL specific - LWJGL and even Java2D people will be able to use this as well.

Is it possible to port?

This I don’t know. From what swpalmer says it doesn’t look that wonderful. Someone proficient in C++ would certainly be an asset. Maybe we should ask for help on the ODE mailing list and LWJGL forums.

About BlueSky’s projects

That’s quite a list, I think you work similar to myself. Many of your projects are equally important as far as their usefulness goes. It is up to you to decide I guess. As I said before, the one thing about this idea is that it is truly universal - physics and display are not coupled in ODE nor should they be in any physics library IMHO.

What to do?
I don’t know. I do know that I would love to have a 100% pure java physics library that is partially ODE-compatible (so I can bolt it to Odejava). I don’t really mind where it comes from or who makes it, just that it is open source (and not GPL) and can be adapted for Odejava. I also know I am prepared to dedicate some time to this end, though I don’t know if I am the right man to lead it.

Will.

[Raghar]

I looked at ODE source code and it’s quite messy and it would need a refactoring. I think it would be easier to simply write down all needed algorithms, and write some reasonable world engine.

BTW what exactly is ODE supposed to do? Colision detection? World partitioning (and scene holding)? Is it able to do a priori collision detection? Does it use a reasonable algorithm to decrease amount of tests needed?

[divzero]

from the website:

ODE is an open source, high performance library for simulating rigid body dynamics. It is fully featured, stable, mature and platform independent with an easy to use C/C++ API. It has advanced joint types and integrated collision detection with friction. ODE is useful for simulating vehicles, objects in virtual reality environments and virtual creatures. It is currently used in many computer games, 3D authoring tools and simulation tools.

It’s a rigit body physics simulator primarily I believe.

See this thread: http://192.18.37.44/forums/index.php?topic=10976.0 for some discussions about implementing this idea.

Cheers,

Will.