Finally, it's time to work on the city's denizens... starting with the un-undead, otherwise known as "Humans".

More b3d exporting troubles

My first stop was Blender to add some animation frames to the guy in the jumpsuit that started this whole project. I added some key frames with five different poses, one for standing still, and the other four for various configurations of one foot on the ground, which, when put together, make it look like the little guy is walking. This is called a "walk cycle" and I found this tutorial made it simple to setup, literally taking an hour, beginning to end. Well, to be honest, I don't need a very accurate walk cycle because my guys are going to be quite small, so I can get away with cutting some corners.

Back to the Zombie Simulator, it was time to run the sprite generator module to see what It'd give me... Many moons ago, when I wrote the sprite generator, I planned ahead for handling multiple animation frames, though I hadn't had a chance to test it. After feeding the jumpsuit guy into it, the output was less than stellar. Sure, it was obviously animating, but the end result looked rather like half the vertices were being left behind as the arms and legs moved... it was looking like something out of an early 80's music video...

Thinking that maybe I'd screwed up the sprite generator, I loaded jumpsuit guy's b3d file into Irrlicht's example 09, which is a 3D model viewer and the same problem showed up, so it wasn't my fault, but I still had to fix it.

There were two possibilities that came to mind, one, that the guy's texture was spread across two different images (I ran out of room on the first one), and two, that the sprite model itself was split between two objects (the hair and collar are separate from the body). After playing around with the model for a while, it turned out that the problem was that the guy's model was made up of two separate objects. As soon as I merged both and re-exported, the sprite began to render correctly.

Back to the code, I added a new class to handle animations, created an XML file to store the animation info (no hardcoding for me!) and then created a single animated sprite for testing purposes at the top left corner of the map. Astonishingly, it worked, the little guy was actually moving, however I noticed after a while that he appeared to be doing the moonwalk... there were several animation frames missing.

What was at fault this time? The b3d exporter or Irrlicht's importer code? I put some debugging code into the b3d exporter and re-ran the export. The output showed that the b3d file had the correct number of animation frames, so Irrlicht was at fault here. Through trial and error, I've since discovered that that the only way to get animations to export properly from Blender is to use the b3d exporter's timeline option and extend the timeline so it includes one extra frame either side of the animation. Then, when Irrlicht reads the file it drops the first and last frame and the correct number of frames will be loaded.

To paraphrase, the latest b3d exporter lessons that I've learned are:

• A bone animation must include only one object
• Export using the timeline option with an extra frame padding the start and end of the animation

Moving forwards

The next step in this project is to finalise the road textures so I know how much room I have to play with for the pavement, then I can move onto setting up the path following for pedestrians, which should be a lot simpler than the vehicle path following. Pedestrians are a rude lot and will simply push past one another, dodging and weaving around obstacles. They don't don't need queue in neat orderly rows, they don't need to give way to the right and they move slow enough that collisions with each other are not an issue. It's so much easier dealing with legs.

After the guys are walking I'll be looking at creating some new skins for the human model to add some variety, and then it'll be be time to create a modified human model that will server as the lowest level zombie... mmm... zombies!