Assets and tiles

A bit late, this post, but work and personal things have been hectic lately…

Anyway, Rincewind has been working on some content for the Calabeth graveyard in the game:

You can see some ground tiles and some tombs/mausoleums.

For this episode, since we’re dealing with most flat “terrain”, we’ve decided to use a tiled terrain approach… So, he built a 5×5 meters patch of terrain and built some tileable textures (in the example above, 4 kinds).

Of course, if we would use that “as is”, we’d end with pretty blocky terrain, which is very ugly.

So, we had to find a way to make “transitions”. After a lot of discussions (and I do mean a lot), we decided on building a tool that will take two sets of textures (A and B), and some mask textures and create the variations. This is easier said than done, specially if we want to save some texture memory.

For example, let’s imagine you have just 2 textures and the appropriate masks:

There’s 9 masks in that last image, this is just a test image… Now, the tool would take the 2 base textures and the 9 masks and build 9 transition textures from it:

For the record, this textures had to be separated by some margin in the atlas because of the mip-map generation, but this is just to explain the basic idea. Note that each of the squared in the image have the same size as the base images.

Problem with this approach is that we’d be doing 9 textures for only these transitions, times 3 (color map, normal map and power/gloss/emissive/ambient map), so that’s 27 textures. If we have the inverse transition, that’s 54 textures. If each of them has 256×256 (and that’s pretty small for a game where you look at ground a lot), we’d have almost 14 Mb of just terrain textures, with no room for other variations, and this is only for two types of ground textures… On our graveyard, we’re expected to have 4 (grass, two dirt types and stone)… If we have all transitions, that’s about 6 times that (so 84 Mbytes) just for terrain textures, with no kind of variations. Guessing that each atlas is 1024×1024 (and we can only fit 9 textures there, because of the mip-map margins), that’s 36 atlas, which means a lot of individual draw primitives…

Now, another option is to reduce the amount of masks. If the mask image was actually well done, you’d see that 1 and 3 are the same mask, just rotate 90 degrees:

So, if we could rotate the the tile, we’d only need 1, 2 and 5, bringing the numbers above from 84 Mbytes to 27 Mbytes, without loosing any flexibility whatsoever!

Problem with this solution is the tiling… Tiled textures usually are only tileable without considering rotation. So, normal case (dirt texture, 2×2 block of it):

If we rotate pieces:

You can see the seam… Zooming in:

In the color map, you might get away with it, but in the normal map (with specular highlights, etc), this would stand out like a million lights!

So, we’ve got to guarantee that the tile texture is rotationally tileable. We had two choices to do this: either create another tool that would do this (by clever trickery and alpha-blending), or the artist could do it by hand… But, after we formalized the problem, we found out that it was pretty simple getting this on authoring with organic stuff, and by organizing our “man-made” textures (stone paths, etc) in another way, we could bypass the problem altogether on those.

This way we can ease up on the memory requirements (or add more “flavor tiles”), like:

Note that all of this was done by me in the making of this blog post, so no artist was tuning anything… for example, the falloff on this last texture is all wrong, it should be something gradual and yet more abrupt.

We hope that with this rudimentary system will help us create some variety on the settings, and yet keep things manageable from an art and performance point of view…

Hopefully, I’ll have time during the weekend to do the tool and try to make a “terrain” layer to try this out…