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.

2D 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:

3D Tilesets

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.


5 thoughts on “Bricksets

  1. I don’t know if the following has been tried, or if it’s trivial or unfeasible. I would think about generating first a small class of cubesets, enough to build a map-like world with them. Each cubeset would have a small number of free parameters, like intensity of color, saturation, gradient, things like this. Then I would build the world. Then I would use the renderer to make the world look more realistic. Imagine that this new shiny world is subjected to weather conditions, which in turn will affect the parameters of the cubesets instances. With the renderer can be simulated a cycle of light which could weather the tiles like the sunlight does on real materials (i.e. use the renderer to simulate a cycle of moving light like the sun during a day and integrate somehow the light on the tile and modify the parameters accordingly). Likewise, there may be a very primitive wind, from 2 or 3 directions, simulated also as light with the renderer, then integrated over the tiles, etc. Then there may be humidity, which is a diffusion process from the underground of the world, or proximity to water sources. Then add some small random noise and you are done, or better say after you heat your computer enough you may arrive to a cubeset world which has naturally grown different (but not too different) tiles. Then keep that in the memory for the game.

    • @chorasimilarity
      I dont get how that solves the Problem. Rendering the scene realistically is always the goal. But what has that to do with saving memory?

      Im not shure if one has to think in boxes/tiles. A world can consist of assets. Lets say you have 5-10 trees. You simply use them to make a Forrest. The actual map (where the assets are standing on) could be a simple height map like grid. The ground can be interpolated inbetween vertices.

      • Of course! Now i get it. Sry, It was too early in the morning.
        That way you can get many different cubes. But will they be seamless? One could specify the free parameters for each oft the 8 vertices. That could help to make them seamless. A cube could be some Kind of “gradient”.

  2. I will opensource my raymarcher soon, but you can do some pretty cool stuff with vox,
    els e.g. recursing on its own or on totally different regions, the latter will trash your cache still:(


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s