Extract mesh from terrain for external physics engine

Troubleshooting terramonkey
1

Hi all,



I’m using jME for academic purposes, for visualiation of a mobile robot simulation based on the nVidia PhysX physics engine (I know jME comes with JBullet now but not at the time I created the simulation, plus I was working on top of existing code). I’d like to create a more complex terrain than the ones I’ve been using so far so my idea is to create the terrain in jME and then extract the triangle mesh to duplicate it in PhysX. I need to do all this programmatically since I need to randomly generate terrains on the fly.



So it seems I should do something like:

  1. Generate a height map
  2. Create a TerrainQuad based on the height map
  3. Extract all TerrainPatches using TerrainQuad.getAllTerrainPatches(java.util.List holder)
  4. For each TerrainPatch tp in holder:



    [java]Mesh m = tp.getMesh();

    java.nio.FloatBuffer vb = (FloatBuffer) m.getVertexBuffer( VertexBuffer.Type.Position ).getData();

    java.nio.IntBuffer ib = (IntBuffer) m.getIndexBuffer();

    float[] vertices = vb.array();

    int[] indices = ib.array();[/java]


  5. Concatenate the arrays of vertices and the arrays of indices and pass them to PhysX, together with the triangle count.



    Does that look about right? Thing I’m worried about is jME’s adaptive (based on camera position) LOD implementation; I just want to create the mesh in PhysX once, with uniform LOD. Is it correct that if I don’t add a TerrainLodControl when I generate the terrain, the LOD will be uniform? Is there a way to specify how detailed the uniform LOD should be?



    The other thing I’m worried about is whether PhysX will interpret the indices “counter-clockwisely”, but I guess I’ll just have to find out.



    Thanks

    Matt



    Edit: Third thing I’m worried about: does the order in which I loop through the TerrainPatches matter?
2

Yep that is all correct.

If you do not add the TerrainLodControl to terrain then the geometry is not changed and will have its original high-detail format. That control just changes the indexes of the mesh, the underlying height data is still available.

Look into physX and how it handles terrain, I’m certain it should be using a heightfield (as bullet does) as they are significantly faster for collision than regular meshes. (edit: it looks like physX does handle heightfields)

The indexes are complicated with terrain, so it might not be worth using the existing ones you extract, especially if you are building one big mesh in the end. It will no doubt be easier to extract everything but the indexes and just build up a straight triMesh.



Looping through terrain patches should not matter if you have them lined up correctly. You can use each one’s worldTranslation to find that out.

1 Like
3

Ok great, many thanks for the tip on the heightfield! PhysX does indeed provide this functionality, so what I now do is generate a height map, and use that map to create both the heightfield in PhysX and the terrain in jME. I just need to offset the the heightfield in PhysX and adjust some other parameter (the way it tesselates the triangles) to make it match jME. Works like a charm, super fast.



Thanks also for confirming that my initial approach was correct. Always useful for when I need to do something more complex.