Smaller-sized blocks about cubyz HOT 3 CLOSED

Some thoughts:

• If you divided the block into 64 (4x4x4), you could use a single 64-bit int as a bitfield to determine if a given chunk is present or not.
• I would encourage pushing the mesh generation into a compute shader, to reduce client-side computation and time required to push the much more detailed meshes to the GPU
• I'd also err on the side of simplicity... for example, cull all faces that aren't visible from outside the entire block space, even if it would otherwise be a full face (ie. hole in the middle)
• Multiple textures could be achieved with an integer per block surface

from cubyz.

I think we're more likely to opt for 1/2 m (in which case blocks are divided by 8), also optimising could be done by making it such that if there is the same block filling a large space, it can be compressed (and in the GPU mesh data too) into a larger cube.

About your 3rd point, it's already what we do with invisible blocks.

from cubyz.

The ²⁄₃ sized blocks have been implemented in ea478e0.
The ability to place/remove multiple blocks at a time isn't necessary as ²⁄₃ sized blocks aren't significantly smaller.

from cubyz.