0

I am making a voxel game like Minecraft. I am able to load chunks using multithreading with the code...

for (int x = 0; x < WorldSettings.WORLD_WIDTH_IN_CHUNKS; x++)
{
    for (int y = 0; y < WorldSettings.WORLD_LENGTH_IN_CHUNKS; y++)
    {
        chunks[x, y].BulidVertexData();
        Thread.Sleep(50);
    }
}

this works fine, it starts by loading the far away chunk and loads them back and forth like a windshield wiper that gets closer, but I would rather have it load in a circle around the player by loading the near chunks first. Any ideas?

ChengDuum
  • 41
  • 5

2 Answers2

2

One thing you might do is store your chunks in a quadtree representing subdivisions of the x-y plane, or some similar structure, and then do a radius search to locate the ones near the player that are to be loaded. You could do progressively larger radius searches to draw outwards, or you could do a secondary distance sort on the search results with the full draw distance as your radius to get the draw order.

However... it looks like you're loading your entire world at once? I couldn't say for sure without more context, but it seems like that's going to really limit your world size. Minecraft uses chunks in part so that it can load only a tiny part of the world (around the player) into memory at once, but loading them all at once negates that benefit. There are others, to be sure, but you may want to consider rethinking the load-'em-all-at-once method.

If you used a quadtree (or similar) to store your chunk references (don't load them until you need them, and maybe don't even load the whole tree until you need it!), it would give you the searching benefit described above and also allow you to sparsely populate a massive world with only the chunks explored by the player.

mdunsmuir
  • 243
  • 1
  • 5
0

An obvious point of reference would be Minecraft itself.

Minecraft maps are effectively stored as a three dimensional array within the map file.

Chunks from the map are loaded based upon the player's coordinates and movement. Chunks closest to the player are loaded first and then the more distant chunks are loaded. Essentially, it's a spiral out algorithm centered around the player's coordinates.

At some point away from the player, the loader stops loading up chunks for display as they are beyond the resolution of the frame.

You can add additional smarts to limit loading based upon opacity of the blocks and / or based upon which direction the player is viewing. I would check your performance times first before implementing those changes as they could be unnecessary micro-optimizations.