How to load stacking chunks on the fly?

Question

I'm currently working on an infinite world, mostly inspired by minecraft.
A Chunk consists of 16x16x16 blocks. A block(cube) is 1x1x1.

This runs very smoothly with a ViewRange of 12 Chunks (12x16) on my computer. Fine.
When I change the Chunk height to 256 this becomes - obviously - incredible laggy.

So what I basically want to do is stacking chunks. That means my world could be [∞,16,∞] Chunks large.

The question is now how to generate chunks on the fly?
At the moment I generate not existing chunks circular around my position (near to far). Since I don't stack chunks yet, this is not very complex.

As important side note here: I also want to have biomes, with different min/max height. So in Biome Flatlands the highest layer with blocks would be 8 (8x16) - in Biome Mountains the highest layer with blocks would be 14 (14x16). Just as example.

What I could do would be loading 1 Chunk above and below me for example.
But here the problem would be, that transitions between different bioms could be larger than one chunk on y.

My current chunk loading in action

For the completeness here my current chunk loading "algorithm"

private IEnumerator UpdateChunks(){
    for (int i = 1; i < VIEW_RANGE; i += ChunkWidth) {
        float vr = i;
        for (float x = transform.position.x - vr; x < transform.position.x + vr; x += ChunkWidth) {
            for (float z = transform.position.z - vr; z < transform.position.z + vr; z += ChunkWidth) {

                _pos.Set(x, 0, z); // no y, yet
                _pos.x = Mathf.Floor(_pos.x/ChunkWidth)*ChunkWidth;
                _pos.z = Mathf.Floor(_pos.z/ChunkWidth)*ChunkWidth;

                Chunk chunk = Chunk.FindChunk(_pos);

                // If Chunk is already created, continue
                if (chunk != null)
                    continue;

                // Create a new Chunk..
                chunk = (Chunk) Instantiate(ChunkFab, _pos, Quaternion.identity);
            }
        }
        // Skip to next frame
        yield return 0;
    }
}

Answer 1

What you need to consider loading/creating one chunk above and below the surface in any given stack when the player is on the surface, so your generation algorithm needs to worry about stacks at the top level rather than chunks... when the player is below ground one above and below the current chunk level is fine. To clarify, a stack is a vertical column of chunks from bedrock to stratosphere :)

Another way to look at it would be to say if the surface is below the player's current chunk level -- generate the surface and one below, otherwise generate the current level and one above and below.

So lets say your world will be 256 chunks high (* 16 = 4096 voxel blocks), and at any time if a stack is within view range, you will have from 1 to 3 chunks in that stack actually loaded and rendering.

Biomes introduce an additional problem of blending heights at the edges, but you can handles that in the biome specific code that will be called to generate the surface and subsurface features. If you are using perlin/simplex noise to generate heights, if a chunk borders a chunk that is a different biome, you can get the noise values that both biome types would generate, then average them.

Answer 2

What you can do, is, making a chunk 256 high in y-direction and divide it into 16 sections, each being 16 blocks high. You then generate the data for the chunk, and build the geometry inside the sections.

One advantage would be, that you have access to the data of a complete chunk, which makes it easier to access the data above and below a section.

This also has the advantage of being able to easily cull away lots of geometry that does not lie inside the viewing frustum. There will also be many sections which do not have any geometry at all.

If you do not use it already, loading the chunks in another thread may also give you better frame rates, while generating the data for each chunk.

Answer 3

I don't believe you can do this with simply loading certain layers because of the problem of transitions.

My inclination would be to store some metadata with each chunk:

1) Is the block entirely air. If so there's no need to render it.

2) For each face of the block is it opaque. An opaque face means you do not need to consider the next chunk. (Note, though, that depending on where the chunk is there could be as many as three faces involved--a chunk must be rendered if any of the three are not opaque. I suspect this is best pre-calculated--render so long either b1 is visible and has a non-opaque face f1 or b2 is visible has a non-opaque face f2 or b3 is visible has a non-opaque face f3.)

There are unfortunately over 7000 chunks within your 12 chunk sight range. However, I would expect few locations to have more than three vertical chunks that actually need to be rendered using this approach which cuts the chunk count to probably no more than 1500.

I would apply the same sort of logic within a chunk--when you load a chunk calculate what junctions are transparent and what junctions are opaque touching opaque--you only need to actually render faces where someone can see them. (Note that in Minecraft you have three types of block--transparent, opaque and vision-altering--glass, doors, fences etc. You can only skip transparent-transparent and opaque-opaque.)