TriMesh vs TriMeshData in jMEPhysics2

I've been looking at the jMEPhysics2 library. The tutorial/demos look pretty nice; congratulations to whomever put them together! Of course, for someone to become a good physics programmer, you'll need a few more lessons, but what's there is a great start, and more than what the C++ side of ODE has.



However, I'm now trying to figure out how to create multiple instances of given meshes (trees, houses, etc) into my collision world. It looks to me as if the GeomTriMesh object actually creates a copy of the TriMeshData for each instance, which will use a lot of memory. Wouldn't the right factoring be to create just one TriMeshData per jME TriMesh, and share that TriMeshData across all GeomTriMesh instances that use it?



Am I missing something?

Of course, for someone to become a good physics programmer, you'll need a few more lessons, but what's there is a great start


??? do You mean the programmer of jmephysics2 could use a few more lessons to become a good physics programmer
but as i'm no native speaker i admit that i could have misinterpreted that. ???

hehe

no he didn't mean it that way.

This was meant for us newbies trying to learn jmephysics/ode.

I'm very happy you like jME Physics 8)


jwatte said:

It looks to me as if the GeomTriMesh object actually creates a copy of the TriMeshData for each instance, which will use a lot of memory.

That's true.

Wouldn't the right factoring be to create just one TriMeshData per jME TriMesh, and share that TriMeshData across all GeomTriMesh instances that use it?

Of course. I did not get around to do that cleanly. ://  I never used trimeshes intensively for anything else than terrain or other single meshes, that's why I never needed nice handling of copies myself. But it shouldn't be hard to add support for it.

For getting this functionality quickly one could add a map from TriMesh to GeomTriMesh into OdeMesh.copyFrom and use an existing GeomTriMesh if possible.

The reasoning that kept me from doing so, is the expected behavior from such an API: In jME trimeshes are not 'locked' by default. Which means any update to the vertices affect the visuals upon the next rendering. For jME Physics 2 this is not true. As we have to means to tell if the vertice data was modifies one would need to check/copy the vertices to ODE each frame - which is obviously not an option. That's why I introduced those copyFrom(...) methods instead of associating a TriMesh permanently with a collision geometry. Otoh 'copy from' suggests that a modification of the original data does no harm to the copied data...

To make a long story short, the trimesh API in jME Physics 2 would need a little overhaul to be satisfactory :|

Thanks for the reply!



It seems that just mirroring the ODE division of TriMesh data and geom would work fine. I e, you allocate a TriMeshData from a jME TriMesh (this copies the data); then you allocate some number of TriMesh geoms using that TriMesh. A utility function that gives back a TriMeshGeom from a jME TriMesh would be easy to build on top of that.

Yes, that's what I meant with "it should not be hard". :slight_smile: