@Muffincoder - do you add the faces to the mesh from furthest to nearest (the camera) or do you always add them in the same order? Sorting them by distance from the camera may make a difference.
Also, are your triangle vertices defined in an anti clockwise direction?
@Ignatz The faces are added as the blocks are arranged in the array hence it would be hard to control which faces to draw first. AND the mesh is built only once, and it’s very large, so rebuilding it every draw would not be an option here from a performance aspect.
And yes one face is made up of two CCW triangles
And as I have studied the look of the blocks beign drawn at negative x values, I’ve come to the conclusion that it has to be something about the draworder(which I know nothing about).
So is it possible to control the draworder in a static mesh? If so how would I do that?
@Muffincoder - OpenGL draws the triangles in the order you provide them, and (when they overlap) the optimum result comes from drawing them from furthest to nearest the camera, because OpenGL keeps track of the z position of each screen pixel as it processes each triangle. The worst case is when you have images with transparent pixels and draw something behind them, because OpenGL ignores the transparency and won’t draw anything behind!
One other thing to watch for is not to draw faces too close to each other (relative to camera position), eg within 0.5 pixels, because you are likely to get flickering as OpenGL gets confused about which one to show.
As to controlling the draw order, you ultimately need to end up with a table of vertices in far-to-near distance order each time you draw. The question is how to do that without killing FPS.
You don’t want to have to rebuild the vertex (and normal and texture) tables at each draw.
One possible option, if the mesh is only built once, is to build (say) 8 separate copies of it to start with, with vertices for each one sorted far-to-near for camera positions 45 degrees apart, all the way round the mesh. Then you choose the closest one to whatever camera position you are in. That would cost you in memory and setup time, but would not cost you anything in drawing speed.
@Ignatz That could work, I think 4 meshes would suffice in my case though.
But isn’t there any way I could somehow reverse draw a mesh in the shader? This could reduce the meshcount to two, or possibly one mesh for each chunk.
@Ignatz not sure about efficiency of drawing furthest to nearest… drawing furthest to nearest resolves the transparency issue, because furthest is drawn first, then drawing something “in front” which is transparent will give you working transparency.
For efficiency I would expect “theoretically” that the opposite is true, because if you draw the nearest one first, then when it gets to drawing the one behind it’ll realise it’s occluded and not draw it. This would of course wreck any chance at transparency working.
I agree with spacemonkey. Unless you have transparency issues, draw from front to back.
I’ll just have to keep my opaque blocks in one mesh and the transparent ones in a different mesh.
The problem with having 4meshes for one chunk is that atm my generation time is about 3-4sec for one chunk, and the drawdistance will have to be at least 5-8 chunks, which means about 25-64 chunks, and that means about 1-2minutes of generation delay. Unacceptable…
Preferably 20-30sec for generation on startup, and a minimum of 5 chunk drawdistance means maximum 1sec for each chunk…
So, this means I’ll have to try to reduce the overhead for generating the mesh, by alot.
Now I’m using a 3 layer array for keeping my blocks position in the chunk easily accessible, But is it faster to use a one layer array and just have an index for each block?
Edit: Answering myself here. 
After testing I found no real difference in generation time if I used a 3 layer or 1 layer array for the block array. So I’ll keep the 3 layer one for convenience. (If you have evidence showing different results in this matter then I’d like to see it, this is just how I concluded this)