JOODE Development Status

[hdietrich]

Hi guys,

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?

Harald

[arne]

have you checked the java.net cvs out, or the one at sourceforge?

Only the sourceforge one https://sourceforge.net/projects/joode/ is up to date.
the last commit is only some days old.

end of march - is not yet past and t_larkworthy only has to find the bug in his code for convex-convex collisions (ok - this is some kind of an unknown factor)

Arne

[hdietrich]

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) ?

Games published by our own members! Check 'em out!

[arne]

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.

[Amos Wenger]

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.

[hdietrich]

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.

[arne]

Yeah it's OO you know

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

[Amos Wenger]

I wonder if Tom is dead or if he's in holidays at the Bahamas... or if he has been debugging for 3 weeks.. 

[t_larkworthy]

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

[hdietrich]

OK, then check in your code (convex stuff) and tell us about the status. I guess there are some people willing to translate/implement further (JO)ODE features.

Otherwise arne will get involved in the fluid dynamics implementation too much 

Games published by our own members! Check 'em out!

[arne]

hehe

[hdietrich]

Code for capped cylinder is coming soon

[bobbokop]

Sorry if my infos are not up to date. However, are you speaking about the CappedCylinder collision code?

[Ask_Hjorth_Larsen]

On the page it just says 'No File Packages Defined'.  How can I get the source files? I can understand from hdietrich's statements that they must be available somewhere.

EDIT: right, right. The CVS. Always check once more before posting....

[Amos Wenger]

On the page it just says 'No File Packages Defined'.  How can I get the source files? I can understand from hdietrich's statements that they must be available somewhere.

EDIT: right, right. The CVS. Always check once more before posting....

Yeah. 

[hdietrich]

I said soon. I just have to do some testing, before I can provide the code. I will post it to this form, since I do not have write access to CVS.

[hdietrich]

By the way, who has write access to JOODE CVS at all?

[Amos Wenger]

t_larkworthy, arne and me.
You can apply for developer access at the sourceforge.net project and t_larkworthy will give you the rights.

[t_larkworthy]

Hmmmm... can't seem to get access to CVS at the moment. I can't upload my latest collision code....

[cborders]

The CVS repo at sourceforge has been down for the last couple of days.

[t_larkworthy]

Woo, we have a new developer. Welcome hdietrich

[arne]

welcome

[hdietrich]

Hey, this time you were really fast 

Until now CVS doesn't let me check in code. I guess it takes some time until the new settings will be applied.

[t_larkworthy]

yeah there is a bit of a delay, CVS is working for me again now. I have not updated yet though (my uni account has exceeded is disk quota gain, sigh)

[hdietrich]

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.

[kylix999]

what do you think , what is current status of joode development in %,

50 % , 70 %,   of course in your opinion

[hdietrich]

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 colliders
5. 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.

[arne]

good job hdiertich

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.

[hdietrich]

I'm currently digging into this, because I expected a body without mass to behave like a static object (F=m*a is always zero for m=0).

[arne]

actually I expected a division by 0
a = F/m