Marching Cubes Dynamic Mesh breaks above certain size

Questions & Answers
1

I’ve implemented the marching cubes algorithm, successfully.
However, it only works so long as the chunk is smaller than 19 x 19 x 19 in size.
For some reason, at that size, the vertices are not in the correct locations, the mesh is lopsided and broken.

Here’s the correct output at 18^3:
152183-size18cubed.png
The broken output at 19^3:
152184-size19cubed.png
As the size increases, more and more of the vertices on one side are compressed into the other.

This is the code that creates the vertices for the mesh.
I tried replacing the algorithm with just filling the entire mesh with triangles to confirm the mesh volume, and that’s it really is broken and it’s not a mistake with the algorithm, I confirmed that much.
I’m completely lost at this point.
I don’t really need the chunks to be that much larger, but I wish I could solve this bug.
Any help is appreciated.

 private Vector3[] InitSharedVertices() {
        var verts = new List<Vector3>();
        var vertsArr = new Vector3[12 * ((size.x - 1) * (size.y - 1) * (size.z - 1))];

        for (int i = 0; i < size.x - 1; i++) {
            for (int j = 0; j < size.y - 1; j++) {
                for (int k = 0; k < size.z - 1; k++) {
                    // 12 points for each cube.
                    // The center of the current cube in local coordinates.
                    var c = new Vector3(halfCubeSize * (2 * i + 1), halfCubeSize * (2 * j + 1), halfCubeSize * (2 * k + 1));

                    // Note: Do not change this order.
                    // Bottom - back, left, front, right
                    verts.Add(c + new Vector3(0, -halfCubeSize, -halfCubeSize));
                    verts.Add(c + new Vector3(-halfCubeSize, -halfCubeSize, 0));
                    verts.Add(c + new Vector3(0, -halfCubeSize, halfCubeSize));
                    verts.Add(c + new Vector3(halfCubeSize, -halfCubeSize, 0));
                    // Middle - left back, left front, right front, right back
                    verts.Add(c + new Vector3(-halfCubeSize, 0, -halfCubeSize));
                    verts.Add(c + new Vector3(-halfCubeSize, 0, halfCubeSize));
                    verts.Add(c + new Vector3(halfCubeSize, 0, halfCubeSize));
                    verts.Add(c + new Vector3(halfCubeSize, 0, -halfCubeSize));
                    // Top - back, left, front, right
                    verts.Add(c + new Vector3(0, halfCubeSize, -halfCubeSize));
                    verts.Add(c + new Vector3(-halfCubeSize, halfCubeSize, 0));
                    verts.Add(c + new Vector3(0, halfCubeSize, halfCubeSize));
                    verts.Add(c + new Vector3(halfCubeSize, halfCubeSize, 0));
                }
            }
        }

        return verts.ToArray();
    }
3

You probably haven’t set yout indexFormat to 32 bit. By default each mesh only has a 16 bit index buffer so a single mesh only supports up to 65536 vertices (in reality it always has been a bit lower). Unity now supports 32 bit index buffers but you have to set this manually before you assign your vertices / indices. Keep in mind that a 32 bit index buffer requires double the memory for the same amount of triangles / primitives.

Note that the indexFormat limits the number of vertices, not the number of triangles / primitives. Though you rarely have much more indices than vertices.

2

This is a couple weeks old but I think I might have an answer for you. It looks like you are adding every vertex weather it is being used or not. you can only use 65,536 vertices in one mesh. looks like you are adding 12 verts per cube and that is what you would expect but that puts you past 65,536 in one 19X19X19 block. ie 19X19X19X2X6 = 82,308. You still pass 65,536 with your 18X18X18 grid but the errors are either inside the block on on the back of the block. Even if you make chunks of 17X17X17 you may hit some serious performance issues just because of the nature of 3D arrays. Make chunks and see if that helps but 17 is the largest you can go in one mesh but while you are there go for an even 16 (programming joke there).