[Odejava] Version 0.2.2 released

Write here your comments about Odejava version 0.2.2.

You can find the latest version from CVS, there does not exists any downloadable packages yet for 0.2.2 version.

We have no documentation yet, but the code is extensively commented and the Demos exploit new Collision classes (JavaCollision) which allow you to receive all collision events and also edit them as you wish. The demos should get you started.

In practise you can now add sound events, particle effects or any other imaginable event that you can come up based on any collision.

Performance should be same as earlier version, based to my initial benchmarks.

CVS contains win32 and linux libraries. MacOS anyone?

Jani,

First up - great work! Thanks ;D

I have compiled and commited the linux native libary in the usual place (odejava/lib/linux/libodejava.so). I’m more than happy to do this at regular intervals for those of us using linux if you would like :slight_smile: It’s compiled on RH9 although I have Fedora setup on another box which I could start using if this is preferred.

One bug which seems to have plagued me a bit with the CarDemo is when it starts, the chassis of the car is rotated 90 degrees on the X-axis (if the car is pointing forwards) (which in ascii makes the car look like this: .|. instead of ._.). When I hit space to reset the simulation it reverts to normal.

I just ran CarExample 5 times and got the same strange effect.

Any idea why?

Will.

Fixed. The problem was on Body.resetRotationAndForces().

This occured with previous releases also, only now it seems to come perhaps a bit easier. I haven’t checked why but somehow Body.setRotation() can act a bit funny. I was aware of this but forgot to fix it. Body.setQuat() has always worked fine. I fixed Body.resetRotationAndForces() by replacing setRotation(new Matrix4f()) with setQuat(new Quat4f());. Have to check why Body.setRotation makes this kind of bugs sometimes. For the mean time, I suggest you use quaternions instead of matrices when it comes to rotating your bodies.

Here’s an important fix / release…

Odejava 0.2.3 now uses DirectBuffers for collision data handling.

Previous version was thrashing memory a lot because of SWIG proxy classes were used for accessing contact data on a tight loop. This was an meaningful optimization as for complex simulations the difference on speed might be over 50%, this was mainly due to GC hickups.

Summary, collision data read/write should finally be as it should. Very fast and it does not need any “new” clauses or any JNI as DirectBuffers are used. Also complex simulations take a lot less memory.

Cheers, Jani!

You rock! :slight_smile:

Thanks for all the work on this - it’s people like you who make this site awesome. :slight_smile:

Peter.

Thank you for the compliment! It’s always nice to get positive feedback, me bows :slight_smile: Have to remember though that it’s the ODE itself that makes all this possible. Just keep more ideas and request coming, I try to coordinate work to other developers as well.

I’m glad that Odejava got quite a good start from the Java community. Too bad this is just a “hobby” project for me but more developers are coming, also some people are already using it for “real” work. I myself would really like to make some big software with Odejava itself but no such luck, no time in the near future :confused:

PS. We have a proper site coming up, just send those screenshots so we get the mandatory screenshots page to our site :slight_smile: