Thoughts?
I’m all for it - though after seeing the trig performance I wonder how much that will effect the overall performance?
The main issue is that it may be hard to convert small bits at a time because of how the data structures must interact with the native code at the low level.
We examined fairly thoroughly for our GDC demos, as we really wanted it all in Java because of the number of platforms we will be running on.
Unfortunately, ODE is not going to be a simple port for several reasons.
- There is significant use of C function pointers, which of course means an object based model needs to be agreed upon to cover that.
- There is array manipulations using gasp NEGATIVE indices. i.e. value[-1], value [-2] etc. For those areas the numeral methods need to be completely rewritten.
So that said, I am all for it, the only remaining problem is that the Java imp will always be a version or so behind the C ODE because of that heavy conversion that will need to be done for each version. :-\
Still…perhaps some custom C to Java processing tools for ODE will help make it happen.
[quote]Unfortunately, ODE is not going to be a simple port for several reasons.
- There is significant use of C function pointers…
…the Java imp will always be a version or so behind the C ODE because of that heavy conversion that will need to be done for each version.
[/quote]
Function pointers shouldn’t be a problem - worst case, pass interface references instead.
How fast is the main ODE development moving? I would think that once the initial port is done the Java version could keep up with incremental changes (all the basic numerical methods would be ported) or just decide to branch out on it’s own and not track the main ODE project so closely.
[quote]We examined fairly thoroughly for our GDC demos, as we really wanted it all in Java because of the number of platforms we will be running on.
[/quote]
Collision part is independent of ODE as the author states. Also, good collision libraries are as complex as ODE itself, at least according to my knowledge but I may be wrong here. So if anyone would wan’t to convert ODE’s functionality into Java at least it could be divided in two parts. Just a tought but does there exist any good Collision classes for Java that could be extended (haven’t seen any)?
In other words, you can plug any collision library to ODE providing that it generates contact points based on collisions, here’s a snippet taken from ODE’s documentation: “Using ODE’s collision detection is optional - an alternative collision detection system can be used as long as it can supply the right kinds of contact information.”
In practise this means that the collision library should provide the following information:
class contactGeom {
Vector3f pos; // contact position
Vector3f normal; // normal vector
float depth; // penetration depth
geom1,geom2; // the colliding geoms
}
Shawn, have you evaluated ODE’s standard collision code, is this a lot simpler than OPCODE? What about OPCODE collision code which supports TriMesh collisions, how complex this would be to convert into Java?
Cheers, Jani!
I’d love to see a pure Java ODE version.
[quote]the only remaining problem is that the Java imp will always be a version or so behind the C ODE because of that heavy conversion that will need to be done for each version. :-
[/quote]
That wouldn’t be a big problem I think: we could see it as some kind of quality assurance (we won’t have the newest bugs with new ODE versions ;-).
[quote]I’m all for it - though after seeing the trig performance I wonder how much that will effect the overall performance?
[/quote]
I ran a test, and JDK1.5 seems to be twice as fast with trig (compared to 1.4)…
Still not FAST, but faster 
Seems to me porting ODE would be quite painful? Why not create a pure Java Physics Engine? Maybe use ODE as a model, but don’t just do a straight port, design it from the ground up.
[quote]Seems to me porting ODE would be quite painful? Why not create a pure Java Physics Engine? Maybe use ODE as a model, but don’t just do a straight port, design it from the ground up.
[/quote]
Sounds easy enough. Got a spare half-hour you could slot that in? ;D
Hehehe, well I didn’t say it would be easy… BUT if it would also be difficult to do a straight port, why not take a little more time and do it right? 
Go for it!
Dynamics is not my specialty but I’ll be happy to test version 0.1
Well porting is essentially not going to be much other than using ODE as a reference and coding most things from scratch, and having the same methods in the API. I recall that Jani has already done some higher level stuff on top of the basic ODE API though - which will help make it more OO and Java-like I guess…
[quote]Well porting is essentially not going to be much other than using ODE as a reference and coding most things from scratch, and having the same methods in the API. I recall that Jani has already done some higher level stuff on top of the basic ODE API though - which will help make it more OO and Java-like I guess…
[/quote]
Back referring to the weekend project ehh :-). Odejava’s higher level API might be of some help, then again not, they were done in a flash. Low Level API is one to one with ODE’s own API, but even the higher level API is somewhat ODE styled (naming conventions), this is on purpose.
But seriously, I think getting any kind of physics engine for pure Java would be great. It can be straight port of ODE or it can be designed from group up, whatever makes the project successfull.
Now we’re getting to the definition of pure Java physics engine project. What does one wan’t to accomplish with this project, when first version should be ready etc. After the definition is clear, I’d select the least riskiest way to complete the project, drop some functionality if neccessary. Initial versions can be based on anything, it does not have to be too good looking etc…
It might be that ODE codebase would offer quicker way to to complete an physics engine for Java, if this is the case then I’d go for straightforward port.
But if it seems that most things have to be written from scratch, I mean also design new data structures and change the actual architechture, then I would only get ideas from ODE and make totally new API that is best suited for this project. It would sure be nice if someone had good opinion about this. I think “porting ODE” might get to this point pretty easily, it wont be a port anymore…
It all comes to people… At the minimum, this project needs people that have good knowledge of physics and medium programming skills. If porting is the choice then I suppose there’s always lurking some Java coders behind the curtains that can be drafted into another open source project, ehh ;D
Time to open redwine, it’s weekend, later!
Jani, as you mentioned, ODE was designed to allow the users to use their own collision library if they really want to. The core collision code that was written by Russell Smith (ODE designer and implementer) is not very large. To get ODE to work, we can go a long way with just Planes, Oriented Boxes, and Spheres. Finding the collision information needed by ODE (collision point, normal, and penetration depth) is not difficult for these primitives. However, to get the entire collision types available in ODE (and contributed code) supported in a Java version, reasonable amount of code will have to be written. Just to give others some Idea, the following collisions will have to be performed/handled to return the “contact info” needed by ODE:
— core —
Plane
Sphere
Oriented Box
— other —
Cylinder
Capsule (Capped cylinder)
Ray
Triangle Mesh
note that every type needs to be able to collide against every other type. for example, there needs to be Capsule to TriMesh, Oriented Box to trimesh, Sphere to triMesh ect…
It is not that the code is extremly difficult to write. Especially knowing that there are many books published on them and there are plenty of open source collision libraries available (including ODE’s source). But the bottom line is that someone has to write it and test it. As it stands today, even ODE doesn’t have all types handled properly. basically besides the core types, anyone who needed anything had to write it which then got moved to ODE.
This brings up another point; there are always people who contributed code to ODE. They are destributed in the “contrib” folder of ODE and if people like it, it tends to gets moved to be part of ode. If ODE is ported directly, the other usefull contributions to ODE can also be ported.
I couldn’t agree with you more :). As Shawn mentioned, we would have loved to used it for our GDC demo. Especially since we have to run on multiple platforms.
I think it is far more practical to try to do a straight port. It will still be a lot of work and we will have to do something about the negative indeces :). It only took me 5 seconds of looking at the code before I was convinced that a direct port would not be trivial. In addition, we would have to do without 3x4 matrices (interestingly, the 0,0,0,1 row is left out. In addition, translation vector is not used. you have to use a float array of length 12 to set/get rot/scale )
Russell has put a lot of effort into ODE. is certainly didn’t get to where it is in 6 months :). Considering he had worked for Math Engine, has looked through other game physics libraries ;), and understand dynamics issues in the context of games, it is probably good idea to take advantage of his knowledge (basically borrow most/all of the work from ODE). I personally like ODE and I am so glad that is available. (BTW, I think Jani did a fantastic Job! )
I also want to mention another motivation for those interested in making a Java Physics library. The ODE Low-level API is low level. I personally am not a big fan of wrapping an API to make another API. I like to avoid it when possible. However, I don’t think someone that uses a Java API should directly allocate a float array in the C heap (not the Java Heap), put data in it one at a time, and then pass it to a function, and make sure to manually free the arrays once he is done. This is what you currently have to do to set the rotation of an object to an array. (however some of these can be fix in the low-level API by using direct ByteBuffers)
I highly recommend not making a new API from the ground up. It will be a difficult task. It will take a lot of time and evolution just to get to where ODE currently is. Porting is much more practical and safe even though it will require a lot of work.
Regards, Syrus
I’m currently working on a rigid body sim for my final year project. It’s basically an implementation of the material from the siggraph papers by Baraff et al. My tutor said it had to be in C++, but I would be more than happy to port it over to Java once I’m finished, around June. I really cant commit any time to a port at the moment.
If people wanted to start before then, I’ve got a stack of references to get them started on implementing a simulator from scratch.
No takers huh?
A pure Java physics engine is certainly desirable, but we should consider focusing on the interface first.
Jani has got a good start on defining a higher-level Java API for using ODE. Let’s help him flesh out the API and develop tools to help users build higher-level projects on top of the engine…
With proper design and encapsulation, the underlying ODE functionality can be reimplement over time.
Just a thought
[quote]No takers huh?
[/quote]
What are we going to accomplish here?-) Sure pure java solution is nice but…
Pure Java physics engine consumes noticeable resources (talented physics people + developers). Realisticly speaking, one could think that if the project is started now, perhaps it’s usable in a year or so. Of course it’s all up to the people that you can recruite for such an project.
Currently ODE goes further by ODE community and keeping Odejava up to these changes should be pretty simple effort.
I’d like to remind that Odejava has been put out by single person in a couple weeks of effective work (mostly on weekends for couple months). Also, I’d say that Odejava is already ready for “production” use if you are not trying to push it too far. Thanks to William, Higher Level API is getting to a more mature state.
There’s a huge difference on creating wrappers to an existing good solution and coming up good solution from ground up.
It’s all about the gains and losses. Odejava was brought up with minimum efforts, bad side is that it needs a native linux, win32 or macos library (how bad is this really?).
Ideally (and ideologically) pure Java physics engine is the way and I think that someday a proper Java project is to be started by some physics guru. But I’d say this new engine should (IMHO) solve some fundamentally big issue or offer new features if someone starts such an big open source project. Hardly eliminating single native library justifies all the resources that you have to put into such an project.
Ok, there might be some rare cases where native libraries could be an issue. Biggest issue might become from tiny differences that different platforms have on the native code, this might be a factor if you are trying to accomplish something on non-uniform platforms. Pure Java applications do not have this issue.
Last, I wouldn’t say native libraries are too big of an issue. As long as they are tested thoroughly on most platforms. You’ll be most probably needing some anyway (like latest lwjgl or jogl library).
To me, multiple same area projects are nice, but I just like to get one working library before starting another. Same goes for scenegraphs, opengl bindings, sound, physics libraries. Most of these are still alpha. Hopefully people would concentrate on getting one library from each area to get into v1.0.
[quote]To me, multiple same area projects are nice, but I just like to get one working library before starting another. Same goes for scenegraphs, opengl bindings, sound, physics libraries. Most of these are still alpha. Hopefully people would concentrate on getting one library from each area to get into v1.0.
[/quote]
I completely agree.
With respect to ODE, what we needed was a way of using it from Java. Jani did a great job on this.
Where I do think value could be added would be to help define a “standard” Java API for utilizing Physics Engines (not just ODE). The “reference implementation” could be bound to ODE.
The benefit would be the ability to focus on a higher level in an implementation independent manner. Assuming that multiple physics engines are implemented, the user could choose the “best” for the task without having to change much code.
Perhaps we need to propose a JSR for this? Java Physics Engine API, JPEA?
Perhaps there is such possibility, I do not have strong feelings about this. However different physic engines have different ways of doing things, but most of them share basic functionalities in the same way.
I’ve checked couple physics engines API’s thoroughly and they are somewhat different from each other. Forcing them under same API would be akward idea in this particular case.
When pure Java physics engine project is started, I’d hope that it’s based on something completely new and not neccesarily use ODE (or Odejava) as it’s example for the interface.
Note that Odejava’s Higher Level API is constructed simply against ODE only, bindings to other physics libraries have not been considered. I do not yet know if this is a good or bad thing, time will show.
Odejava’s HL API is also quite far away from being finished, currently we try to get the job done with minimum resources. It would be possible to hide ODE away from most of the HL API and separate strictly ODE specific features to own layer, this might be good idea on the long run. This is an interesting idea that should be considered, thanks for pointing this out John!
I’d like to have an general API for this one, but I for this area it might be quite a task. Engines share common ideas like position, orientation, angular and linear velocities (add more here), but each have lot’s of their unique features. At least general bindings to various renderers should be possible for various physics engines.
Perhaps very general definition would be possible and then use extensions based for each physics engine implementation which is being used. I assume this is something you mean?
Just food for tough…