I was thinking of running greedy meshing or any other meshing algorithm to combine blocks over time to reduce part count.
I tried making it so my blocks are stored in voxel representation. So a two by two block might occupy four voxels in a lua dictionary. I don’t like the idea of this as I want to used the least memory as possible. Seems pretty inefficient when chunks are broken of from the main voxel grid as you’d have to reconstruct that voxel grid. Is representing the game world in voxels the only way to make this work?
All the solutions I tried for meshing different sized voxels barely combined anything. My formula was combing blocks which share the same size on one axis and were adjacent. This didn’t work very well as the cases of these configurations happening are slim.
It doesn’t seem to me like it would even save that many parts. There are only some special cases where you’d be able to optimize beyond what you get from the straightforward splitting.
If your holes are aligned to a grid, it’s more likely that you can save parts. But you didn’t mention that.
Anyways, have you considered using unions to literally create holes in parts? That might be the easiest and fastest solution.
The parts are aligned to local grids. For example, all the parts in a building will be aligned in a local grid. When part of the building falls of a new grid is created for the piece falling of. So I think I should be able to save a lot of parts with greedy meshing.
Also unions don’t work was these parts are the parts created from splitting are welded to surrounding parts.
@0Shank
What you could do is use a regular greedy meshing algorithm, but only greedymesh that group of voxels if they are the same size. When you greedymesh a group of voxels, you will know that you should only greedy mesh that group of voxels if they are all the same material, and are all not air voxels. But in this case, make sure they are all not air, make sure they are all the same material, and make sure they are all the same size.
Those 2 parts can’t be greedy meshed because more 2 axises are different (If we are speaking about size here)
Also, you will run into a case where the parts are the same size along all axises, except 1 (Like in the first screenshot), but they still can’t be greedymeshed (for obvious reasons) the reason why they can’t be greedymeshed is because their size difference is along an axis that you aren’t scanning on… If you are be scanning the voxels from negative X, to positive X, and their size difference is along the Y axis, then this will not be greedymeshable like in the next screenshot (You will understand this when you start working on your algorithm).
I use different colors for those 2 parts in the screenshots, not to describe their different materials, but to show that it’s actually 2 parts!
Also, what’s your use case here? Greedy meshing different sized voxels is such a complicated topic, and there are so many different cases you have to check for if you want to greedymesh a group of voxels, and I doubt it would lower part count by much.
The use case is for a destruction system. I have tried the voxel way where I represent different sized blocks as voxels internally and it does reduce the part count by a lot for certain cases (like a player cutting a hole in a wall). (The buildings in my game mostly have similar material and texture). Though it gets really slow with medium sized worlds.
One way I was thinking was running a “voxel” greedy mesh check on a separate thread every 5 seconds for the good configuration and running the same the same size voxel greedy mesher process every 2 seconds.
