Pure Java Port of ODE - planning/feasibility

Game Mechanics
#1

Is this feasibible? Who’s with us on this project?

How are we going to tackle this task? Each volunteer to port certain files/sections? What are the overall design implications?

Should we create a new Java.net project to manage the port (probably not a bad idea)? What name? “pureode” or something? Are there any other resources we need? The Odejava.org website/wiki is available for use.

Should we appoint a single manager for the project? BlueSky are you interested in that role?

The objective as I see it is to do a 1:1 Java port of the ODE sources such that we can sub-out the native interface of Odejava and sub-in the java one. Current and future changes to the functionality or areas where the code is for some reason quite different (so much so that you can’t recognise the 1:1 relationship) should be well documented I believe.

Will.

#2

I’m used to porting C to java code (I have done so professionally on two projects in the past) but I’m not sure yet I can commit to this porting.

In a week or two I should have more visibility on my schedule (currently working on my own software renderer) and if I can help, I will.

Overall I think it’s a good idea if we manage to avoid too many objects instantiation (or keep them short lived). At least it doesn’t require full understanding of physics…

I’d vote for a java.net project (or an extension/plug-in of odejava ?).

Lilian

#3

Great idea.

#4

Nothing’s impossible… But from what I heard about ODE code, it will be very difficult…

Talking of myself, I’m not sure if it’s better :

  • To port ODE
  • To make a proper binding of Newton Dynamics or to port it
    I’d wish that ODE was OO…

I should look at how the code is organized before answering that question.

If it’s a good idea, yes we should create a new Java.net project. I propose the name : JODE or JDE (standing for Java Dynamics Engine, assuming when a project name has Java in it, it’s open-source…)

I can’t say right now. If it’s a good idea why not…

IMHO, it’s a pretty reasonable way to do that. But maybe later we can completely throw out the non-OO design. Isn’t it possible to put ported Java code into actual ODEJava OO classes instead of interfacing as it’s made actually ?

#5
  • the physics would stay the same, so no argument like “yeah, but we don’t understand the physics, so we can’t do that…” In Odejava there is soch much effort spend on making a good OO interface for the non OO ODE, so it would be performance throw-out to make it non OO, so we can use all the overhead of having extra classes that map these. ::slight_smile:
    If we port it I’d say we should try to make it OO right a way, because everything else makes it only less readable and much more error addicting.
    just my 2 cents…

Arne

#6

The other optionis to simplement the public (non-OO) interface to ODE, but where possible ignore the C implementation entirely and jsut do what is right for Java.

Since OdeJava already has an OO layer that is implemented via the C-style ODE bindings it makes sense to use the OO work that was already done. Then if needed you can gradually blur the line between the original ODE API and the OO API (possibly with significant performance benefits?) until it really is just a pure OO physics framework…

#7

I would personally like to drop ODE all together and get the community to make our own physics engine. There are alot of papers out there that describe, in glorious detail, how to make a 3D physics engine.

Physics does involve alot of maths, but its good maths, the concepts are more difficult to absorb. Thats just my opinion…

But if you are insisting to make a complete ODE port, i’l maybe, possibly, help out a little bit as a contributor, but definetly not as a developer as I already have alot on my plate. But you need to start now, because the more people that voice in with their views on how to go about this, the more difficult it is for the project to satisfy more people.

DP

#8

Well alot of ODE is object orientated when you look at the source. They just exposed it in a C library so it could be used for more things. When you read the C library you can see an OO structure to it.

#9

Oh yeah and I think the name JDE is great

#10

Yeah I will contribute 5 hours of my time (min!) a week on this project as a straightforward port. As mentioned before ODE does have an OO layer. Thus porting it all the way to the exposed layer will not mean that OO concepts won’t be able to be used. Those parts that sit just behind the C layer will still of course be public and usable.

#11

I would be very interested if such an initiative would be started. But it seems to be a lot of work.
Because apart from native crashes due to JNI bindings (when using ODEJava), ODE suffer of some bugs :

  • Approximative (too much!) collision detection (ex : objects fall down through terrain trimeshes)
  • Non-deterministic & iterative simulation (Newton Dynamics has a deterministic solver)
#12

Its not a painful task to create a simple physics engine if you understand the basics, all you need to is integrate the acceleration of the object twice between 0 and the time difference to obtain the position, and using F=ma to relate force to acceleration. For rotation, integrate the torque twice to obtain omega which is the rotation angle between the local body axis and the world axis. Probably using a simple iterative solver to solve the differential equation.

All the above is nice for 2D, but for 3D, it gets harder for rotations as you have to deal with matrices or quaternions. But the basics stay the same.

I think if we build a solid foundation, we can add other things to it, like shock propogation from Kenny Ereleben’s thesis, and we can use ODE as a reference instead of a base…

Thats just my opinion.

DP

#13

maybe we can fix the ODE bugs with our ODE port :wink: Port it and make it better :slight_smile:
Yeah, as darkprophet said, we really should start now else it will get buried next to alot of other unfinished projects.

Arne

#14

ODE is advanced, its a mature product…so fixing things by our port is probably not likely…

Also, most visible bugs in ODE are due to the collision system (boxes going through mesh), and thats because its not exactly easy doing a trimesh-trimesh collider, otherwise, all the engines would have arbitrary trimesh’s colliding with others with spectacular physics, although the inertia tensor might make it difficult if not nearly impossible to do that on a concave object…

Bluesky, do you know the difference between the two solvers for the differential equations imposed by the simulation? I tried googling for it, but couldn’t find anything…

DP

#15

sure, but we could at least improve datastructures…something that goes lots easier with OO

#16

It probably makes sense to approach the port from a very high level. Use proper OO to model the concepts in ODE (world, bodies, joints, etc…) then look to the ODE source to extract the math bits and apply the same equations to our OO data model.
Having not yet used ODE I really can’t comment further… I’ve got two game ideas brewing that need a good physics engine though :slight_smile:

#17

I agree its the collision system that is buggy, but ODE is made so that the collision system can be changed, hence a straight forward port would provide a working physics system quickly, and could be upgraded later easily with a better collision system (I have one in mind).
The hard bit of the system is not the math, its how you solve the math. And ODEs quicksolve and stuff is pretty good.
I am all for a straight forward port, skipping uneccissary bits (like fastStep or whatever the outdated method was), becuase ODE does have a certain amount of design flexability built in.

#18

Interesting points - ODE deos have an O-O layer under the hood which we can use. It is quite a mature API, and I think a better starting point than starting with nothing. t_larkworthy, your comments about the collision are interesting, it is certainly good that we can change the collision system – certianly that is something that would be far easier when it’s all in Java than messing around with the C and JNI wrapper.

So it sounds like we have t_larkworthy, BlueSky, myself and possibly darkprophet prepared to commit some time per week into this idea. It certainly sounds like it is worth giving it a shot and seeing how we go. There is no shame in deciding once we look deeper that it isn’t feasable after all.

Who is the most qualified to lead us? I would think whoever has the most C/C++ knowledge would be best. I have a decent enough working knowledge, but my use of C has not really spread beyond university and toy projects unlike my Java so I don’t believe this would be me.

Cheers,

Will.

#19

I know that this is not a priority for you guys right now, but what about the possibility of having the physics engine you’re building detect the presence of a PPU and take advantage of it? When one is not present, it just uses the CPU.

#20

If we want to do that one of us would have to have a PPU to test it :confused: Nice idea though :wink: