However, i did see a little applet (about a year ago) that does use a physics system to collide a set of boxes together, handled stacks pretty well actually. But it was 2D and it cost money...I also can't find the link now, but its somewhere on forum.java.sun.com

There was talk at one point of gradually migrating ODE to pure Java. So it would be the same API with a pure Java implementation. I still think that is a cool idea.

I think so. Is there any open-source C++ to Java "pseudo-converter" existing ?@c_lilian : I also found very irritating when nobody answers to questions on a forum. It's not evident to know if there's no answer to the question or if nobody does mind..

It is additionally attractive because, to some degree, it _can_ be accomplished incrementally. You can migrate operations, and the web of direct dependencies of those operations, to java in clumps, but continue to call into C++ when possible. The task could potentially be far more pleasant than a monolithic port.

I think one approach would be to start with the ODE bindings and try to push the 'native' methods lower and lower until they were gone... but I say that having never looked at the code, so it could be totally the wrong way to go about it.

The advatages that I can think of:- users don't need to change their code, old code that used the ODE bindings continues to work- the JNI overhead is eliminated- with everything in the Java domain it will be easier to modify it in small bits towards a more OO API, or you can just layer a more OO API over the original routines.

Writing yet-another-API has a whole pile of requirements and tasks that go along with it, not least of which are designing, testing, documenting, and maintaining. The scope of such a project is a good deal larger than changing the internals of a tried-and-true, well used, and documented api like ODE. The purpose of ODE->java migration, to me, is pure performance. I don't have a problem with the 'non OO' API of ODE any more than I have a problem with OpenGL or AL.

But if you made a fresh start, it might be possible to make it better than ODE. What would be such features that commercial engines have but which ODE is missing? Any ideas how to improve ODE?

Sure it would be very hard to build a new physics engine, but I don't like the idea of rewriting something that somebody has already done, unless there is some considerable improvement over the existing system. How big performance increase can be expected from converting ODE to Java?

Well there is also the benefit of not needing to distribute a native DLL, so it will work anywhere that Java runs, without security restrictions. Like unsigned applets and Web Started applications.

It will be easier for anyone to build for the same reason.

The only way I see the performance NOT getting a boost, is if the ODE native code uses SIMD instructions to optimize some things. I don't think there are still a lot of issues with Java's floating point that would restrict the performance enough that getting rid of the JNI call overhead wouldn't balance out.

Either way, I think there are enough reasons to have a pure Java version of ODE that even if there was no performance gain at all, it would still be better. Though I guess without operator overloading it will look a bit messier on the insides.

Well there is also the benefit of not needing to distribute a native DLL, so it will work anywhere that Java runs, without security restrictions. Like unsigned applets and Web Started applications.

It will be easier for anyone to build for the same reason.

Yes this was my original requirements... Also, the fact to sticking to ODE is that... wel... you don't have to understand anything on physics ! you just have to apply a receipe to translate C code to Java. A project like this could stay in sync with ODE and be maintained by java developpers not knowing much of physics, like me or others (well, I've studied theses things a while back to have enough understanding of ODE internals, but it was so easy to forget ! I don't want to refresh my memory )

I'm really interesting in all these things, you know, because I ~3 months ago I tried to port Cal3D (an animation library in C++) to Java. And I can say it really wasn't hard, but : - There was no JNI bindings, so I haven't tested the Java version, because it's still unfinished (suspended for now) - Cal3D is completely "clean" OO

I think : - It's a good idea to port ODE to Java - It would be very easy to transform C-like ODE functions to OO-style classes, really - I just don't know how we will do when a new ODE version will be out.. maybe we could work with diffs ?

If we do something like this, couldn't we make like in the xith ? Where there are also two renderers that can be used. And jogl and lwjgl also got differences, so this would maybe the best idea (e.g. with things like "GeomTriMesh works fine for pureJava, but is buggy with ODE" )

Site last updated 4 years ago. All it does is simple particle physics (collisions and gravity between spheres).

In otherwords it doesn't look usful. Not even as a starting point for a proper engine. (It's also GPL, not LGPL, so useless as a real library.)

Now if Shawn's API is Open Source and uses a suitable license, perhaps it would make a good starting point for a more general engine, that is, break the Java3D ties.

Hard to say what the best path is, other than there definitely appears to be some demand for a pure Java general purpose physics engine. Bindings to the Newton Dynamics engine will at least offer some choice, ODE, or Newton Dynamics. Has anyone asked the Newton Dynamics guys if they are interested in a pure Java port, perhaps they would be willing to share some ideas at least.

I have been thining for a while that a java engine would be so much better. Less nightmares of random crashing without hope of debugging. ODE is designed so that a custom collision system can be inserted. I think that would be the way to go. I don't feel like the ODE collision system is really very good. I think it would be better to implement a new collision system based on OBBs:-http://citeseer.csail.mit.edu/gottschalk96obbtree.htmlif that were used you would have good collisions for boxes and rays. Shperes and such I think should just be implemnted as approximations using OBB trees. I think the major weakpoint of ODE is that new geometries have to be analytically coded for colisions with every other existing geometry. I say a better system is just stick to one type of collision situation and approximate to that. Still, its all talk. I don't think I have time to implement it. Depends on which direction my PhD goes.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

arne, I think there are some merits in doing a 1:1 port in this case. Odejava already provides an excellent O-O interface to ode, and since nobody here that I know of is a real Physics expert, keeping the java code as close to the C/C++ code as possible will help from a maintenance point of view. The main differences would be removing pointers and replacing them with arrays or buffers. It would also mean people could use the low-level pure-Java port with Russ's documentation.

A pure-java port of ODE would solve most of the problems that Odejava is suffering. I think it is worth a crack.

Here's the big question. Who here supporting this idea is actually prepared to walk the walk and code it. I am, I have a vested interest in the future and stability of Odejava. I would like to see at least 3 people on the team, that way if one person goes I won't be left carrying the whole thing by myself. I would like to see people who are developing their own projects with Odejava and therefore also have a vested interest in the API.

arne, I think there are some merits in doing a 1:1 port in this case. Odejava already provides an excellent O-O interface to ode, and since nobody here that I know of is a real Physics expert, keeping the java code as close to the C/C++ code as possible will help from a maintenance point of view. The main differences would be removing pointers and replacing them with arrays or buffers. It would also mean people could use the low-level pure-Java port with Russ's documentation.

Ok I get your point

Quote

A pure-java port of ODE would solve most of the problems that Odejava is suffering. I think it is worth a crack.

Here's the big question. Who here supporting this idea is actually prepared to walk the walk and code it. I am, I have a vested interest in the future and stability of Odejava. I would like to see at least 3 people on the team, that way if one person goes I won't be left carrying the whole thing by myself. I would like to see people who are developing their own projects with Odejava and therefore also have a vested interest in the API.

Will.

definitely - I also would try to help, but don't count on me, because I don't know if I will manage it.

If I engage and abandonate in 3 weeks, I will lose my credibility. Err.. what credibility ? I haven't any.. Okay, so I'm with you.Will we implement what t_larkworthy talked about ? May he imply himself too ?I have a pretty good knowledge of C++ and Java, but I prefer to leave physics subjects to peoples that know a lot more than me..

Haha. I was trying to avoid any commitment. There are elements of the OBB thing that I really don't know how to do exactly. The transforming of an arbitary trimesh to an OBB. The researches used a tool that helped them but we would need to do it from scratch. The raw realtime collision system using the OBB trees is fine. its the bit beforehand. Count me out for now becuase I really cant commit just yet. Though I am on the border at the moment. Give me a week of monitoring the forums and I might go for it.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org