JoeJ said:
But that's no noticeable difference?

Sadly, yes. There is about 800-4800us+ missing as the call took 1ms to 5ms+ to complete by CPU time. I'm thinking about two options:
1) The 174us are only time needed to draw and render this part of mesh, in this case 800-4800us+ is lost by some GPU side operation that is not visible in RenderDoc (copying VBO data by idexes to some temp buffer?).
2) The time is whats needed to complete whole draw call, there is no copying involved and the time is lost in PyOpenGL's implementation of OpenGL.

Thank you for all the help. I will now try to implement few different solutions, to see, which is best.
Worst case, I'll just abandon “raw” OpenGL and use some engine.

GlummixX said:
Sadly, yes. There is about 800-4800us+ missing as the call took 1ms to 5ms+ to complete by CPU time. I'm thinking about two options: 1) The 174us are only time needed to draw and render this part of mesh, in this case 800-4800us+ is lost by some GPU side operation that is not visible in RenderDoc (copying VBO data by idexes to some temp buffer?).

Oh, then i still missed the CPU variance.

To sum up my updated understanding: GPU rendering time keeps the same, but heavy difference on CPU side.

This could be easy to explain. The driver may be able to figure out only a small range of the beginning from the vertex buffer is used, so it uploads only a small range.
But it may be not smart enough to see that only a section at the end is needed.

Could this be? And if so, the goal seems to minimize the uploads you need per frame. Usually vertex data is only uploaded once, which happens only at level load or when streaming in new open world detail.
GPUs also have the option to do uploads in background, with little effect on actual processing. But iirc OpenGL is meant to handle this mostly automatically.

Just had a chat with friend of mine, and he made a joke that i should just do the slicing of VBO on CPU and then use glDrawArrays. Well i tried it and the performace is somehow better and it doesn't degrade with distance. Sure changing the range of rendered area is causing drop from 1000 to 400 fps but thats not something happening all the time, and still could be improved with use of heightmaps and other tricks.

This is quite unexpected. I'll keep this solution as backup in case the moving grid is extremely bad. (Probably is not going to be)

JoeJ said:
uploads only a small range.

VBO is being set only once in the beginning. So it should be completely uploaded on GPU.

Hi, everyone I did some trials and this is my final solution:

Height, texture, UV, and normals are now stored inside heightmap. I'm using R channel for height, G channel for texture, and UV position with normal are sharing B channel.

Sharing is done through bitwise operations. First two bytes of uint8 are used to determine UV mode, 00 for 00, 01 for 01 etc. remaining 6 bytes are used for pre-calculated normal. Since the light source is going to be static - normals are calculated while loading.

For the selection part. X/Y coordinates and triangle orientation enum are being stored in instancing buffer. One vec3 per tile. Rest of the triangle vertices are generated inside vertex shader. VBO for the instancing of tiles contains only 6 numbers from 0 to 5 which are being used with triangle type to determine vertex position.

NOTE: Current configuration is for 512x512 quads area, first tests and the figure in my first post were for 200x200 area.

I've achieved 1500 FPS when not moving around and about 300 FPS when moving. This gives me plenty of room to add more shapes without the need to worry about performance.

This is the resulting selection-time figure for random movement around:

This is the current result:

And thanks to the Index / Triangle type system, I'm able to interpolate between textures like this: