Yet another minecraft clone thread? No.
Go do something easier that 65536 people already have done like pong/tetris: No, I already made some 2d games, I want something new and challenging.
Use Volumes of fun? No.
Have you heard about minetest by celeron55? Yes, and I studied his code.
Do a forum search for "minecraft". Done, I've read everything.
Summary:
I'm working on an engine that can be summarized as a minecraft-like, BUT:
-There are not only squares shapes
-There are much more meshes displayed (your character is not 1x2x1 but rather 1x4x2 and might be 2x7x3 depending on the performance/results)
-It is not based on digging/building, but that's a feature implemented.
Problem:
Displaying blocks as individual meshes create a shitton of queries which has a huge impact on the FPS.
Potential solutions:
-Mesh combining / batching
-Back face culling
-Only draw visible triangles
My solutions:
I am considering mesh combining using this method:
-A "cube" is composed of 6 faces, each composed of 2 triangles
-A "rectangular triangle" is composed of 5 faces, 2 composed of 1 triangle and 3 composed of 2 triangles.

When both are placed close to eachother, an alogithm will check which "faces" are in contact and remove useless S3DVertex, to create a bigger mesh, this will reduce the number of calls.
Then, if there are squares close to eachother, instead of having 4 rectangular triangles, it'll combine it in bigger rectangular triangles. This will reduce the number of triangles to draw.

I want to display 1024x2048 (considering a 180° view angle) terrain tiles (each tile contains a "shape") so that's (for a flat surface) 4.194.304 visible triangles.
By regrouping tiles in 16x16 blocks, that will reduce the numbers to 64x128 blocks: 16.384 visible triangles.
By regrouping them in 32x32 blocks, that will reduce numbers to 32x64 blocks: 2.048 visible triangles.
And so on.
When it comes to back face culling, from what I've seen, it's automatically done, but still, what would be the point of displaying "invisible" triangles, that's why I thought of testing if there is an "obstacle" between the camera and the target vertex/triangle (of course after cleaning them with both previous functions). For this part, I don't know how to do it, I lack knowledge.
Questions:
Do you guys think I am "doing it right" or is there something easier, more elegant, less time consuming or whatever better than my method?