Strange chunk size

[Pandawan]

Hey, I'm trying to use the world generator using noa.world.on('worldDataNeeded', () => {}) but for some reason, the chunk's data object has a shape that is different than the chunkSize. In my case, I set chunkSize: 16, but the data.shape ends up being [18,18,18].

Even stranger, when I try to set a block on the corner of that chunk data.set(0, 0, 0, game.blocks.stone.id);, the block doesn't appear, I need to set it on (1,1,1) for it to work. Same thing with setting it at (data.shape[0] - 1, data.shape[1] - 1, data.shape[2] - 1), which I expected to be the opposite corner, but didn't work, that corner turned out to be at data.shape[i] - 2 for all of them.

I'm unsure if this is intended and, if so, what the purpose of having a 1 block padding all around the chunk if they're not going to be rendered anyways.

Thanks!

[Pandawan]

It seems this was worked on 3 years ago but was never really finished...

[fenomas]

Hi! Sorry - this is intended but I don't have any good docs explaining it. Here's the basic story.

The implementation I've settled on adds 1-voxel of padding to all chunks. This is done so that the edge blocks of each chunk can be built correctly, since the meshing and ambient occlusion for a given voxel depends on its neighbors. The alternative would to omit the padding but rebuild each chunk when its neighbors first get created - I experimented with that as you saw, but wound up sticking with the current behavior for now.

So, when you set chunk size to 16, and noa wants the chunk for (0,0,0), it sends out an event with an (18, 18, 18) size array for location [-1, -1, -1]. So the correct way to handle it would look like:

    noa.world.on('worldDataNeeded', function (id, array, x, y, z) {

        var size = array.shape[0]
        for (var i = 0; i < size; i++) {
            for (var j = 0; j < size; j++) {
                for (var k = 0; k < size; k++) {
                    var worldx = x + i
                    var worldy = y + j
                    var worldz = z + k
                    var block = decideBlockID(worldx, worldy, worldz)
                    array.set(i, j, k, block)
                }
            }
        }

    }

Hope this helps, let me know if it works!

[Pandawan]

So should you or should you not write to the padding? In the example you gave, you are simply acting as if the chunk was 18x18x18; doesn't that mean you are writing twice but one of them is useless? (I know that you are using worldX, worldY, worldZ to allow terrain generation to know where it is, but it still seems pointless to write if you don't need it).

Right now, I'm simply ignoring the padding and not writing anything there, is that fine/recommended?
Will that mess up with block culling?

// Note: I'm ignoring the x,y,z passed by worldDataNeeded because I don't need them
noa.world.on('worldDataNeeded', function (id, data) {
    for(let x = 1; x < data.shape[0] - 1; x++) {
        for(let y = 1; y < data.shape[1] - 1; y++) {
            for(let z = 1; z < data.shape[2] - 1; z++) {
                if (y === 1) {
                  data.set(x, y, z, game.blocks.stone.id);
                }
            }
        }
    }
}

EDIT: Is this issue related? Should I add blocks in the padding area?

[fenomas]

Yes, you should fill in all the blocks in the data array, including the padding.

The engine uses the padding blocks to figure out how to build the edges of each chunk - whether they need meshes on the boundary and whether the edge blocks need AO, so if you leave them out there should be issues at chunk borders.

For reference here's what the hello world demo looks like if you omit the padding blocks - the light-colored bands on the ground are incorrect AO, and the terrain gaps are the same issue you saw in your video.

[Pandawan]

Okay, that explains it. Thank you very much!