Odejava version 0.2

Odejava version 0.2 is released. I am commiting the files now. See http://odejava.dev.java.net for information on how to checkout it from the CVS. You can also browse project files and documentation using your browser.

I have started this thread for people to comment Odejava’s higher level API and other support libraries like Xith3D toolkit library.

Higher level API has just been started.
All comments are welcome. Documentation is not complete, also API still needs some work. There exists couple examples that show you how easy it is to use.

Lower level API is stable and works very well.
There exists one simple example, documentation from ODE’s own site works perfectly as the API is one to one with ODE’s own interface.

Toolkit: Odejava-Xith3D
There exists a helper class which automatically binds Odejava objects into Xith3D shapes (or transformgroups if the object is complex).

Toolkit: Odejava-Jme and Odejava-Openmind
These are coming up.

Happy Christmas for everyone!

nice one dude ;D

I made some enhancements and fixes to the CVS, but there’s still a problem with linux platform and TriMesh. This is pure ODE problem (OPCODE actually) and it’s top priority currently to get this fixed, win32 version works fine.

The binding from Odejava into Xith3d works quite nice currently, it’s pretty easy to define objects in Odejava and get them to Xith3d automatically or by telling what ASE object , appearance or Shape3D you wish to use for given Odejava object. Check the Car demo source and tell me if you have any ideas on how to develop it further.

I hope we get the JWS demos running soon and also new website.

Are there plans to create a binding from Xith3D to ODE (currently it is ODE->Xith3D)? For instance I’d like to load an ASE model in Xith3D and add it to the ODE world.

The problem with that is that usually the 3D geom would be more complex than it’s ODE representation (for example spokes in a wheel).

You’d have to give ODE many hints on how to represent it. Eg. Should a mesh be represented by TriMesh or by it’s bounding box? Other things such as Spheres are harder again - loaded from an ASE file they are mearly meshes. Another thing that you don’t get is the relationship’s between the objects - how do you know the properties of a hinge or joint?

All of the above questions I guess could be answered if we had a seperate (.ode?) file which stored the ODE properties and a reference to the ASE file.

However I don’t think a simple Xith3D/ASE->ODE would work.

Personally I think just constructing the ODE objects then adding Xith3D TG’s to them is acceptable.

Will.

William, I’ve though the same thing but for now I’ve decided to go other way around (define physics in Odejava and offer simple OdejavaToXith3d helper class for users). It’s simpler and I got first implementation out very fast.

However for the future, here’s an interesting thread:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1072726004;start=0

It contains a project that aims defining Xith3D world (objects) on XML. This alone is nice but why not to extend it a bit and add also physical attributes to every object? This is quite simple to accomplish, but would require some work to make good XML definition.

Below is my post if anyone has any thoughs on how to go with this further on Odejava side:


For each object one could define:

  1. identity (or name) of object

  2. collision primitive(s)
    -geometry data like sizex,y,z (e.g. box)
    -local position (x,y,z)
    -complex composite objects have multiple primitives

  3. mass distribution
    -e.g. simply mass size which is centered

  4. surface parameters
    -frictions, bounciness…

There should be also common physics XML definition for the world itself that contains e.g. gravity or common friction values etc. Also joint node’s would be good, these bind two different objects to each other (e.g. leg to body) and define their attributes (how much can I move my leg related to my body) and so on.

After these definitions, not only Xith3D objects but also their physic engine objects could be created automatically using XML definition, both sides would be neatly in the same place.

Here’s one thing I’d like to clarify for people that haven’t used physic engines yet. Why to define primitives two times per object, once for scenegraph (Xith3D) and once for physics engine? Think for example a human, it’s quite complex object for 3D renderer, but for physics engine it consists of a sphere (head), cylinders (neck, arms, legs) and a torso (box). As physics calculations are quite complex it’s best to simplify objects as much as possible on the physics engine side.


[quote]Are there plans to create a binding from Xith3D to ODE (currently it is ODE->Xith3D)? For instance I’d like to load an ASE model in Xith3D and add it to the ODE world.
[/quote]
As William pointed out, I feel that this would not work for obvious reasons. But e.g. on Car demo I did this:

  1. Load your ASE object into Xith3D TransformGroup
    -on car demo I loaded tire and rim mesh into wheelTransformGroup Xith3D object.

  2. Set your own object (here an TransformGroup) into Odejava object
    odejavaToXith.addUserTransformGroup(
    “wheelFrontLeft”,
    wheelTransformGroup);

Of course here the caveat is that you have to manually create this object’s physical side on Odejava. Here the Body named “wheelFrontLeft” is simply org.odejava.GeomSphere object that simulates an wheel.

How can I handle scaled objects (scaling needed to let objects appear smaller)? Let’s say you have the following path in the scenegraph:


