Is there a utility function to go from a Node to a number of TriMesh objects, or even better, a single baked TriMesh object?
Specifically, I'd like to use that with the jME Physics 2 GeomTriMesh collider.
It wouldn't be that hard to write; just walk the Node tree, get the geometry from everything, and transform it into a growing list of triangles. But it seems like something that ought to already exist, so I don't want to do work I don't have to!
Don't think such a thing exists… What you would want to check, though is probably not a growing TriMesh, but a TriMesh with several GeomBatches (TiangleBatch)… since they can actually also have a transformation attached to them.
I want to create one large, global trimesh that represents the entire static part of a level geometry. The ODE triangle collider is most efficient with all the triangles in one big batch. Well, at least the OPCODE one is – I just noticed jMEPhysics changed to GIMPACT – any reason for that? I find OPCODE is more stable for everything except mesh<->mesh.
I think there was some piece of code capable of that on the boards, but I can't find it now 
jwatte said:
Well, at least the OPCODE one is -- I just noticed jMEPhysics changed to GIMPACT -- any reason for that? I find OPCODE is more stable for everything except mesh<->mesh.
Actually I switched to GIMPACT because my feeling was OPCODE was not that stable . Esp. in the newer versions of ODE (somewhere between 0.8 and 0.9) OPCODE exposed some weired contact generation issues I didn't want to debug... but it's easily changed back to OPCODE by modifying the odejava-jni build script/project and rebuilding the natives...
I think geometryinstancing have what you need… Either way I think that there should be a way to either share or combine meshes on the jMEphysics side rather than having to do it in user code.
Momoko_Fan said:
I think geometryinstancing have what you need.
I don't think so. It's for duplicating meshes (in a single mesh) rather than compiling a node to a single mesh.
The geometryInstancing merges multiple TriMeshes into one large TriMesh… The instances can be different meshes, so there shouldn't be any problems if they all have the same renderstate.
jwatte said:
I want to create one large, global trimesh that represents the entire static part of a level geometry. The ODE triangle collider is most efficient with all the triangles in one big batch. Well, at least the OPCODE one is -- I just noticed jMEPhysics changed to GIMPACT -- any reason for that? I find OPCODE is more stable for everything except mesh<->mesh.
Then you would be losing textures and materials, which might be ok if you need that trimesh only for physics, and if you need only one physics material.
I have a question about what you said. Would it really be faster? Doesn't ODE use the bounding boxes first to check for collisions, and then evaluate triangles if needed?
Sorry if I sounded weird. Just trying to understand this a bit more.
On the ODE mailing list, a few years ago, someone made a benchmark of a bunch of little trimeshes, versus one large trimesh. The large trimesh won out.
Btw: you can implement multiple physics materials with a large trimesh if you want, by using the "hit triangle" return values from ODE. Don't know if those are exposed in odejava, though.
I see. I've been reading a bit more and seems that ODE uses its own space partitioning techniques (Quadtrees I think). It probably doesn't matter too much if the triangles belong to one, two or 200 "nodes".
Thus, the only problem here is that ODE is storing a second copy of the geometry, which anyway I think we already knew.
I am interested in the "hit triangle" feature you mention, which would be useful to freely specify friction and material properties (based in, i.e., texture, or any other metadata). However for that to be really useful the triangle returned would need to be contextualized to the appropriate node in the jME scenegraph. Additionally, I wonder if that facility would behave like a "callback function". I am totally clueless here. What about the list of joints you can get per simulation step? Can you define friction, materials and bounciness using that?
Thank you for your patience.