[odejava] Weird GeomTriMesh problems

Game Mechanics
#41

I have a question regarding vertex stride in GeomTriMesh.java.
Shouldn’t vertex stride be 12 instead of 3 since we’re using float arrays for the vertex data? Changing the vertex stride to 12 and Ole’s example suddenly works… better (but not perfect).

Edit: Okey, feel like I’m spamming this thread. :slight_smile:
I discovered that if I do my own collision checking with dCollide (colliding every geom against each other manually), then I get contacts where the space-collision approach doesn’t. I can’t however, get dCollide to work with more allowed contacts than 1, probably since I’m not sure how big the skip-parameter should be.
If anyone is interested, I’ll post my code.

Is there some bug in how trimeshes are added to spaces?

#42

Which Space type are you using? As noted above, there seem to be some problems with HashSpace.

#43

well, actually it was me who pointed out the trouble with HashSpaces :wink: but there seems to be issues with SimpleSpaces and QuadSpaces as well, since changing the space-type in the code posted by Ole does not help at all.

Changing the vertex stride to 12 helps, but all sphere’s are still not colliding.

Manually collision check all geoms against all other geoms and create the contacts and contactjoints really helps. All sphere-trimesh collisions are detected but I can’t figure out how to get more than one contact per geom. If anyone can help with dCollide(…) I’ll be grateful.

#44

Sorry about that :slight_smile: Your observation about Space types really helped me!

From the ODE user guide:

// as long as dReal == floats
dGeomTriMeshDataBuildSingle (TriMeshData,
// Vertices
Bodies[BodyIndex].VertexPositions,
3sizeof(dReal), (int) numVertices,
// Faces
Bodies[BodyIndex].TriangleIndices,
(int) NumTriangles, 3sizeof(unsigned int),
// Normals
Bodies[BodyIndex].FaceNormals);

So it looks like both the VertexStride and TriStride should be 12? Have you tried changing both? I find it difficult to believe GeomTriMesh would work at all if both values are actually wrong. I’ll play around with it today or tomorrow if I have time…

Edit:
fixed typo

#45

Update:

GeomTriMesh seems to work really well with both VertexStride and TriStride set to 12. It works with all three space types, but I haven’t tried mixing positive and negative z coordinates. This would sure explain some of the TriMesh weirdnesses. I would like a few more people to confirm that things are better with this change (and agree that it is correct), and then I will commit it (or someone else can).

#46

[quote]I would like a few more people to confirm that things are better with this change
[/quote]
Where can this version be downloaded from?

#47

That’s sort of a catch-22 :slight_smile: I think the best thing to do is grab the latest CVS from the Odejava project home page, change the 3s to 12s on lines 249, 253, 259, and 263 of GeomTriMesh.java, and then recompile the .jar.

#48

yeah, I agree that Tristride should probably also be 12. However, I get hotspot crashes for certain meshes after changing the stride parameters to 12 (I’m loading from .obj files). Not sure what to make of it.

And I still think there is some space-bug, since I’m still not getting all triangles to generate contacts using spaces.

Java VM: Java HotSpot™ Client VM (1.5.0_01-b08 mixed mode)

Problematic frame:

C [odejava.dll+0xc57e]

Stack: [0x00030000,0x00070000), sp=0x0006f838, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [odejava.dll+0xc57e]
C [odejava.dll+0xc941]
C [odejava.dll+0x64f6d]
j org.odejava.ode.Ode.dGeomTriMeshDataBuildSingle1(Lorg/odejava/ode/SWIGTYPE_p_dxTriMeshData;Lorg/odejava/ode/SWIGTYPE_p_float;IILorg/odejava/ode/SWIGTYPE_p_int;IILorg/odejava/ode/SWIGTYPE_p_float;)V+24

#49

That’s troubling… I certainly don’t want to commit a change that will break some people’s apps. However, I think this change is needed to make TriMeshs behave properly. What to do?