|
TransformGroup, which scales by the factor x (not 1)
|
TransformGroup, which is modified by ODE
|

This propably won’t work, because ODE’s internal coordinates differ from the visible ones. How can this be done?

[quote]How can I handle scaled objects (scaling needed to let objects appear smaller)?
[/quote]
I added a method called setScale to org.odejava.xith3d.OdejavaToXith3D class. You can try it out yourself. Basically I added these two lines to following methods: createTransformGroups() (scale when objects are being created), updateBodyTGs() (scale when dynamic objects are being updated) and updateGeomTGs() (scale when static objects are being updated):
// Scale objects visually
t3d.setScale(scale);
t3d.scaleTranslation(scale);

And there’s also getter and setter for the scale attribute.

This should do the trick for you. Do a CVS update and give it a shot.

I don’t currently need the feature anymore. However I tested it and it seems to work better, but it doesn’t collide with other objects when it should. I didn’t really run a useful test. If I need scaling again and experience problems I’ll tell you.

[quote]I don’t currently need the feature anymore. However I tested it and it seems to work better, but it doesn’t collide with other objects when it should. I didn’t really run a useful test. If I need scaling again and experience problems I’ll tell you.
[/quote]
Actually, the proper solution would be to add uniform scaling into org.odejava.Body and org.odejava.Geom classes. Every getPosition, getQuaternion etc. method should be scaled accordingly.

So, if you use OdejavaToXith3D.setScale(0.2f) then you have to scale all Odejava position and translation calls aswell, then scaling should work as you want.
e.g. on your app. do:

Vector3f position = myWorld.getBody(“car”).getPosition();
position.scale(0.2f);
Quat4f quat = myWorld.getBody(“car”).getQuaternion();
quat.setScale(0.2f);

Not too convinient, but it works.


Summarum, the OdejavaToXith3D is wrong place for scaling, the right place to do scaling is on Body and Geom objects. I’ll add this to todo list and ask some opinions from other people also.

I’d like to ask an opinion from you guys. Usually Odejava objects are best to keep under certain scale because of ODE.
But on the Xith3D side people usually would like to scale all Odejava objects e.g. bigger. The right place to do this is to add scaling factor to every position and translation methods in Geom and Body objects.

Because Body.getPosition() and Body.getQuaternion() calls are made very often (once per object per frame), do you see any performance loss on following code:
public Vector3f getPosition() {
return new Vector3f(
Ode.floatArray_getitem(posArray, 0),
Ode.floatArray_getitem(posArray, 1),
Ode.floatArray_getitem(posArray, 2));
}

comparing to this code:
public Vector3f getPosition() {
if (scale != 1) {
Vector3f result = new Vector3f(
Ode.floatArray_getitem(posArray, 0),
Ode.floatArray_getitem(posArray, 1),
Ode.floatArray_getitem(posArray, 2));
result.scale(scale);
return result;
} else {
return new Vector3f(
Ode.floatArray_getitem(posArray, 0),
Ode.floatArray_getitem(posArray, 1),
Ode.floatArray_getitem(posArray, 2));
}
}

I am not too good at JVM optimization but my gut feeling says that this does not affect to performance in any way, JVM optimizes these things very nicely, or am I complete fool on this case?

Below is an explanation taken from ODE FAQ:

12.8. Should I scale my units to be around 1.0 ?

Say you need to simulate some behavior on the scale of a few millimeters and a few grams. These small lengths and masses will usually work in ODE with no problem. However occasionally you may experience stability problems that are caused by lack of precision in the factorizer. If this is the case, you can try scaling the lengths and masses in your system to be around 0.1…10. The time step should also be be scaled accordingly. The same guideline applies when large lengths and masses are being used.

In general, length and mass values around 0.1…1.0 are better as the factorizer may not lose so much precision. This guideline is especially helpful when single precision is being used.

[quote]I made some enhancements and fixes to the CVS, but there’s still a problem with linux platform and TriMesh. This is pure ODE problem (OPCODE actually) and it’s top priority currently to get this fixed, win32 version works fine.
[/quote]
I forgot to mention that Linux version has been on the CVS for a while (compiled with latest GCC under Fedora). TriMesh problems have been fixed.

If anyone needs mac version and has problems compiling the library, feel free to ask help through these forums. MacOS library will get to the CVS eventually.

Here’s a small screenshot of CarTerrain simulation with Odejava using Xith3D. It works pretty nice even though it has quite a large terrain. This is with a 2GHz processor and with good GPU. However, I’ve made zero optimizations or tweaks, e.g. all objects are on the same space. But the code is very simple. This scenario has following Odejava objects:
-single TriMesh consisting of 6144 vertices (terrain)
-200 boxes
-25 spheres
-bridge made out of boxes
-car (boxes + 4 wheels with hinges)
Collisions seems to work nicely. However I noticed problems with boxes that are a lot bigger than terrain’s vertices (single triangle).

