Voxel terrain doesn’t work if it’s just blank boxes. (Actually that’s a complete lie — there are plenty of examples of beautiful games made using only flat colours and shading.) So how does a lone wolf amateur get terrain that doesn’t look like, to coin a phrase, programmer art? I’ve talked about texturing before but it’s taken a while to settle on an approach and get something more than experiments out of it.

It probably still looks like programmer art, but I take comfort in my delusions.

Terrain Up the Night

The first question is a very mundane one. How many pixels of texture should each terrain tile get?

You need to ask this question so that there aren’t rampantly different resolutions scattered across the world — so that the tiles don’t, say, look hyperdetailed next to blurry wall models. Consistency, consistency, consistency. The common ratio doesn’t really matter, as long as it is common.

Coming out of WC3, the answer is easy enough for me: it’s clearly got to be 64. I’ve not gone straight down to that level, though — I’m still generating 256×256 terrain textures. What gives?

It’s all about balance, really. I want the 64-pixel look of classic terrain tiles but I don’t want quite so much of the repetition, so I simply map my 256-pixel terrain textures over four tiles instead of one. My voxel terrain editor has texture scale and offset settings so I can fine-tune this in future, and it sets the texture coordinations of each vertex based on their position relative to the origin of the terrain, rather than the original of each voxel.

Indeed, to take a leaf out of Rage‘s book, I could almost do megatextures for some of my terrains — a 1024×1024 texture would cover a sixteen tile square, and even that’s on the low end of image sizes for modern games. Could I do 2048, or even 4096 terrain textures? Would that eliminate repetition completely without making Unity (or my texture workflow) melt?

I’ve written about how I intend to do textures before, but I have to rescind some of that entry. Substance Designer didn’t cut the mustard for me, at least not to the tune of more than a hundred quid — I kept drifting back to NeoTextureEdit, which is overall simpler but feels more responsive and easier to manipulate, and easier to get comprehensible results out of. It’s also not designed for a — ho hum — triple-A workflow where every texture is accompanied by fifteen different bump and specular maps.

That’s not to say it’s perfect, and it has languished without update for several years now, but it has one major advantage in that regard: it is open source. I don’t like Java at all these days, and I’m pretty leery of putting the horrors of my own codebases up for public consumption, but I just don’t know enough about procedural textures to start from scratch.

Knowing my own limits in this regard, I’ve taken a little fork and I’ve already installed a couple of custom filters to my own “marginally enhanced” version of NeoTextureEdit. One does nothing at all but helps to organise my texture graphs, the other crops one image onto another. Simple things, but enough to keep me going, and NeoTextureEdit is set up so perfectly that these additions slot seamlessly into the file format, the interface, the graph editor — everything.

Even so, I’ve come to the realisation that I’ll never be adept enough at procedural texture graphs for that to cover all bases. It’s doing me nicely for dirt, rock, concrete and metal so far, but it will never give me grass. What to do?

Why, I think I shall just take photographs. There are a wealth of real textures out there that will fit in well enough as they are, or will do with just a bit of post-processing. (NeoTextureEdit can of course take in bitmaps and feed those into its other procedural elements.) Remember that I’m going for late-90s pseudo-realism — which can as easily be faked by downscaling real photographs as it can be generated with Perlin noise and filter chains.

I’ve been poking around Episcura and CGTextures which seem to provide plenty of what I want, with free tiers that satisfy my extremely light usage patterns and permissive licenses that will let me make what I want (provided I include a license statement, and I was always intending to credit my sources anyway). Photographs of foliage with neutral lighting can be turned into tiles that sit happily alongside procedural rock faces and mudbanks. I can then extend this further into making actual foliage models like trees and bushes, finally letting me break away from the worlds of grey rock I’ve called home for so long.

With that, it would appear, I have a complete level design workflow. Physicl landscape, modular structures, natural textures… Guess it’s time to turn all this junk into an actual game, eh?