GeomCyclinder

Has the cylinder dissapeared from ode or something?

Hmmm.
I replaced the cylinder with a a tri mesh and my god. I am astonished by how slow the tri mesh is.
How do people do wheels now?

Could we overlap a box with a sphere and return collision true iff both the objects say they have been collided with?

The cylinder is a contrib module for ODE. When I updated the binaries a while back I didn’t add it back in (at that stage I was more concerned about getting it working on a mac).

I use spheres for wheels, I thought everyone did :slight_smile: Logically I agree that cylinders make more sense.

I have been communicating with a guy named Levent over email who has been trying to get this support back in. I’ll direct him to this thread.

Will.

Since cylinder support was last added in there is a new cylinder contrib module, I think we should use it instead of the older one.

Here’s what I did: Checked out from CVS the ODE source. In the ode folder (the one which has src as its sub folder), I run:

patch -p1 < …/contrib/dCylinder2/dcylinder2.patch

That patches the code adding in the cylinder contrib module.

added:


        ode/src/collision_cylinder_box.cpp \
        ode/src/collision_cylinder_sphere.cpp \ 
        ode/src/collision_cylinder_trimesh.cpp 

to the Makefile.

So far everything is fine :slight_smile:

Then I built and installed the new Ode version

I uncomment out the line in GeomCylinder.java, then try to create one in my scene.

The program crashes with:
“ODE INTERNAL ERROR 2: geom must be placeable in dGeomSetBody()”

Any thoughts? Can you try the above steps and tell me what you get?

Will.

Jeez, I dunno.
I have patched it all and got it running. I got the same error as you.
I have started probing the ode source to locate the problem. The thing is though as soon as I probe and area where it crashes it will stop crashing at that point and move somewhere else.
I can now create the cylinder but then when getPosition is called as part of updtaeReferences it will sometimes crash there and say the Geom is not placeable.
If I probe that I can sometimes get it to keep going until my code calls
setPosition.
At that point it always hangs when it tries to write into the array that represents the position of the geom.

I have not worked in C/C++ for a while. I had hoped not to with javaode :-). But my thoery at the moment is that its some kind of memory cleanup problem. The memory for the Cylinder is being tydied up for some reason. If I reference the memory it keeps it alive a bit longer, but ultimatly it will be tidied.
I thought perhaps it was something to do with how the JNI keeps pointers alive? So I loked more closely in the SWIG file stuff. Couldn’t see anything that looked wrong but this is all new stuff to me.
I shall keep looking though

My god. I have solved it. Da da da da da daa, hey!
The problem is in the Swig file: odejava.i
the dCreate for the cylinder
says the return type is a *
when it is not
(have a look at the other dCreate, you see how it idfferers subtly)
DOH!

Well now the cylinders do not collide with anything. Not at all. With themselves or tri meshes or spheres.
I could imagine a few missed collisions as bugs but not a single collision once is too rediculous, especially with all the extra extra cpp files with tons of code in them
So the quest for cylinders continues…

Right. Well the problem was that patch doesn’t do all the work that is needed.
It seems to miss doing the header file prototypes
it takes bloody ages
this is the file with the info
ode/contrib/dCylinder2/cylinder_collider.txt
also you need to update the build file to compile the extra files that are added
I dunno what the best way of transfering my knowledge over it. I could cut an paste crappy instructions like the txt file does. But its really not very helpful.
Anyway …
I have cylinders, they certainly do bounce into things, I am not sure if they are working quite right yet. It may be my graphics arn’t alligned with the cylinder so I shall investigate.
Also it seems collisions are only defined for cylinders to sphers boxes and trimeshes. Though that may not be true if the functionality is hidden somewhere
What a bloody day! Bloody C.

Xith draws its Cylinders aligned differently to ODE.
Heres some code that will fix that


private Shape3D createCylinderShape(GeometryCylinder geometryCylinder) {
        IndexedTriangleArray geom = (IndexedTriangleArray) CylinderGeometry.createCylinder(geometryCylinder.getRadius(), geometryCylinder.getRadius(), geometryCylinder.getLength(), 20);

        Matrix4f transform = GeomUtils.getMatrix(new Vector3f(), new Quat4f(0,1,0,1));

        Point3f temp = new Point3f();
        for(int i = 0; i < geom.getVertexCount(); i++){
            geom.getVertex(i, temp);
            transform.transform(temp);
            geom.setCoordinate(i, temp);
        }

        return new Shape3D(geom, backup.getDefaultSphereApp());

    }

[quote]Right. Well the problem was that patch doesn’t do all the work that is needed.
It seems to miss doing the header file prototypes
it takes bloody ages
this is the file with the info
ode/contrib/dCylinder2/cylinder_collider.txt
also you need to update the build file to compile the extra files that are added
I dunno what the best way of transfering my knowledge over it. I could cut an paste crappy instructions like the txt file does. But its really not very helpful.
Anyway …
I have cylinders, they certainly do bounce into things, I am not sure if they are working quite right yet. It may be my graphics arn’t alligned with the cylinder so I shall investigate.
Also it seems collisions are only defined for cylinders to sphers boxes and trimeshes. Though that may not be true if the functionality is hidden somewhere
What a bloody day! Bloody C.
[/quote]
What a pain that the patch doesn’t do everything - I thought it was bad not patching the Makefile but it sounds much worse. Just how long does it take to fully patch the source?

I did see that .txt file but shuddered, manually applying patches is not something I enjoy.

I think we should petition the ODE mailing list for a better patch file. Can you create a patch of the work you have done?

Congratulations on getting it working! Using C/C++ really is a pain in the arse.

Will.

I have sent an email to the ode mailing list about the patch. I have tried making one but its a bit confusing.
I have put up a tar of my compile directory at
http://users.aber.ac.uk/ttl0/compile.tar.bz2
That has ode configured to DEBUG
Has the geom cylinder support
The make-gcc.sh file copies the libodejava.so into the odejava/lib/linux directory.
It has the ode random seed thing added.

I added my $0.02 on the mailing list as well.

I’ve committed in the “void dRandSetSeed (long seed);” addition to odejava.i so next time we recompile it will be included.

Will.