Animations

In this chapter we will add support for skeletal animations using compute shaders to perform the required transformations to animate a model. By doing so, we will handle static and animated models in the scene render stage exactly the same way. The compute shader will perform the required transformations and will dump the results in a buffer that will be bound when rendenring the scene as in the case of static models. By doing that way, we will not need to change a line of our current shaders, we will just be accessing buffers that have vertex information with the same layout. Please keep in mind that, in order to keep this example as simple as possible, we will simplify the animation mechanism, for example, we will not be interpolating between animation key frames and we will not control animation duration.

You can find the complete source code for this chapter here.

Skeletal animation introduction

In skeletal animation the way a model is transformed to play an animation is defined by its underlying skeleton. A skeleton is nothing more than a hierarchy of special points called joints. These joints are organized in a tree-like structure, a joint can have a parent and several child joints. In addition to that, the final position of each joint is affected by the position of their parents. For instance, think of a wrist: the position of a wrist is modified if a character moves the elbow and also if it moves the shoulder.

Joints do not need to represent a physical bone or articulation: they are artifacts that allow the creatives to model an animation (we may use sometimes the terms bone and joint to refer to the same thing). The models still have vertices that define the different positions, but, in skeletal animation, vertices are drawn based on the position of the joints they are related to and modulated by a set of weights. If we draw a model using just the vertices, without taking into consideration the joints, we would get a 3D model in what is called the bind pose. Each animation is divided into key frames which basically describes the transformations that should be applied to each joint. By changing those transformations, changing those key frames, along time, we are able to animate the model. Those transformations are based on 4x4 matrices which model the displacement and rotation of each joint according to the hierarchy (basically each joint must accumulate the transformations defined by its parents).

If you are reading this, you might probably already know the fundamentals of skeletal animations. The purpose of this chapter is not to explain this in detail but to show an example on how this can be implemented using Vulkan with compute shaders. If you need all the details of skeletal animations you can check this excellent tutorial.

Processing the models

We need to modify the code that loads 3D models to support animations. The first step is to modify the ModelData struct to store the data required to animate models:

File: src/eng/modelData.zig

zig

pub const ModelData = struct {
    ...
    animations: std.ArrayListUnmanaged(AnimationData),
    animMeshes: std.ArrayListUnmanaged(AnimMeshData),

    pub fn cleanup(self: *const ModelData, allocator: std.mem.Allocator) void {
        ...
        for (self.animations.items) |*animData| {
            allocator.free(animData.name);
        }
    }
};

The new animMeshes attribute is the equivalent of the meshes one but for animated data. That list will contain an entry for each mesh storing the relevant data for animated models, not th evertices but data structure that will allow us to animate a specific mesh. In this case, that data is grouped under the AnimMeshData struct and contains two arrays that will host the weights and associated bones (joints) that will modulate the transformations applied to the joints related to each vertex (related by their identifier in the hierarchy). That data is common to all the animations supported by the model, since it is related to the model structure itself, it models its skeleton. The animations attribute holds the list of animations defined for a model. An animation is described by the AnimationData struct and consists on a name the duration of the animation (in milliseconds) and the data of the key frames that compose the animation. Key frame data is defined by the AnimatedFrame record which contains the transformation matrices for each of the model joints for that specific frame. Therefore, in order to load animated models we just need to get the additional structural data for mesh (weights and the joints they apply to) and the transformation matrices for each of those joints per animation key frame.

Let's define the new structs. We will start with AnimMeshData one:

File: src/eng/modelData.zig

zig

pub const AnimMeshData = struct {
    weights: []f32,
    boneIds: []i32,
};

As you can see is just contains an array of floats for the weights associated to a bone (or joint) and and array of identifiers for these bones / joints. The Animation struct is defined like this:

File: src/eng/modelData.zig

zig

pub const AnimationData = struct {
    name: []const u8,
    frameMillis: f32,
    frames: []AnimatedFrame,
};

It is just defines a name, the milliseconds that each frame should last and a list of frame data modeled by the AnimatedFrame struct:

File: src/eng/modelData.zig

zig

pub const AnimatedFrame = struct {
    jointMatrices: []?[16]f32,
};

A frame is basically a list of transformation matrices associated to each joint / bone. These matrices will model how each of these joints will be modified (translated, rotated and scaled) according to the specific frame. Each of these joint / bones will affect the associated vertices through a weight.

Finally, we need to update the loadModels function to duplicate animation data string name:

File: src/eng/modelData.zig

zig

pub fn loadModel(allocator: std.mem.Allocator, io: std.Io, path: []const u8) !ModelData {
    ...
    for (modelData.animations.items) |*animData| {
        animData.name = try allocator.dupe(u8, animData.name);
    }
    ...
}

Let's review now the changes in the model generation code: