Edit: This article used to be titled ‘cubesets’. However, as ‘bricks’ are a better 3D equivalent of ’tiles’ than ‘cubes’, I’ve renamed it to ‘bricksets’.
If we want to use the sparse voxel octree renderer to make games, we have to find a more efficient way to store game worlds, because having to download and install a 5TB large world file just isn’t feasible. Therefore we’re going to look at how this problem was already solved 30 years ago. We’re going to look at tilesets.
Back in the old days, memory was scarce. To get around this, some games used tilesets to create big worlds. First you create a set of tiles, and then you can create your world by painting with these tiles in a grid. The Tiles can be ‘intentional’, for example: this grid cell is water, that grid cell is dirt. This looks like:
Another option is to use a ‘seamless’ tileset, where additional tiles have been created that represent the transition from one type to another. This helps to hide the grid, as it is no longer visible where one tile ends and another begins:
When creating a seamless tileset, eventually the question “what tiles do I have to make?” will pop-up. The answer is based on the marching squares algorithm. For example, we want to create grass and dirt tiles. Each tile has 4 corners, and each corner can be either grass or dirt. Hence, we would need 2x2x2x2 = 16 different tiles. There is a nice explanation of the marching squares algorithm and how to combine it at: http://blog.project-retrograde.com/2013/05/marching-squares/.
The above can quite easily be translated to 3D. Using intentional tileset results in a minecraft like game. For example, the following screen shot is from minetest (my favorite open-source minecraft clone):
I don’t have any images that use the 3D equivalent of seamless tiles, because such games don’t exist yet (though the Euclideon island demo would almost qualify).
Again, the first step is to create a tileset. How many tiles do we need? Well, a cube has 8 corners, so if we are only having dirt & air tiles, this would result in 28 = 256 tiles. That is quite a lot, especially because creating 3D tiles is also a lot harder than drawing 2D tiles. So, instead of drawing these by hand, I want to generate them procedurally. I’ve not yet figured out how I want to do that. Obviously, I also want a third tile type, for example stone. If we combine three tile types in a single tile, we would end up with 38=6561 different possible tiles. Obviously, most of these will rarely be used. So here it would be nice to have a method that can create such tiles on demand.
The name ’tilesets’ isn’t really accurate, because in 3D, they’re not tiles, they’re bricks, hence we might want to call them bricksets.