I've been playing around with ODEJava a while ago and stopped my efforts again, because there were too much unpredictable behaviour in this library, which made it useless for me. So I appreciate the development of a pure Java implementation of ODE very much.

I started to check out the latest sources of JOODE and tried to find out what's the current status of the project. From this I could identify the following points:

the activity on the project (CVS commits) seems to be low in the last few weeks

I could figure out that a lot of functionality if ODE is not ported to Java until now (limits and motors on joints, cylinder geometry, hash spaces)

the code itself seems to be a very raw port of the C sources (C-stylish method and property names, few use of an object oriented approach, no use of the collection API)

In earlier posts about the status of JOODE it looks like you were planning to release a first version in the end of March. I guess this will not fit into your timeframe anymore. What are your current problems?

did you experience servere problems when porting the code or

is it really only a question of time?

For me it is very hard to see if the code is working. The Testcases seem to be working, but they are very rudimentary. I would love to see the project going on and could spend some effort to make the porting and clean up of the resulting code going on (ven though I am not a real expert in physic engines). But before doing this I would like to make sure if the effort is not only a waste of time. Who can tell me more about it?

I am on the SourceForge forge. Maybe I am just a little bit too exited to see JOODE work and expected still more to change on the subjects mentioned above

Am I right that your started to implement a convex hull geometry in favour of the ODE geometries (sphere, box, cylinder, trimesh)? Otherwise I would miss at least the cylinder geometry (for vehicle physics).

Could you tell me where you implemented new or replaced existing functionality (compared to ODE) ?

mmh theres the convex hull stuff - it's going to replace box and we think on building a GeomTerrain with it. I don't know how it's going to work out with GeomTriMesh, because TriMeshes are fairly different.

and there are also some differences in the handling of the spaces but that are actually more internal differences, that shouldn't matter to the average user. There's OctTreeSpace now which doesn't exist in ODEJava.

If you need something, that's not implemented yet, you're welcome to implement it (e.g. the cylinders) instead of hashspace you could use OctTreeSpace for now.

Hi hdietrich,Yeah the code is pretty raw and some functions are still C-style, but heh that's a first attempt to get something running. We can do refactoring when needed. Yeah the CVS activity is pretty low, actually I'm waiting for t_larkworthy to finish his convex-convex collision detection stuff before doing extensive testing. And Yeah limits and motor on joints are not yet ported, these are planned for the second release of JOODE (according to t_larkworthy's post).But I can assure you the project isn't dead at all.

To be honest, JOODE is no port of ODE anymore. I started to move the code for Cylinder geometry from ODE to JOODE and realized that the JOODE impelemntation of the colliders has not much in common with the code in ODE. I guess there is more "new" code than ported code in JOODE now. At the moment I don't know how to handle this.

I think the best way would be for you to simply look at the example of sphere, and then simply port the logic. That's how I did this with Box. In the Geom itself are only simple methods like calculation of the penetration depth and so on. For the different Collision-Types (e.g. Sphere-Cylinder, Cylinder-Cylinder) you'll have to write a new class handling that collision and also register it in Colliders. The best way to find how to do this is again to look at already ported examples (Sphere-Sphere or Box-Sphere - only Box-Box doesn't work correctly).

Your work is appreciated.

@Tom: If you don't hurry with your Convex-Hull code, you'll also have to implement Convex-Cylinder Collisions, hehe

Hello. I have not been in the office for a while. I am here. I am desperate to get back into JOODE but it is the end of term and I have TONS of stuff to do. I had a robot competition on Tuesday. Our robot blew up! Smoke and everything. But yeah, I have lots of major projects in over the next two weeks and then exams. And my Summer project starts before my exams! Urgh. Rediculous workload it really is. For those who are interested, which I doubt there are any, I am taking pictures of fly brains under a confocal microscope and automatically mapping them using machine learning techniques. Woo! I can't wait.So yeah. Don't expect me to do much over the next 3 weeks. But I promise I will be back with avengance ASAP

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

Code for primitive geometries and colliders has been added.For each collider a test has been added.

Be aware that not all of the colliders have been implemented and therefor not all tests show a valid behaviour. I just wanted to add them to have an overview of what is working and what is still missing.

For a complete integration of ODE functionality it is still a long way to go, but I think its worth having releases before that.

Things to do in the next days:1. implementation of all primitive colliders (could be accomplished quite soon)2. implementation of convex colliders (don't know what's the status of t_larkworthy)3. basic support of limits and motors in joints (see above)4. clean up of the API

After that has been done I think 80% of the functionality has been ported. The rest will be the more complex stuff, which will take some time.

Further things to do:4. implementation or TriMesh geometry and colliders5. full support of limits and motors in joints

Of course thats my personal opinion and I am quite new to the code, so I could be totally wrong . Please correct me.

I just looked at the CapsuleSphereCollisionTest (but it'll be similar with the other Test-cases you made) There you set the mass of the second Body to 0.The collision looks fine, which is why I'm wondering. So for example the first Body actually gets slower when the collision happens, but because the second body has no mass at all, it cannot give some of it's kinetic energy to the other body - so it actually shouldn't slow (no matter what the other body does) -> there might be a problem in the basics of our collision algorithm.

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