[ODEJAVA] TriMesh <-> TriMesh collisions

[kevglass]

Does this combination work at the moment?

Kev

[William Denniss]

Not that I have seen in Odejava.  I believe it is working in ODE, but I have not really had my ear to the ground on this one as I do not need it (I just approximate my complex shapes using primitives which I find is quite accurate and fast).

If they can do it in ODE, then we can do it in Odejava basically.  I did update our ODE version very recently, so it may even work already (just nobody has tested it).  If we need to add any extra functions or whatever, please let me know.  If TriMesh<-->TriMesh is currently a patch for ODE, then the only requirement is that it can be added into our automated build proces (i.e. by using 'patch').

Will.

[kevglass]

Cheers for the quick response Will. I may have slightly misinformed here.

TriMesh <-> TriMesh collision works. Its just the physical response that doesn't seem to. In the engine thing I'm putting together primitive collision and response works fine (well, I think) but TriMesh response doesn't actually do anything.. i.e. the collisions are detected but the object falls straight through the other...

I'm not 100% why this could be happening. I imagine it gets pretty complicated with this sort of collision. Anyway... looking through the ODE user guide I'm wondering if we currently cope with this situation:

In order to efficiently resolve collisions, dCollideTTL needs the positions of the colliding trimeshes in the previous timestep. This is used to calculate an estimated velocity of each colliding triangle, which is used to find the direction of impact, contact normals, etc. This requires the user to update these variables at every timestep. This update is performed outside of ODE, so it is not included in ODE itself. The code to do this looks something like this:

1   2   3   4   5

const double *DoubleArrayPtr =     Bodies[BodyIndex].TransformationMatrix->GetArray();   dGeomTriMeshDataSet( TriMeshData,     TRIMESH_LAST_TRANSFORMATION,     (void *) DoubleArrayPtr );

The transformation matrix is the standard 4x4 homogeneous transform matrix, and the "DoubleArray" is the standard flattened array of the 16 matrix values.

If not this might explain why the response doesn't happen as expected since ODE can't caculate velocities for the trimesh?

Thanks again for the swift response,

Kev

Games published by our own members! Check 'em out!

[William Denniss]

Sorry this responce wasn't quite so swift - had a big weekend.

That code isn't in odejava which could explain your problem.

The dGeomTriMeshDataSet function isn't exposed.  I can add this to the interface file so it is included next time the natives are rebuilt.

Is that all you need?

1   2

const double *DoubleArrayPtr =     Bodies[BodyIndex].TransformationMatrix->GetArray();

I can't see a get transform matrix method in the API docs.  I guess we could simply create our own using dGeomGetPosition and dGeomGetRotation.

Will.

[kevglass]

That'd be useful, just to see apart from anything else if TriMesh collision actually works.

I'm suprised the GetArray() method isn't there, the quote was from the ODE user guide which I'd assumed would be correct

I'd guess that if the function doesn't exist then maybe the documentation is out of date and this might not be the problem? Might be time to check with the ODE folks direct...

Hope all these queries arn't too annoying, been meaning to have a play with ODE for ages and it suddenly seems I have time.

Kev

[kevglass]

PS: Is there a nightly build that can be picked up publically?

DarkProphet over at JME forums isn't seeing any of these issues, wondered if maybe he'd built his own release or something and these issues have automagically disappeared.

Kev

[darkprophet]

DarkProphet over at JME forums isn't seeing any of these issues, wondered if maybe he'd built his own release or something and these issues have automagically disappeared.

Nope i haven't built anything, im using the latest ODE release.

What im doing however is when it comes to trimeshes is apporximating them according to their BoundingVolumes. Then i let the user decide (using jME triangle accurate collision detection) whether they should carry on with the response or cancel the contact.

However, having said that. Static triangle collision detection seems to work fine .

Ie. Terrain <> Sphere; that works fine. Also Terrain <> Box works fine also.

DP

[kevglass]

Ah yes, but the physical response on collision of trimeshes isn't working. The detection of the collision works ok but the bounce (or whatever) doesn't.

Out of interest, which way have you got gravity?

Kev

[darkprophet]

-9.81 (sweden apparently have it as -9.82!)

But hold on, why is Sphere <> TriMesh working then?

DP

[kevglass]

Na, I meant are you using z or y for gravity influence?

Kev

Games published by our own members! Check 'em out!

[darkprophet]

y to influence...sorry, i didn't understand what you meant..

DP

[kevglass]

The dGeomTriMeshDataSet function isn't exposed.  I can add this to the interface file so it is included next time the natives are rebuilt.

Is that all you need?

That'd be great.. I think with this we could have moving trimesh collisions which I'd quite like

Kev