CODEWITHSUNDEEP
libgdx
vtni
vtni

Reputation: 980

Move position of mesh in libgdx

I have a world with some polygons (shapeRenderer) and want to have an arrow which moves when the user changes his GPS position. i thought i could do it with meshes, but i didn't find any option to move the mesh to another position.

Mesh mesh = new Mesh(true, 6, 0, 
        new VertexAttribute(Usage.Position, 2, "a_position")
);
mesh.setVertices(new float[] { -0.3f, -0.3f,
            0   , 0,
            0f  , 0.7f,
            0   , 0,
            0.3f, -0.3f,
            0f  , 0.7f  });
mesh.render(GL10.GL_TRIANGLE_STRIP, 0, 6);

Is there a option to change the position of the whole mesh? or can i get all of the vertices to create an new mesh with the new position?

Upvotes: 2

Views: 3198

Answers (2)

Daniel Funicello
Daniel Funicello

Reputation: 21

I know this is old but what I do is

mesh.transform(matrix);
mesh.render();
mesh.transform(matrix.inv());

Upvotes: 2

P.T.
P.T.

Reputation: 25177

There are (at least) a couple ways to "move" a mesh. There is no specific support in Libgdx for this, its just the same options any OpenGL app has:

  1. Change the vertices
  2. Use a translation matrix
  3. Render the mesh to a texture and move the texture around

To change the vertices you will have to keep track of the float[] and mutate it (or re-create it) when you want to "move" the mesh. You can invoke setVertices again with the new data.

For the translation matrix approach see How do I rotate or translate individual object instances in OPENGL? However, note that this is mostly deprecated with more recent OpenGL APIs. (I'm not entirely clear with what they replaced it with, though: I think you're supposed to do the matrix math on your own, which is basically option #1.)

For the render to texture option, use a Libgdx FrameBuffer object, render to that, then use a Libgdx Sprite to move/render that texture. Note that the Sprite implementation is just built on a simple quad of vertices and is effectively doing option #1 to move the sprite around the screen, so this option makes sense only if your mesh is really complicated and has lots and lots of vertices.

Hmm... Now that I've written that out, it looks like all three boil down to option 1: you should track the actual location in the mesh vertices yourself.

Upvotes: 3

Related Questions