• News
• Features & Screenshots
  
• Status
• Performance & Multi-Threading
  
• Differences to ODE for C/C++
• Migration Guide
• Documentation
• Source Code
• Dependencies
• License & Copyright
• Contact / Contributors

News

• 16th July 2011
  Checked library compatibility. ode4j still works with latest Java (1.6.0_26) and lwjgl (2.7.1)
  
• 19th June 2010
  Released '1.4' of the ode4j-0.11.1 Java physics engine.
• Updated javadoc for DHeightfieldData build(...) methods.
• Implemented support for building DHeightfieldData from short[], float[] and double[].
• API CHANGE: Changed API of DHeightField and DHeightFieldData to accept Object instead of Object[] as type of data.
• Trimesh: Trimesh support contains no known bugs except bugs that are also present in ODE for C/C++. However, performance has still not been optimized for Java.
  
• 30th May 2010
  Released '1.3' of the ode4j-0.11.1 Java physics engine.
  
• Fixed bugs: infinite recursion in DxBody and drawstuff crash with ATI 10.1/10.2 driver (linux)
  
• 16th April 2010
  Minor updates to this page, clarified multi-threading capability (also applicable to release 1.2)
  
• 3rd February 2010
  Released '1.2' of the ode4j-0.11.1 Java physics engine.
  
  • Initial TRIMESH support via GIMPACT port. This is still buggy!
  • Improved Javadoc
  • Fixed bugs: damping & auto-diable and commandline parameters in demos
    
  • General code clean-up
  • API change: DrawStuff.setOuputNull() -> dsSetOutputNull()
  • API change: renamed DContact.dSurfaceParameters to DSurfaceParameters
• 10th Januar 2010
  Committed bug fixes regarding dampening of bodies and regardin command line parameters (see bug tracker).
  Committed initial trimesh support (via gimpact) to SVN. The support should be considered alpha state, there should be no crashes, but expect weird behaviour. The new demo_trimesh and demo_moving_convex work reasonably well. But other demos (demo_cyl, demo_basket, demo_moving_trimesh, demo_heightfield) show problem. Any help with bughunting is welcome. Note: demo_moving_convex looks broken, however it behaves exactly like ode-0.11.1. The test harness is broken as well.
  I intend to make the next release once the bugs are fixed.
  
• 11th November 2009
  Some minor updates to the home page, including some new screenshots.
  
• 18th August 2009
  Released '1.1' of the ode4j-0.11.1 Java physics engine.
  
  • API port is now complete except for TLS and TRIMESH support
  • Javadoc has been copied to the OO-API
  • Bugfix
  • Cleaned up dependencies
  • DVector3 and DMatrix3 are slightly faster now
  • API CHANGE: Some mathematical support functions have been altered or removed (only the API, not the functionality). If you find having problems with the changes please contact me.
  • On-line Javadoc available . Please note that the method summary doc is often empty, while the detailed method doc is not empty. This is due to annotations in the original ODE doc.
    
  I'm again working on the TRIMESH support.
  
• 20th July 2009
  Released '1.0' of the ode4j-0.11.1 Java physics engine.
  
  • Two known bugs related to OpenGL, used in the demos only.
  • Currently working on an OPCODE port, enabling trimesh in ode4j.
    
• 7th July 2009
  Released beta-2 of ode4j-0.11.1 Java physics engine (based on ODE 0.11.1)
• All bugs are fixed, except two which are on drawstuff.
• Re-arranged downloadable libraries, so there are the following now:
• ode4j.tar.gz -> Contains the core jar file for end users.
• ode4j-cpp.tar.gz -> Contains the additional C-style API for end users, where the developer uses the C-style API.
• ode4j-src.tar.gz -> All sources, including demos and test harnesses.
• ode4j-doc.tar.gz -> Generated Javadoc for public API.
  
