We are currently hitting performance issues, when generating this grid map overlay for very big maps where rows are 100 000 <= rows <= 1 000 000 and cols as well. We generate one big bufferGeometry with edges to get this overlay over the map. For the biggest maps it takes 20-30 sec to calculate sometimes crashing the page, and the performance drops to 15-25fps. I know this can be done better with some shader logic moving the expensive computations on the gpu, but i am not sure how. If anyone has any examples that would be great. I can provide the code for generation if someone is interested.
A million * million * 2 triangles?
So.. 2000000000000 triangles? That’s about 1999999000000 too many. 
An approach I like, is to store the heightmap in a float datatexture or rendertarget.. say 1024 * 1024 rgba texels.. put height in the red channel, then material type, and custom data in g and b, and then use a single instanced quad to render it whatever region is close to the camera, say a 256x256 window around the camea.. in the vertex shader, computing the uv from gl_InstanceId, sampling from the heightmap per instance. As new data comes in it either goes into new rendertargets, or gets copied over when the viewing origin changes.
Another approach is to use something like a CLIP map.. where you have a flat grid of high resolution quads close to the camera, and lower tessellation quads in the distance.. and then doing similar heightmap/material reads in the vertex shader.
Yet another is to store the world in smaller tile chunks, and maintain a cache of like NxN of those tiles where N >=3 and < 10.
All these schemes don’t rely on building mesh data and sending it to the gpu, but rather sending the height/material data in directly as a texture.
Terrain rendering is a huuuge topic, and it’s hard to say what is an optimal approach without knowing a lot more about what your specific needs are.
1 Like