Basically, I’ve been working on the “asset conditioning pipeline” – which is to say, the scripts, tools, utilities and general technology which gets my props, characters and bits of scenery all the way from the 3D program I use and into the game, where they can be rendered to the screen. I really wanted to have an automated process for this, so that I could just set up an object or character the way I want it in Poser (the 3D program I use), and then just save that file, and have my tools pipeline do the rest. And by “the rest”, I mean quite a few things. Here’s a brief summary of the steps that happens after I’ve saved a new Poser file somewhere in the asset directory for my game.

1. When I’m done using my machine for the day, I launch the asset conditioning program.
2. This scans through the asset directory, and detects any poser file which is new or have been changed.
3. If there are new/changed files, the conditioning tool generates a poser script file, which, when called, will load and render the files.
4. The conditioner starts Poser, and automatically starts the script (by sending key presses! – it was the only way I could get it working)
5. The script loads up each poser file in order, and renders each object from eight different directions – but also, for each direction, it renders a bunch of different images – I’ll explain way later.
6. When everything’s been rendered (which could take hours, if there’s a lot of new assets) the conditioning pipeline goes through each rendered image, and processes it into a format that can be loaded by the game. This is a bit tricky, as I want the data to both be as small as possible, and as fast as possible to draw.
7. Each image is divided up into 16 by 16 pixel tiles. This leaves us with quite a few empty tiles, and these are just discarded.
8. Next, each 16×16 tile is compressed using a custom RLE compression.
9. All the images for one object is put into the same file – and what’s more, if I have several animations for an object (as with most characters), all images of all animations are put into the same file. This way, I end up with neatly packaged object files that contains everything there is for that object.
10. Finally, I look through all the tiles of an object, looking for duplicate tiles. I then get rid of the duplicates and points them to the one instance of that tile. It is amazing how much redundancy there is, especially when having lots of animations, or objects with flat colour areas.

So what are all those different images I render for each image? Well, here they are, for a simple wooden chest:

From top to bottom, they are:

1. Albedo – this is basically the diffuse, unlit texture of the model. Its “colour” if you will.
2. Depth – used to get pixel perfect depth sorting in the game
3. Normals – the surface normal of each pixel (including displacement map details) for dynamic lighting
4. Occlusion – masks off the pixels that should receive no ambient lights. Gives objects more definition
5. Specular colour – colour to apply to the highlights of the object
6. Specular power – how focused/spread out the highlights should be for each pixel. In this example, it looks similar to specular colour, but for some models it varies significantly
7. Height – this is a bit of a special one, in that it is not used for rendering. Instead, it defines the height of each pixel of the object, but stored on a flat plane. The idea is to use this data to determine where the player can walk (imagine that you could walk behind the chest, but not through it)
8. Not shown here, but there’s also a whole bunch of renders for shadows – I’m rendering shadows from 8 different direction, for each of the objects 8 directions, to be able to have some sort of dynamic shadowing. It won’t be super-smooth, but should be good enough).

Occlusion and shadows are stored as 4 bits (16 levels) per pixel, to save memory. Albedo and specular colour are stored as 8 bits per pixel – serving as indices into a 16-bit palette (which is shared between both albedo and specular, and also for all images of an object). Normals are stored as two 8 bit values, with the third component being calculated on the fly. Depth, specular power and height are all 8 bits per pixel.

All in all, this data gives me the ability to do full dynamic lighting, and with all the different tricks, the memory overhead is workable, though perhaps not ideal.

I still have a few bits to finish off with the conditioning pipeline, but it feels really good to have the bulk of it done – this should allow me to focus on what I want my assets to look like, without having to waste a lot of time on getting them in the right format for the game.

I’ve continued experimenting with my tile generation code for my Manticore engine. I’m already quite happy with the way my ground tiles are coming along, and I feel confident that I can make them into something really useful, but I also wanted to see if I could use a similar technique for generating wall tiles. I want to make some games that takes the player not only down man-made dungeons, but also natural caves or tunnels carved through rock. I think it will be tricky to get it looking just right, but the initial results look promising (at least when you put in a few props and a character to distract the viewer a bit ). The technique is pretty much the same as for the ground tiles.

Being a programmer who only dabbles in art, I like tools that save having to do art work, so I try and generate things whenever I can. For my Manticore isometric engine, I would like to have nice looking terrain tiles, so I’ve started experimenting with code which generates a height-map, takes a couple of plain textures and generates an isometric tile with nice slope-based terrain transitions and lighting. There’s a lot of work left until it is finished, but initial results look promising

Here’s the result (and below it are the different images I render from Poser):

What I’m actually doing here, is rendering four images in Poser – one for the basic textures, or albedo, one for the facing direction (or normal) of each pixel, and two for shadows (one for the ambient shadows and one for the shadow of a fixed directional light source). These images are then stored in a much more compact format – albedo is palettized to 8 bits per pixel, the normals are stored with 8 bits for x, 7 bits for y and 1 bit for z (for a total of 16 bits) and the shadows are stored as 8 bits per pixel (though I’m considering dropping it to 4 bits per pixel, which might work ok). Each of these are then RLE-compressed, making for quite efficient storage.

When I’m rendering, I do a straight forward deferred renderer (but I do it in software – no GPU acceleration in this prototype, but it will be eventually) where I render the four RLE datasets to four buffers, and then perform (linear space) lighting in a separate pass (for now, I do two full-screen directional lights and hemisphere ambient lighting, but I’ll add support for point lights next), followed by a final pass of "filmic tonemapping" (yeah, I got that from this years GDC presentation on Uncharted 2 )

And I’m quite happy with the result so far – If you want to see what it looks like when it is running, here’s a download link:

Download lighting demo

(I won’t be able to have dynamic shadows with this technology, and I guess it does look a bit funny when the light sources move and the shadows don’t, but I think I can live with that…)

I’m only just starting out now, but I will try and document my progress on here – both regarding the game itself (or rather, the first story), which is called “Rage and Sorrow”, as well as the isometric RPG engine I’ll be building to power it, which is called “Manticore”.

And just to feel like I’ve properly got started, here’s a preview picture of the main character. When the game starts, you won’t know much about him or his past, but you’ll learn more about him as the story unfolds.