• 6th July 2009
  Released beta-1 of ode4j-0.11.1 Java physics engine (based on ODE 0.11.1)
  Known issues can be found in the Bug Tracker. I plan to fix the test harness and the DemoBuggy for the next beta, possibly later this week.
  The core library is now called ode4j.jar, the optional API similar to C/C++ is in ode4j-cpp.jar. both are included in the ode4j-sdk.jar, which also contains demos, tests, sources and the javadoc.
  
• 10th June 2009
  
  • Released beta 2 of ode4j Java physics engine (based on ODE 0.10.1)
  • New home page
    
• 5th June 2009
  
  • First release of ode4j: ode4j-0.10.1-beta-1 Java physics engine (based on ODE 0.10.1)

Features & Screenshots

• 100% pure Java port of the ODE / OpenDE physics engine. Native libraries are only used for the OpenGL rendering in the demos (thanks to lwjgl).
• Fast. It is in some cases even faster than the original C/C++ ODE. Please note that only the physics are fast. The graphical rendering in the demos is not optimized and quite slow.
  
• Provides javadoc, ~30 demos, complete source code and test harnesses (JUnit).
  
• Supports all geometries from ODE: box, convex, capsule, cylinder, plane, ray, space, sphere, transormable geom (deprecated), heightfield (a kind of trimesh) and trimesh (GIMMPACT port, still alpha state).
• Supports all joints from ODE: AMotor, BallJoint, ContactJoint, FixedJoint (deprecated), HingeJoint, Hinge2Joint, LMotorJoint, PistonJoint, Plane2DJoint, PRJoint, PUJoint,SliderJoint and UniversalJoint.
• Supports all spaces from ODE: SimpleSpace, HashSpace, QuadTreeSpace and SAPSpace.
• Java specific optimisations.
• A more object oriented implementation.
• Provoides an alternative API which is a direct port of the original C API. This simplifies understanding the existing documentation & tutoriuals and helps porting other ODE dependent code, but is not recommended, because it is less object oriented.
  

Status

• Currently, the port has only been tested through the available test harnesses and through running the included demos. Functionality that is not used in either may not be function correctly or may not be available at all. Please point out these cases to me.
• ode4j uses 'double' precision. A single ('float') precision version may improve performance by 10%-20% (based on a singular test). Also, the code provides some features that should allow a rather simple port. But there are currently no plans for such a port.
• Trimesh / GIMPACT: Trimesh support contains no known bugs except bugs that are also present in ODE for C/C++. However, performance has still not been optimized for Java.

• Look into optimizing OpenGL usage in demos. This should also fix the GL related bugs.
  
• Measure performance.
  