Screenshot link:
http://cray.tuug.org/~jani/odejava/carTerrain.JPG

[quote]Are there plans to create a binding from Xith3D to ODE (currently it is ODE->Xith3D)? For instance I’d like to load an ASE model in Xith3D and add it to the ODE world.
[/quote]
You can create Odejava TriMesh objects out from ASE file easily. If you want I can send you the code, basically it’s only passing vertices and indexes to org.odejava.GeomTriMesh constructor. I did this on CarTerrain example where I loaded the Terrain made with 3dstudio (CarTerrain example is not yet on CVS).

I have created a class named Xith3DToOdejava which can handle Xith3D to Odejava conversions. Currently only IndexedTriangleArray to GeomTriMesh is supported.

I needed this method for a (BSD) Xith3D/Ode terrain generation library I am currently writing so I thought I may as well plonk it in.

I will be adding some more which can create an Odejava box based on the bounding box of a xith3d object (be it a mesh or whatever). The reason this is usefull is that TriMesh isn’t always needed and a simple bounding box will do.

Will.

I decided to add CarTerrain files directly to the CVS, so now there are following new files in the CVS:
org.odejava.xith3d.test.CarTerrainExample
org.odejava.test.car.CarTerrain
terrain.ASE

This demo, like all others (except one lower level demo) are using the new higher level API. I suggest you use it as much as you can and extend it with lower level API as needed.

This newer demo has better controls, you have to keep keys down in order to accelerate the car in high speed or to steer it some direction, like in traditional games if you wish. It’s also easier to drive around as the friction is lower.

Note that the terrain is bit rough and steep in many places. Well, it’s my first terrain with 3d studio :slight_smile:

Excellent work! If you compare the result with number of lines of code for the CarTerrain, it is in a class of it’s own! :smiley:

While testing your stuff I had a couple of problems that other people might encounter as well.
First of all, if the landscape doesn’t have any texture on it, it is because the path to the texture is absolute. In the terrain.ASE file change
*BITMAP “D:\eclipse\workspace\odejava\odejava\odejava-xith3d\data\images\groundandtrees3.png”
to
*BITMAP “data\images\groundandtrees3.png”
and things should look a bit nicer. (Maybe something that Jani could change in CVS as well when you get a chance.) When debugging this I also noticed that highlighting effects only took place on backside of the terrain mesh. Drive around so that the viewpoint will end up below the surface and you will see it. Guess this is a Xith/JOGL issue. I am sure someone knows the answer to that one right away, and maybe even how to let the car cast a shadow on the ground anyone? I know this is a ode demo, but that would be so nice!

I also got some strange error messages regarding reading the ASE file. That was related to the ASE reader didn’t like the linebreaks in the file (tireAndRim.ASE). Converting it to Unix style fixed the problem (or just dl that file direct from the web instead of WinCvs also fixed it).

Hope this can be of help to someone. If you haven’t already tried it you should! Really cool stuff! Thanks Jani! 8)

I succeeded to compile libode.dylib, but can’t compile libjavaode.jnilib, in my MacOSX 10.3.2.
I read “compliling-macosx.rtf”, the command:
g++ -W -Wall -Llib -dynamiclib -o lib/libodejava.jnilib net/java/dev/odejava/ode/odejava_wrap.o net/java/dev/odejava/ode/odejava.o -lode -framework JavaVM
makes following errors;
/usr/bin/libtool: internal link edit command failed
ld: Undefined symbols:
_dCreateTriMesh
_dGeomTriMeshDataBuild
_dGeomTriMeshDataBuildSimple
_dGeomTriMeshDataCreate
_dGeomTriMeshDataDestroy
_dGeomTriMeshGetPoint
_dGeomTriMeshGetTriangle

Please, fix TriMesh problem for macosx.

[quote]Excellent work! If you compare the result with number of lines of code for the CarTerrain, it is in a class of it’s own! :smiley:
[/quote]
Thank you, I would say that this is all because of ODE :slight_smile:

Higher level API is very young still, there are some design issues that need to be solved but for simpler demos it is very usable.

I’d like to hear if anyone has made a big world (using multiple spaces) with Odejava. I know some people are looking into this.

Good point, I’ll fix this next time I do changes to Odejava.
I will also check the ASE file’s linebreaks.

About your renderer related questions. Better graphics (like shadows) are always welcome, I assume e.g. Xith3d does not support “easy” shadows feature just yet, hopefully this will be added soon.

PS. If you start an project with Odejava, be sure to write your questions, and screenshots 8), here.

Cheers, Jani!