Has anyone a function to do that ?
I tried to write my own function, but it seems not to treat all the vertices…
Or has anyone detailed informations on how TriangleArrayS are working ?
For an IndexedTriangleArray with normals, I just do:
geomMesh = new GeomTriMesh(“floor”, ga.getCoordRefFloat(),
ga.getNormalRefFloat(),
((IndexedGeometryArray)ga).getIndex());
Edit:
You sould also grab the newest Odejava from CVS. It resolves a GeomTriMesh issue.
[quote]For an IndexedTriangleArray with normals, I just do:
geomMesh = new GeomTriMesh(“floor”, ga.getCoordRefFloat(),
ga.getNormalRefFloat(),
((IndexedGeometryArray)ga).getIndex());
Edit:
You sould also grab the newest Odejava from CVS. It resolves a GeomTriMesh issue.
[/quote]
Thank you very much.
I will try it as soon as possible.
I think “ga” mean GeometryArray and is a TriangleArray ?
Are the “getCoordRefFloat()” and “getNormalRefFloat()” new functions in Xith3D ? ( I will upgrade to last binaries, but for instance I’m using an old version ).
What is the bug that is resolved about TriMeshS in Odejava ?
I’ve seen a bug with negative Z values in an Odejava forum thread, but this isn’t what I’ve experienced.
The bug I have is that my terrain ( a GeomTriMesh ) generate collisions only on a part of it.
When I move my character on the terrain, at the half of the terrain, my character fall through it…
But I will try your solution and update to the latest versions of Xith and Odejava, and I will see what happen !
Thanks !
ga is a GeometryArray. I don’t think getCoordRefFloat() and getNormalRefFloat() are new (not in the last 9 months or so). The GeomTriMesh bug in OdeJava had to do the vertexString and triangleStride used for the vertex and index arrays and was causing the ODE TriMesh to be interpreted differently than the specified OdeJava GeomTriMesh (this at least partially explains the holes in your mesh).
Thanks ewills…
Also I have another “problem”.
I’ve grabbed the latest Odejava from cvs, but I can’t compile it…
I have an “evil” (;D) error message :
`bluesky@dhcppc1:/mnt/hda6/Programmation/Java/latest-odejava/odejava/odejava/compile $ ./make-gcc.sh
[Testing env variable. The next line should print the location of your java installation (eg. /usr/java/j2sdk1.4.2/)]
/usr/lib/sun-j2sdk1.5.0/
[registering JAVA_INCLUDE path]
/usr/lib/sun-j2sdk1.5.0//include
[removing old files]
[Compiling Odejava swig]
[creating ODE-lib]
(… all right)
[creating libodejava.so]
…/odejava/odejava_wrap.cxx: Dans function « void
Java_org_odejava_ode_OdeJNI_dGeomGetQuaternion(JNIEnv*, _jclass*, long long
int, long long int) »:
…/odejava/odejava_wrap.cxx:769: error: cannot convert float*' to dReal*’ in
assignment
(…a lot of others convertions errors)
g++: …/odejava/odejava_wrap.o : Aucun fichier ou répertoire de ce type`
Can you help me ?
ooo… I’ve never tried to compile the binaries. Do you need to? You should be able to use the latest OdeJava from CVS (compile with ant) with the most recent binaries.
Okay, I used the latest binaries.
But there is a problem anymore : the collision detection seems to work well, but it don’t seems to act properly. Maybe should I try dContactApprox1 ?
Yes. I use dContactApprox1.
I have a lot of problems with terrain interaction…
Aaahhh… maybe I won’t use anymore Odejava because of that…
It’s really irritating : I move some cubes (~50) on a surface ( TriMesh ). They slide normally, but sometimes, there’s one that fall through the terrain. And one minute after the beginning, well there’s no more cube on the surface !
I will try to prepare a .jar file so you can see the problem yourself.
the good news is that ODE has an UNSTABLE branch now which seems to be getting weekly patches. Most of them seem to be related to tri-mesh stuff so let’s hope they make it a bit more stable.
I agree with you, it can be annoying.
There are some tricks, like making sure your terrain has positive Y values.
Will.
Try grabbing the latest odejava from CVS. I just now committed a change that improves TriMesh performance.
Yes, I’ve seen on the Odejava board that both TriStride and VertexCount were wrong. Okay, so I’ll grab it and try.
However, my terrain work a bit well since I changed from dContactApprox1 to dContactApprox0.
The unstable branch of ode is really a good thing.
Here I would just thank all Linux, Java, OpenGL, JOGL, Xith3d, ODE, Odejava… developers to make so many things in the open-source world possible !
Personally I’m doing a little improvement by “merging” ( unofficially ) Xith3D and Odejava.
I think it’s an interesting stuff… Just think the power of creating an object like this :
Immobile ground = new Immobile("Herb", new Point3f(0f,0f,0f), new Point3f(0f,0f,0f), "Data/Herb.obj", Immobile.TriMesh );
You define the name, the position, the rotation, the graphic data, and the physic representation of an object just in the constructor.
And here’s a little enemy example :
Mobile robot = new Mobile("Robot", new Point3f(5f,8f,2f), new Point3f(0f,0f,90f), "Data/Robot.3ds", Mobile.Cube, "Robot", "100" );
Here you define the name, the position, the rotation, the graphic data, the physic representation, the behavior, and the behavior parameter of the object. And there is a Robot class ( child of Behavior ), of course.
And now think you can load all these datas from a file.
And think you have a World editor to edit all this graphically and user-friendly. What’s more, you can edit the World separetely from the game code, because we don’t need to instance the behaviors classes to place objects. So it’s easy separe task to organize projects.
And think you have a ton of other stuff to manage graphics, IA, sound, UI… And you have thinked of Gamma.
Your feedback would be appreciated.
yup nice one 
But I think it’s a bit limited. As an example how do you want to animate your robot? There has to be interaction between the class controlling the objects and the mesh itself.
What are the semantics of dContactApprox0? I don’t see it in the ODE user’s guide…
By the way, you can use this method that I created:
org.odejava.xith3d.Xith3DToOdejava
public static GeomTriMesh createTriMesh(com.xith3d.scenegraph.TriangleArray array, String name);
I use it in conjunction with a heightmap generator. Works great, my vehicles stay on the trimesh no worries.
ewills, thanks for the bugfix btw ;D
Cheers,
Will.
[quote]By the way, you can use this method that I created:
org.odejava.xith3d.Xith3DToOdejava
public static GeomTriMesh createTriMesh(com.xith3d.scenegraph.TriangleArray array, String name);
I use it in conjunction with a heightmap generator. Works great, my vehicles stay on the trimesh no worries.
Will.
[/quote]
Yes, in fact I inspired me from that code and I integrated it in Gamma, just adding a splitter for large terrains ( < 10 000 triangle ).
Arne, you can do something like that in Gamma :
MD2Model md = null;
public void init ( Mobile m, String s ) {
md = (MD2Model) findObject( m.bg, "MD2Model" );
}
public void step () {
if( isWalking ) {
md.setAnim("walk");
m.advance(); // Gamma function
}
}
So it’s not limited as you thinked. Note that the findObject(Group g, String type ) method look for an object in the group g of the class type.
And something I’ve forgotten to say : Behavior can send messages from one to another. It’s really useful :
class Door extends Behavior {
public static final int OPEN = 0;
public static final int CLOSE = 1;
public boolean opened = false;
public void sendMessage( int m, string s ) {
if( m == OPEN ) {
opened = true;
m.setPos( initialPos.x, initialPos.y, initialPos.z+2 );
}
if( m == CLOSE ) {
opened = false;
m.setPos( initialPos.x, initialPos.y, initialPos.z );
}
}
}
class Player extends Behavior {
step() {
for( Object o : uni.lCollision ) {
if( o instanceof CollisionMM ) {
CollisionMM cmm = (CollisionsMM) o;
if( cmm.mobile1 == this && cmm.mobile2.getName().startsWith("Door") {
cmm.mobile2.sendMessage( Door.OPEN, "" );
}
}
}
}
}
So what do you think of that ?
Ok so you manage animations and movents outside the Behaviors. The Behaviors so merely handle communications and other not geometry applying stuff. I thought you were doing this stuff also inside the Behavior classes.
Nice 
I think it would be good to use it for SpaceBomber but there is one main problem : SpaceBomber is precisely an example on how to use Odejava and Xith3D…
… and not an example of how to use gamma. In the case of Spacebomber things should be also simple enough, so gamma won’t be needed anyways.