Hi,
I’m looking for a pure java physics engine to bind it to my modest software renderer prototype (unsigned applet stuff)…
Basically it’s for collision detection, moving solid objects and applying forces to springs.
Is there something like that available somewhere, idealy open-source ?
Many thanks.
Lilian
Nobody ?
I’m going to find out by myself… 
Lilian
Being honest, i haven’t seen anything yet thats does what you want.
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
DP
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…
Yep I would prefer a pure-java solution for physics. Porting an existing API like ODE 1:1 is preferable (to me) over coming up with a new one, even if it is ‘more java-ish’ or ‘more OO’.
+1 ! who starts the project ? 
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.
Exactly… Of course there is still ample room to screw up…
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.
directly porting ODE to java would be stupid. If somebody would be doing such a thing it would be much better to code it object-oriented rightaway!
Why do you say that?
The advatages that I can think of:
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?
Yep that’s really the question… how much performance?
Is there a java profiler out there that is good enough to separate the operation time of a native call from the JNI overhead time?
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.
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 )
Lilian
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 :
I think :
It depends on the state of ODE… I don’t know it much but took for granted it was already stabilized and production quality.
If it’s the case, we’d just have to loosely follow its life cycle (not really needing to stay perfectly in sync).
Well… that’s my 2 cents… (I’ll have a look at the C source code before commenting on it again)
Lilian
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” )
ODE is not stabilized, there are lots of bugs still.