I don’t think there’s a Space bug on the Odejava side, but there might well be one the ODE side. Are your objects traveling at velocities great enough to cause tunneling effects? I have noticed that TriMeshs are particularly susceptible to tunneling due to the lack of volume in the TriMesh planes.

#50

well, I’m modding the code example posted by Ole Friis earlier in this thread. A few spheres don’t collide, even with the trimesh-loading changes. I also get different results if I add another geom to the space before the trimeshes. Not high velocities at all, only gravity -9.8 affecting the spheres.

Perhaps someone could try the code example and verify this as well.

Doing collisiontesting without spaces does work as noted earlier.

#51

Hi!

You guys rock! Yes, by changing the 4 lines in GeomTriMesh.java, it almost works! Sometimes when I run the demo, all the collisions are detected, and no spheres go through the trimeshes. But sometimes two certain spheres pass through. It’s got nothing to do with changing anything in the code, since I don’t do that, I just run the demo again and again :slight_smile:

This behaviour does seem like a problem with some algorithm based on nondeterministic behaviour, just like I suppose a HashSpace is. (Though I haven’t looked at the code, so I don’t know if it actually does behave in a deterministic manner.)

I guess this is a big step towards getting rid of these trimesh problems. Let’s hope somebody find out how to get rid of the last problems. (My girlfriend needs to use the computer this week-end, so I’m afraid I don’t get that many chances at having a look at it…)

Anyway, thanks a lot to you people for the work so far!

Ole

#52

harryk - what’s the status of the native crash caused by the VertexStride and TriStride change?

I would like to commit this, but not if it will break some standard code.

#53

I say submit! :slight_smile:
I only had native crashes on one or two meshes, but most work great.

#54

Done and done!

#55

I just fixed a bug concerning this:
The invocation of dGeomTriMeshDataBuildSingle and dGeomTriMeshDataBuildSingle1 with correct stride (12) caused crashes and strange collision behaviour here. I debugged into the natives and found ode to read beyond the limits of the vertice array. This was caused by the wrong VerticeCount - it must be vertices.length/3 !

So the correct invocation would be

Ode.dGeomTriMeshDataBuildSingle1(data, tmpVertices, 12,
vertices.length/3, tmpIndices, indices.length, 12, tmpNormals);

(this also explains why it kind of worked before changing to 12, too)

Additionally I have to mention that the value 12 is platform dependent - on a system where the floating point numbers are different size than 4 bytes everything will go wrong again.

#56

sorry to be naive, but on which OS is a float not 4 bytes?

DP

#57

The ODE user’s guide says:

// as long as dReal == floats
dGeomTriMeshDataBuildSingle (TriMeshData,
// Vertices
Bodies[BodyIndex].VertexPositions,
3sizeof(dReal), (int) numVertices,
// Faces
Bodies[BodyIndex].TriangleIndices,
(int) NumTriangles, 3sizeof(unsigned int),
// Normals
Bodies[BodyIndex].FaceNormals);

So yes, I agree that the call wants the vertex count and not the number of vertex coordinates. I’ll commit this change as soon as I post this.

Also, I’m not aware of a Java equivalent to sizeof… any ideas?

Edit:
Thanks for debugging this, irrisor.

I committed the change and TriMeshs seem to be working really well.

#58

Sorry to bring this up again, but im having trouble with this…and none of the above seems to make a difference to it.

Its really strange, imagine 9 squares in a trimesh in a grid like manner (its part of a larger mesh btw). Each square is made up of 2 triangles…When i pass this mesh to ode, most of the triangles work fine, but some dont. The objects go straight through some of the triangles (esp the middle square’s left triangle). Also, it can’t be the winding because the triangle fails from both sides.

I also tried not passing any normals, seeing if that helped, it didn’t…:-\

Any ideas?

DP

#59

Space-bug perhaps? Have you tried collisiontesting not using spaces or used a simple space?

#60

Im using HashSpace, i changed to SimpleSpace and the problem is still there…

DP