Question by eliasbylarsen · Jun 19, 2019 at 04:08 PM · mesh culling procedural mesh voxel procedural generation

Manual culling of voxel faces?

I am making a game not unlike Minecraft in that it uses a voxel-based world system. However, my game supports the use external mesh files for each voxel imported by the user/player. These meshes are imported at startup and held by a static class to be retrieved as necessary.

The voxels are already gathered into larger sections (similar to "chunks" in Minecraft, I suppose) to avoid the excessive CPU overhead that comes with frustum culling too many GameObjects. Each one of these sections will obviously have to generate its own mesh, with each voxel having its own submesh (although texture atlasing is enabled and there is only one material by default, I want to let the user be able apply custom materials for each voxel type).

I am unsure of how I should be storing the model data for each Voxel type, because the sectional mesh should not need to include faces of the voxel that are touching a neighboring voxel (simple bool for each face specified in a config file for each external model). I see there being two options:

Generate and store a mesh for each of the 2^6=64 face permutations, depending on which of the 6 faces are/aren't touching a neighboring voxel. Although the models are expected to be fairly simple, this seems like a bunch of unnecessary memory overhead to me
Generate and store a mesh for each face, and use Mesh.CombineMeshes when a specific permutation is requested by the sectional mesh GameObject. This seems like a ton of CPU overhead, as a new mesh effectively has to be generated each time the voxel's mesh is requested
Leave it be and overdraw the hidden faces. I really don't want to do this, because I am expecting that some of the user-imported models will have faces that ask for this type of culling when they will actually still be visible next to a neighboring voxel (effectively creating "hidden compartments" within the model; it's hard to explain).

Am I missing something? Perhaps I can alter the rendering pipeline (I'm using the default pipeline at the moment but thinking of switching to LWRP)? There has to be a better way to do this than the one's I'm envisioning.

0 Show 1

Namey5 · Jun 23, 2019 at 02:36 PM 0

The first approach makes the most sense to me, especially if you are working with cubes. I can't imagine there would be significant memory overhead for the meshes alone. In theory you would only require aprox. twelve meshes (for each of the face variations) which can then be rotated to match the context of the voxel, rather than creating a mesh for every single outcome.