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?
1,600 meshes * 3,042 vert (4.8M vertices) -> 131 FPS
625 meshes * 11,250 vert (4.5M vertices) -> 132 FPS
100 meshes * 45,000 vert (4.5M vertices) -> 113 FPS
GTX660 2GB Memory Utilisation during test 70% in all scenarios. Vertex allocation memory impact seems to be negligible compared to textures.
From API TRACE, this is the frame life-cycle in summary
mesh generation (one off)
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.