• Improve javadoc (copy it from C++ API to object oriented API
• Improve performance (DVector3 and DLCP)
  
• Fix known bugs
• Improve webpage.
  

Performance & Multi-Threading

• When profiling any of the included demos, you will see that most of the time is spent in OpenGL calls (at least on my SUSE 11.1 64bit system / ATI Radeon HD 3850).
• As far as I can tell, this is not a problem with lwjgl, but could be fixed by optimizing 'drawstuff'.
• To profile ode4j, please use applications that do not use drawstuff. To profile the existing demos, drawstuff can be disabled by calling DS_API.dsSetOutputNull() at the beginning of any demo.
• ode4j is in certain cases faster that ODE. I have investigated this only briefly, but I have the impression that Java can draw its advantage from using the garbage collector for arrays. This means de-allocation in Java occurs in a 2nd thread in parallel to computations, while in C/C++ de-allocation (which is expensive) occurs in the main thread.

• Any particular world should not be used be more then one thread at a time, reading or writing
• Multiple worlds can be used in concurrently by multiple threads as long as every world is only access by a single thread at a given time
• A world can be passed around (and then used) between threads simply by passing on the reference (this is unlike ODE in C/C++)
• The method OdeHelper.allocateODEDataForThread(int) does not need to be called as it does nothing (and never did). Actually it will be removed in one of the next releases.
• OdeHelper.init2(...) needs to be called only once per application, not for every thread (in fact, calling it multiple times should fail).
• OdeHelper.init2(...) needs to have returned before any thread uses ode4j.
  
• A future release may introduce more powerful mutlithreading.
  

Differences to ODE for C/C++

• API: The preferred API of the ODE projects appears to be the C API (it is more complete and contains all the documentation). The preferred API in ode4j is the OO-API.
• Class names all start with a 'D' rather than 'd'.
• The d***ID types have not been ported. Simply use the according D*** interfaces. Also, the type hierarchy has changed, the D*** classes are now interfaces that are implemented by the according Dx*** classes.
  
• Main access points in ode4j are OdeHelper (initialisation methods and a factory for creating most classes), OdeConfig (for configuration) and OdeConstants (providing many of the contants used in ode4j).
• Some of the math has been moved inside the DVector3 and DMatrix3 classes.
• ode4j provides DVector3C and DMatrix3C interfaces that provide immutable encapsulation.
  

• All global methods have the leading 'd' removed and the 2nd letter lowercased. Most of the global methods can be found in OdeHelper. For example: dInitOde2(...) -> OdeHelper.initOde2(...).
• All 'create' methods have the 'create' moved to the beginning: OdeHelper.createMass().
• To find the Java method name for a global C method, one can usually remove the dClassName from the beginning and remove the first argument, for example dJointAttach( myJoint, b1, b2 ) becomes myJoint.attach( b1, b2 ). This is also valid when looking for C++ function names in ODE itself.
  Another example: dJointSetPistonAnchor ( piston, ... ); becomes piston.setAnchor ( ... ); .
  
• Unlike ODE, the preferred policy for getting complex values from an object is not to pass in an empty array:
  DVector3 result = new DVector3();
box.getSides( result );
  but to return an immutable object:
  DVector3C result = box.getLengths();   //The trailing 'C' on DVector3C and other classes indicates and constant / immutable object.
  In many cases this avoids creating unnecessary temporary objects and also makes the code more compact. It also avoids a possible spelling mistake, when typing 'g' instead of 's' (get <-> set).
  

Migration Guide

Documentation

Source Code

• ode4j.tar.gz -> Contains the core jar file for end users.
  
• ode4j-cpp.tar.gz -> Contains the additional C-style API for end users, in case the developer uses the C-style API.
• ode4j-src.tar.gz -> All sources, including demos and test harnesses.
• ode4j-doc.tar.gz -> Generated javadoc for public API.
  

• cpp4j: This is from a different project of mine. It contains helper functions that I used for porting the code from C/C++ to Java.
  
• ode4j: This is the core repository containing all functionality to run physics simulations.
• ode4j-cpp: This provides an optional additional static C-like API (which is the preferred API in ODE for C/C++). It can be used for reference (most of the ODE docs refer to the C-like API) or when migrating projects from C/C++ to Java.
• ode4j-sdk: This repository provides additional code for developers like demos, sources, javadoc and test harnesses. There are two sets of demos; the demos in'org.ode4j.democpp' are ports of the original demos and require the C-like API (from ode4j-cpp). The demos in 'org.ode4j.demo' are updated versions of the 'democpp' demos, such that they now use the OO-API provided by ode4j.jar.
  

1. Download and install a SVN plugin for Eclipse (The following steps are for Subversive, an alternative plug-in is Subclipse)
2. Create a new SVN project from existing source
3. URL = https://ode4j.svn.sourceforge.net/svnroot/ode4j/ode4j-core
4. Press "Next >"
5. Browse to select "trunk"
6. Press "Finish"  (For SVN Project Set-Up)
7. Press "Finish"  (For check-out)

• https://cpp4j.svn.sourceforge.net/svnroot/cpp4j
• https://ode4j.svn.sourceforge.net/svnroot/ode4j/ode4j-core
• https://ode4j.svn.sourceforge.net/svnroot/ode4j/ode4j-cpp
• https://ode4j.svn.sourceforge.net/svnroot/ode4j/ode4j-sdk

Dependencies

Licensing & Copyright

Contact / Contributors