Subdivided Icosahedron Hex/Pent grid efficient rendering?

Question

How to performantly display a hex/pent grid on a subdivided icosahedron?

I have a subdivided icosahedron planet used as the "board" for a strategy game. It usually has anywhere between a few thousand and a hundred thousand tiles depending on the size the user inputs to the map generator.

Basically, I cannot brute force this and do a simple bounds and depth check, because of the sheer numbers of tiles.

I am storing the grid in a 2D array for simplicity. I understand that, on a 2D map, you simply do something like the following to draw a hex map:

for(int x = cameraX; x < viewportWidth; x++)
{
    for(int y = cameraY; y < viewportHeight; y++)
    {
        if(x % 2 == 0) //For the 2D array to work properly we have to offset every other row by +1 world coordinate (assuming each tile is 1*1 world coordinates)
           grid[x][y].render(x+tile_width, y);
        else
            grid[x][y].render(x, y);
    }
}

And that to draw a wrap-around world you would check the absolute distance from the camera's position.

Eg:

//This sets up the variable that tells the game what hex tiles to draw.
if(camera.x - viewportWidth < 0)
{
    camera_rX = camera.x - viewportWidth;
    cameraX = grid.length + camera_rX; //We will add this to the cameraX value because the result should be a negative value if the prerequisite if statement is met. The "cameraX" variable is used for viewing calculations, while the "camera.x" variable is used for camera positioning. Err... I think this makes sense.
}

I wrote a previous answer about rendering a dynamic tile map on a single quad, using a shader to.draw the tile subdivisions and select tiles to draw using an index texture. A similar technique could be applied on a sphere, with suitable UV mapping and tile rounding math in the shader. Is that something that would interest you, or do your tiles each require 3D geometry rather than just surface colouration/shallow displacement? — DMGregory, Oct 13 '17 at 13:03
I'm open to alternative solutions, though this question is mainly looking for the math behind performantly rendering only the sphere tiles that need rendered based on camera zoom. — Jax, Oct 14 '17 at 00:45

score 2 · Answer 1 · answered Oct 13 '17 at 02:57

First question that comes to mind: does the hex-planet change a lot during gameplay? If the planet is mostly static, and just the inhabitants on it move around a lot, I would definitely not render the tiles separately.

I've made a hex-planet game myself. And in this game the planet is just two draw calls, one to draw its faces, and one to draw the edges.

This way I don't have to iterate over the tiles to render them.

For the stuff on top (trees, rocks, etc) I use instanced-rendering, so that in one drawcall, all pine-trees e.g. are rendered in a single go. I am not sure what you are using for rendering (question tags don't mention a render system), but if it is OpenGL or OpenGLES3 then look into glVertexAttribDivisor() and glDrawArraysInstanced().

It gets trickier if the tiles change a lot during gameplay. Let's say you frequently change the colour of the tiles in the world. Then I would still have a single VBO to represent the entire planet, and just update that VBO every frame with the correct colours before rendering, as described above.

I'm using libGdx to abstract a lot of the low-level graphics API's and save on development time (I probably should have named the engine, but I thought this was more of a mathematical problem). I already considered drawing the planet in a single draw call, but unfortunately there is a lot of change going on on the planet surface (eg, tile color change with ownership). I have considered drawing colored, faded meshes over the top of the rendered planet, and sply disallowing the user to zoom closer, but I still have to find which tiles are visible to do that. — Jax, Oct 13 '17 at 04:07

Subdivided Icosahedron Hex/Pent grid efficient rendering?

1 Answers1