Procedural mesh's normals are reversed (Solved)

[system]

So I am trying to generate a procedural mesh, but I am encountering problems with the normals.

![Where’s the cream filling!?][1]

I find this very strange, since the mesh itself seems to be of the right shape. Here is my attempt to explain the code, if anyone ends up wanting to help me:

1. Based on a variable called “mapsize”, I populate an array, blobVerts, with the position of each vertex. If mapsize is set to 10, then the result is a 10x10 units mesh. (Note that mapverts is just mapsize + 1, because there’s one more vertex per row than there are squares)
2. On alternating rows, the x-value is shifted over by 0.5 units. This gets the zigzag pattern
3. The triangles are generated in batches of two, with six indices handled in each batch. The “CurrentRow” switch statement is used to alternate the pattern of the batch. Within each batch, the six indices are calculated based on a pivotal vertex. this central vertex is held by the “g” variable (Which is actually being reused from the earlier Vertex section… ugh).

That’s about all I can think of to explain it for now. If anyone has questions, such as “Jesus dude, where did you learn to program? The Internet!?”, please ask. So here’s the code:

        blobVerts = new BlobVertex[mapverts * mapverts];
        blobVertsArray = new Vector3[mapverts * mapverts];
        blobUV = new Vector2[mapverts * mapverts];
        blobTriangles = new int[(mapsize * mapsize * 6)];

        //Populate the blobVerts class array
        for (int i = 0; i < blobVerts.Length; i++)
        {
            blobVerts *= new BlobVertex();*

}

//VERTICES
int g = 0;
int row = 3;
//Set the vertices to fill the map grid
for (int i = 0; i < mapverts; i++)
{

for (int h = 0; h < mapverts; h++)
{

blobVerts[g].position = new Vector3(h - ((row % 2) * .5f), 0, i);

g = g + 1;
}
row++;
}

//Transfers positions from blobVerts[].position to blobVertsArray
UpdateBlobVertsArray();
//END VERTICES

//UV
Debug.Log("blobUV.Length: " + blobUV.Length);
// Set the UV verts
for (int i = 0; i < blobUV.Length; i++)
{
//Debug.Log("i = " i);
blobUV*.x = 0;*
blobUV*.y = 0;*
}
//END UV

//TRIANGLES

// Set the triangles
// Interger “h” corresponds with the batch of triangles (form a square)
// Interger “g” is reused as a holder for the real starting vertex in each batch
g = 0;
row = 2;

for (int h = 0; h < (mapsize * mapsize); h++)
{
//this is my attempt at skipping the last vertex in each row, since it does not have a square
if ((g + 1) >= mapverts && (g + 1) % mapverts == 0)
g++;

//Cycle through the six vertices for a pair of triangles (parallelogram)
for (int i = 0; i < 6; i++)
{
int triIndex = (h * 6) + i;

switch((CurrentRow(g) + 2) % 2)
{
case 0:
switch (i)
{
case 5:
blobTriangles[triIndex] = g + mapsize + 2;
break;
case 4:
blobTriangles[triIndex] = g + mapsize + 1;
break;
case 3:
blobTriangles[triIndex] = g + 1;
break;
case 2:
blobTriangles[triIndex] = g + mapsize + 1;
break;
case 1:
blobTriangles[triIndex] = g + 1;
break;
case 0:
blobTriangles[triIndex] = g;
break;
}
break;

case 1:
switch (i)
{

case 5:
blobTriangles[triIndex] = g + mapsize + 2;
break;
case 4:
blobTriangles[triIndex] = g + 1;
break;
case 3:
blobTriangles[triIndex] = g;
break;
case 2:
blobTriangles[triIndex] = g + mapsize + 2;
break;
case 1:
blobTriangles[triIndex] = g + mapsize + 1;
break;
case 0:
blobTriangles[triIndex] = g;
break;
}
break;
}
}

g++;
row++;

}
//END TRIANGLES
----------
EDIT: Here’s a few more images to demonstrate what is happening.
With a texture (viewed from the bottom)
![A a-a-a a-al co hol, baby][2]
[1]: http://s7.postimage.org/9wckg52h7/Meshed_Up.png
[2]: http://s7.postimage.org/7eamkjp3f/Meshed_Up2.png

[aldonaletto]

It seems your problem is already solved, but just to let you know about this triangle winding thing, here goes a drawing:

The winding order informs which’s the front side: if the vertices are in clockwise order, you’re looking to the front face; if in counter-clockwise order, it’s the back face and you will see nothing (unless the shader is double sided). In the drawing above, triangle 1 must be composed by vertices [1,2,4] (or [2,4,1] or [4,1,2]), and triangle 2 by vertices [2,3,4] (or [3,4,2] or [4,2,3]). Since vertices 2 and 4 in this drawing are common to both triangles, usually we calculate their indices and store in two variables, then assign the six vertices based on these variables:

    int v2 = ...; // calculate index of vertex 2
    int v4 = ...; // calculate index of vertex 4
    verts[i++] = v2-1;
    verts[i++] = v2;
    verts[i++] = v4;
    verts[i++] = v2;
    verts[i++] = v2+1;
    verts[i++] = v4;

NOTE: The pseudo code above is based on the vertices 1…4 showed in the drawing above; it must be changed if the vertices are stored in a different order.

[system]

I narrowed it down to two things. First was the blob.Optimize() function. When I comment it out of the code, I get a correct-looking mesh:

However, this only got me halfway there. When I added a texture, things got interesting again:

So I decided to start messing around with the triangle batches. By switching the order in which the vertices where added to the blobTriangle array, I finally got it to work:

Thanks for the help, Christian. I’m still not sure exactly why this worked. There seems to be something about the order in which the vertices are assigned to triangles that affects their (and the surrounding triangles’) face normals. Really weird.

EDIT: blobOptimize() was not part of the cause. It was just covering up the problem with the triangles. Also, Christian pointed out that when assigning vertices to the triangles, the order of assignment (clockwise vs counter-clockwise) affects the orientation of the mesh. That was my problem.