Return to Question

I'm working on a libgdx implementation of mesh terrain and running into some performance issues.

The terrain is represented by a number of mesh tiles, each mesh is made of vertices laid onto a 2D plane.

The implementation of the meshes is done via libgdx Mesh, each of which is cached after its initial generation. I use GL3.0 and therefore the vertices are handled via VertexBufferObjectWithVAO which as I understand it should allow GPU caching.

Performance is sluggish, I have tried to increase the number of vertices in each mesh (while keeping the same overall amount of vertices) but weirdly the performance gets worse rather than improving.

I think I'm missing something out in the OpenGL pipeline, in my mind the way is should work is meshes are sent to GPU once, the larger the mesh the better as less draw calls but this doesn't align with the results I'm getting.

To give you an idea of the size of the meshes the initial set up was: 7,200 vertices * 625 meshes in a single draw call. FPS were worse when trying 100 meshes with ~45,000 vertices.

*edited to clarify that I have tried to group the vertices into less amount of meshes to reduce number of drawcalls

I'm working on a libgdx implementation of mesh terrain and running into some performance issues.

The terrain is represented by a number of mesh tiles, each mesh is made of vertices laid onto a 2D plane.

The implementation of the meshes is done via libgdx Mesh, each of which is cached after its initial generation. I use GL3.0 and therefore the vertices are handled via VertexBufferObjectWithVAO which as I understand it should allow GPU caching. Meshes are indexed.

Aiming to optimise performance, I have tried to increase the number of vertices in each mesh (while keeping the same overall amount of vertices) but weirdly the performance gets worse rather than improving.

Question 1: any possible reasons why given the same total number of vertices the scenario with lower amount of meshes (#3 below) is slower than the scenarios with higher number of meshes?

Question 2: based on the OPENGL pipeline summarised below is it correct to assume that VBOs are being transferred to the GPU once and then drawn via GPU memory reference?

Performance comparison

1. 1,600 meshes * 3,042 vert (4.8M vertices) -> 131 FPS

2. 625 meshes * 11,250 vert (4.5M vertices) -> 132 FPS

3. 100 meshes * 45,000 vert (4.5M vertices) -> 113 FPS

Hardware Details

GTX660 2GB Memory Utilisation during test 70% in all scenarios. Vertex allocation memory impact seems to be negligible compared to textures.

OPENGL pipeline

From API TRACE, this is the frame life-cycle in summary

mesh generation (one off)

glGenBuffers()
glGenVertexArrays()

render (every frame)

glClear(GL_COLOR_BUFFER_BIT)
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
glUseProgram(...)
glUniformMatrix4fv(...)
glUniform1f(...)
glActiveTexture(...)
glBindTexture(...)
...
glBindVertexArray(...)
glBindBuffer(...)
glDrawElements(...)
[for each mesh]

*edited to clarify that I have tried to group the vertices into less amount of meshes to reduce number of draw calls

**edited to provide more data and streamline questions.

I'm working on a libgdx implementation of mesh terrain and running into some performance issues.

The terrain is represented by a number of mesh tiles, each mesh is made of vertices laid onto a 2D plane.

The implementation of the meshes is done via libgdx Mesh, each of which is cached after its initial generation. I use GL3.0 and therefore the vertices are handled via VertexBufferObjectWithVAO which as I understand it should allow GPU caching.

Performance is sluggish, I have tried to increase the size of the meshes but weirdly the performance gets worse rather than improving.

I think I'm missing something out in the OpenGL pipeline, in my mind the way is should work is meshes are sent to GPU once, the larger the mesh the better as less draw calls but this doesn't align with the results I'm getting.

To give you an idea of the size of the meshes the initial set up was: 7,200 vertices * 625 meshes in a single draw call. FPS were worse when trying 100 meshes with ~45,000 vertices.

I'm working on a libgdx implementation of mesh terrain and running into some performance issues.

The terrain is represented by a number of mesh tiles, each mesh is made of vertices laid onto a 2D plane.

The implementation of the meshes is done via libgdx Mesh, each of which is cached after its initial generation. I use GL3.0 and therefore the vertices are handled via VertexBufferObjectWithVAO which as I understand it should allow GPU caching.

Performance is sluggish, I have tried to increase the number of vertices in each mesh (while keeping the same overall amount of vertices) but weirdly the performance gets worse rather than improving.

I think I'm missing something out in the OpenGL pipeline, in my mind the way is should work is meshes are sent to GPU once, the larger the mesh the better as less draw calls but this doesn't align with the results I'm getting.

To give you an idea of the size of the meshes the initial set up was: 7,200 vertices * 625 meshes in a single draw call. FPS were worse when trying 100 meshes with ~45,000 vertices.

*edited to clarify that I have tried to group the vertices into less amount of meshes to reduce number of drawcalls

I'm working on a libgdx implementation of mesh terrain and running into some performance issues.

The terrain is represented by a number of mesh tiles, each mesh is made of vertices laid onto a 2D plane.

The implementation of the meshes is done via libgdx Mesh, each of which is cached after its initial generation. I use GL3.0 and therefore the vertices are handled via VertexBufferObjectWithVAO which as I understand it should allow GPU caching.

Performance is sluggish, I have tried to increase the size of the meshes but weirdly the performance gets worse rather than improving.

I think I'm missing something out in the OpenGL pipeline, in my mind the way is should work is meshes are sent to GPU once, the larger the mesh the better as less draw calls but this doesn't align with the results I'm getting.

To give you an idea of the size of the meshes the initial set up was: 7,200 vertices * 625 meshes in a ingle draw call. FPS were worse when trying 100 meshes with ~45,000 vertices.

Thanks

I'm working on a libgdx implementation of mesh terrain and running into some performance issues.

The terrain is represented by a number of mesh tiles, each mesh is made of vertices laid onto a 2D plane.

The implementation of the meshes is done via libgdx Mesh, each of which is cached after its initial generation. I use GL3.0 and therefore the vertices are handled via VertexBufferObjectWithVAO which as I understand it should allow GPU caching.

Performance is sluggish, I have tried to increase the size of the meshes but weirdly the performance gets worse rather than improving.

I think I'm missing something out in the OpenGL pipeline, in my mind the way is should work is meshes are sent to GPU once, the larger the mesh the better as less draw calls but this doesn't align with the results I'm getting.

To give you an idea of the size of the meshes the initial set up was: 7,200 vertices * 625 meshes in a single draw call. FPS were worse when trying 100 meshes with ~45,000 vertices.