ODE Physics for Java

Game Mechanics
#1

Hi Folks,

I will be very shortly releasing a Java binding for the ODE physics library. It’s not pure Java using JNI as it does and I’ve only built on Windows to date - but all components should build under Linux et al. However it is pretty fast and comes with a trimesh collider. It uses the new direct buffers to share data between Java and ODE.

Keep an eye on www.shortfuze.co.uk for news (sorry it’s on the end of a wet piece of string for the moment).
I’ve a few other useful components in the pipeline as well…

Cheers,
Dave Lloyd
Short Fuze Ltd

#2

Sounds interesting. What do you mean with very shortly? Weeks? Months?

Please, keep us up to date about your work!

#3

I would love to see this migrate to a 100% java version, but obviously that’s way too much work.

Very cool though.

#4

Is this the same as this?

#5

I’m hoping to get the first release out in the next week or two. If anyone is particularly keen please feel free to bug me directly via dave at chaos dot org dot uk!

The Fuze3D implementation is independent of odeforjava - I only found out about that when I was well underway and I believe my implementation is now more update as it works with ODE 0.039 which has the OPCODE support built in.

As for a pure Java version yes that would be great. Though for performance reasons what I would like to do is to reimplement the structural layers of ODE in Java but to leave the solvers in native code - these can take advantage of the SIMD operations available on most processors. Ideally of course we need a BLAS (Basic Linear Algebra Subroutines) binding for Java and do it once!

#6

The 1.4.2 JVM uses SIMD automagically.
After all our VecMath tests, I can confidently say that an all Java version would the the fastest possible runnign in a VM environment.

#7

[quote]The 1.4.2 JVM uses SIMD automagically.
After all our VecMath tests, I can confidently say that an all Java version would the the fastest possible runnign in a VM environment.
[/quote]
It is heartening to hear that but I still suspect that for something as complex as the solver kernel, superscalar optimised code will have a significant edge. The JVM bytecode doesn’t provide sufficient information to do all of this. When I was working on a superscalar Fortran90 compiler I could get a good factor of 2 or even 5 just from the extra abstraction provided in F90 and there was usually a factor of 2 left for hand optimisation for specific problem sizes. Mind you the current implementation of ODE doesn’t go this far either!

#8

This project sounds great. I will definitely be giving it a look.

I tried a while ago to use odeforjava and found that it only compiled for linux. (this may have changed of course) I did my best with the make files, but I certainly no expert in that area. I am sure a make expert would have been able to make it go.

#9

[quote]The 1.4.2 JVM uses SIMD automagically…
[/quote]
I was told during a Sun Net Chat that this was NOT the case. SSE/SSE2 instructions are used by the 1.4.2 SERVER VM, but only for floating point operations that are NOT SIMD.

#10

Yes, the release ntoes say Server HoptSpot
http://java.sun.com/j2se/1.4.2/changes.html#runtime

But I’m not sure what you mean here

[quote]SSE/SSE2 instructions are used by the 1.4.2 SERVER VM, but only for floating point operations that are NOT SIMD.
[/quote]
What does “floating point operations that are NOT SIMD” mean?

And actually, more specific information on how/what gets SIMDed would be excellent. I’ve pinged my sources at Sun but no responce anymore :frowning:

#11

I mean they don’t use any vector instructions, but they do use the SSE registers

#12

[quote]I mean they don’t use any vector instructions, but they do use the SSE registers
[/quote]
Dammit! What’s the hold ups?! :wink:

#13

From the transcript at http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0429.html

SWP2: I noticed that the HotSpot compiler in Intel is now able to generate SSE instructions. In what situations would SSE instructions be used?

Ken Russell: The HotSpot Server compiler now generates SSE and SSE2 instructions depending on processor level; PIII will cause SSE (single-precision floating point) instructions to be used, while P4 will cause SSE2 (double-precision) instructions to be used as well. Only the scalar instructions (not the vector versions) are currently emitted.

#14

Any updates on this? You said you would release your binding “shortly” back on Sept 19th 2003 and it’s Nov 22 and still no releases at www.shortfuse.co.uk.

The project sounds promising and I’m anxious to check it out.

#15

News about a different ODE bindings project is currently being discussed in the Xith3D forum: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1069584768

Will.

#16

I’m willing to bet that by the time someone did a full 100% Java port of ODE, the newest JVM would use more SSE and SSE2 instructions, even the vector ones. :smiley:

#17

Please see http://odejava.dev.java.net

This project has comprehensive Java API for ODE, it is almost one to one to ODE’s C++ class.

Four demos included using Xith3d, jME and console (no rendered).

Below is a small intro on what to do with the demos:

runXith3dBox.bat
-change simulations by pressing 1,2 or 3. Keys q,w,e,a,s,d change box sizes (select new simulation after this). Mouse drag with left mouse button adds some spin to boxes and plain left click to bottom or top of the screen gives big force to last object (try it with tower simulation as all boxes are connected to each other using ODE’s joints).

runXith3dCar.bat
-you can try to drive around with a,d,w,s keys. b is handbrake (on/off) and keys 1,2,3 change the camera position. Space resets the simulation. Ode’s parameters are bit hairy, fix if you want.

runOdeHelloWorld.bat
-runs console based test with couple objects falling to a ground, with no rendered attached to it, so this is a bit dull demo.

runJmeBox.bat
-help is displayed inside the application

Linux and MacOS binaries are also available separately but we have not yet integrated these to the release file.

#18

[quote]Ideally of course we need a BLAS (Basic Linear Algebra Subroutines) binding for Java and do it once!
[/quote]
There are of course a number of BLAS bindings for Java, some of which are quite fast. See here http://hoschek.home.cern.ch/hoschek/colt/ for example. That comes from people who REALLY know about physics!