Figured I'd ask for help on this before I drive myself insane trying to figure it out. I'm looking to create Minecraft like terrain using the 3D GridMap, as already done by many developers as far as simple blocks go.
But I want to do it with a twist: I wish to support diagonal surfaces for slopes and corners. This adds a lot of complexity... particularly if you want to support both cubes and slopes on a per voxel basis; I was initially thinking of designing the edge / corner meshes to always be diagonal but felt that would be boring and I'd rather allow all possible shapes. One way of doing it would be a quantity float per voxel: Empty when 0, a full cube when 1, a slope based on neighbors when between 0 and 1... this though is unpredictable and could make gameplay too weird while the shapes needed are too complex.
So I thought of an even better idea, which would provide full player control over surface sculpting to freely make slopes or diagonal walls: Instead of adding or removing the blocks themselves, you could place or dig their vertices! Each block is still located at a fixed position, for example "0 0 0" for a 1m voxel at the world center... to determine its shape however, you don't scan for a value at this location but instead check it at the 8 locations: "-0.5 -0.5 -0.5" "-0.5 -0.5 0.5" "-0.5 0.5 -0.5" "-0.5 0.5 0.5" "0.5 -0.5 -0.5" "0.5 -0.5 0.5" "0.5 0.5 -0.5" "0.5 0.5 0.5" and decide the shape based on which are full.
The issue I'm running into is that the amount of shapes needed is gigantic: The total possible combinations of cubes with one or more missing vertices which still create a shape is huge, particularly when we take into account all possible rotations too. I did a quick visualization in Blender and came up with at least 8 distinct forms which might be even more:
I'm starting to feel it would be foolish to create and export each individual shape as a mesh and use it in the gridmap... especially since I'd need yet another magnitude of shapes to also exclude backfaces where two neighboring voxels match, I care for performance and want no hidden triangles. I'm wondering if instead I should use an ArrayMesh and skin those voxels via code. But this I have no idea how to program... unlike scanning neighbors and picking a predefined shape which is easy, I can't begin to visualize the code for manually skinning the closest outer surfaces between a set of points.
How do you suggest I approach this? We might be circling back to a smooth voxel algorithm like marching cubes, though my idea is limited at 0 to 45 surfaces connecting only direct neighboring points, it's a different and far simpler method which is also easier on gameplay since the player predictably knows what they're building / digging. Before anyone suggests Zylann's terrain, I can't use it as his implementation requires a custom build of Godot as the C++ version can't be compiled as a plugin nor is there a GDScript implementation for Godot 4.0 dev. Let me know if there are existing examples of something like this, or if you can provide ideas on the skinning or tile mesh selection code for such a system.
