Greetings all,

I'm currently developing a 2D game which has an isometric view. Think the original StarCraft or SimCity. However, the art is being produced primarily in 3D to get the different viewing angles correct for all objects in the game. We're planning on taking snapshots of each model from particular viewing locations to generate sprites for drawing in the game.

While perfectly doable, I feel like if I could get a solid animation system up and running, we would not even need to do this hack from the era of the 90's and instead do as many games do today which is to keep the gameplay essentially still 2D but utilize the actual 3D assets and render the game in 3D. To be sure, there's some work to be done with both methods. However, I've never had to use or write an animation system before.

As (mostly) a personal research project, but with hopes of using this in production, I'm looking to investigate what I would need to do to implement the animation of rigid 3D models. The game consists of basically tanks and other vehicle-like models. No characters like humans or animals, just rigid 3D models. Turrets turning, barrels rotating, treads cycling, etc. We may have mechanical walkers such as what you might see in Star Wars, so they may be humanoid in form, but again, these models are RIGID.

Given these constraints, I feel like coming up with a simple animation system wouldn't be incredibly difficult compared to doing a full skinning, morph target, and blend shapes system. What is involved in such an animation system for my requirements? My knowledge says I would just need to be able to import the 3D model data, the animation keyframes, maintain the hierarchy for each model in the case of being able to attach separate models to another model, and an interpolator?

What file formats are easily accessible and parsable (or should I use some binary format to avoid parsing)? How much should I worry about compression of animation data? Are there other gotchas with going basically full 3D and animation that are just too costly that I'm simply ignorant of?

you can start with toying with some simple kinematic chains.

For example, you may start with a simple barrel attached to the tank.
You'll need a point between the two shapes to use at the reference point for articulation.

Have the tank oriented to the terrain and reorient the barrel so that it points at the terrain.

However the learning curve is steep. once you reach this point, you are practically ready for full on skinning. the leap is not far from there.

You can probably find many references on .3ds format for hierarchical bone transformations. personally i learned with the milkshape 3d tutorial from a while back.
I have since then implemented my own exporter and dump the scene information to my own format.

But is skinning really necessary? Like I mentioned before, I only need to really animate the movement of completely rigid bodies. I don't forsee any requirement of changing the mesh in any way except for translations, rotations, and possibly scale in some specific cases. Skinning doesn't seem useful to me since I don't really have any articulated bodies where the meshes must deform in specific ways to make it look realistic. I'm not saying it doesn't seem like a good technique, but it does seem like overkill given my requirements.

No, skinning is not necessary, it sounds as if you just want to be able to animate tires moving, etc, without handling dynamics at all. This is as simple as creating a heirarchy of your objects. Each will get a local transform, and child object transforms will be relative to the parents space.

Sure thing, but what about for large models with multiple moving parts? Splitting each movable part into its own model seems unintuitive. Say, for example, I have a turret which can be attached to multiple different tanks. The turret itself makes sense to be its own model. However, the turret may have its own animations in it, like the barrel recoiling. Would I have to export the barrel out as several different models?

I'm not very experienced with 3D modeling packages and their output formats. I assume various modeling/animation tools will allow you to output the animation data in a variety of ways? Or do they all output in a particular format and you must parse yourself and then transcode to your own expected format? It seems like the way the animation data is initially formatted can have a huge influence on what kind of animation technique you use.

For example (and I have no knowledge of what real 3D animation formats are like), an animation format exports data out in a way that is specifically designed for skin and bones. If I wanted to do animation with key frames that contain the entire mesh data, then this format is worthless to me unless I can properly understand how the skin and bones animation is to be interpreted and generate the final mesh data, no? In this case, I might as well have just done the skin and bones animation since it basically requires me to know how to do that to even get the final mesh data.

Yes, you will need to split your model into as many parts as you want to articulate, and build hierarchies of models with local transforms, when doing rigid animations.
Usually this is on the artist, to deliver models with hierarchies set up, and keyframe transforms for all the parts.

I'd say its quite a lot easier to do a rigid animation system then full skinning, you just need to interpolate the transforms and multiply them together right, and you are more or less home.

At least if all clips are independent, and you don't need to blend animations, but I think you shouldn't need that for vehicle type models... (for walk cycles you might need it if you have for example a jump and a walk, it needs to smoothly go from walk to jump in any point in the walk animation.)

One thing to look out for is an explosion of draw calls, because of the model splitting... You can solve that with various batching techniques if that is a problem on your platform.

Fantastic! Would you recommend storing all orientation information as quaternions to avoid problems during key frame interpolation? As far as batching draw calls go, I haven't crunched any numbers, but I don't think that the batching would be worth doing if the CPU transformation cost is high (ie - Model data is large)? Hard to say without real data.

Yes, quaternions is definitely the way to go.
Yeah, if batching is a good idea depends on both hardware and real data, just thought it was worth mentioning.
We use it for our latest iOS-game, with good benefit