Contact / Contributors
Main contributor:
Tilmann Zäschke: ode4j AT gmx DOT de
Please see GitHub for other contributors.
Want to Contribute?
Contributors are welcome.
To
avoid misunderstandings: What probably doesn't need
doing
I know that the current look of the code might bring tears
to the eyes of any reasonable Java developer (public
non-final fields, lots of commented out stuff, lack of
abstraction, duplications, ...). However, there is a
reason: I want the code to be as close as possible to the
C/C++ original in order to simplify future porting of
updates from C/C++ to Java. In some places I had to
implement significant changes in order
to keep performance acceptable, but other than that, the
internals should stay as they are, which is as close as
possible to the original.
The same is true for org.ode4j.math, which is not
perfectly nice Java, but which I believe strikes a
reasonable balance between beauty and performance.
Recommendations for minor changes are welcome, but I would
probably not agree on refactoring it (also to maintain API
compatibility).
Generally, I also prefer any fixes to ode4j also to be
applied to ODE, ideally before they end up in ode4j.
Unless of course the bug is specific to ode4j/Java.
What needs doing
- Complete multi-threading support
- Port OPCODE Trimesh collision engine to Java. OPCODE is
the default trimesh library in ODE C/C++ and is supposed
to be more stable than GIMPACT in some cases.
- Fix GIMPACT. GIMPACT is somewhat broken, but it is not
updated anymore in the original ODE C/C++, so it could be
refactored for bug fixing or performance improvements.
- Improve Javadoc of public API.
- More ideas, anyone?
|