A whole lot of animation, with a whole lack of compute.

Ok, 'lack' is probably a strong word. And this was a topic that, when I first began researching it for my complex games unit earlier this year, I had not heard of, despite its honest to goodness awesome nature!

I am, by no means, an experienced enough programmer to write a decisively fantastic resource on this topic, but, it would be cool to get words down about my experience using Vertex Animation Textures (VATs, from now on) and talk through the theory and implementation of them, assuming you're going from the ground up!

Chapter the First: What the heck IS a VAT?

Indulge me a little, for a piece of tech that I spent a good amount of time developing, I would like to infodump a lot. Feel free to skip forward to the next section if you're already pretty in the know about them!

But, first, in short, and in a fashion I would answer this question if you caught and asked me at my workstation, "This is":

I will assume no further questions from the audience.

But, in all seriousness, to understand what a VAT is it's best to first understand and revise the basics of what skeletal animation is, and why we may use them in its place. Skeletal Animation involves using a collection of matrices that represent the position, scale and rotation of a metaphorical 'bone' in a set of bones called a 'rig' (or 'joints' and 'armature,' for those of you more blender inclined folk). These matrices operate on the positions of vertices, typically three-dimensional positions in space, and transform the base positions of a mesh to another pose. If you want a quick graphics programming focused rundown on the topic, this article on learnopengl.com, or these videos and articles by ogldev are both a good place to start! They're where I learnt from!

The perks of skeletal animation are honestly, pretty clear. With a robust enough system, and a cool enough animator, you can do mostly anything to any mesh! And it is the standard practise for animation in games, film and other mediums! The major con of skeletal animation is that, in a lot of ways, it is computationally expensive, given each entity needs to, every frame it would be animated, traverse its skeleton and update the transforms of each bone. That can be a lot, especially for a game like Mall or Nothing (my capstone at AIE, read more here!)where there were expected to be about 200-300 animated entities loaded at once! And given the time frame!

VATs address the computationally expensive part of the problem, with some admitted tradeoffs. The reason Skeletal Animation is a bit pricey but still used is its versatility. It can animate anything, and blend between mostly anything as well. It'll let you have complicated animated characters, which is where its strengths lie. It is why we used it for the animation of our 'leader' units in Mall or Nothing, they were bigger, more important units, and their animations had important information to communicate to the player. VATs let you have a lot of smaller animations, at the same cost of rendering a textured static mesh to the screen.

To properly answer what a VAT is, I'll grab a quick slice of the image I showed above and we can walk through it!

The two dimensions of the each represent the Vertex (on the Y-Axis/the height), and the Timestep (on the X-Axis/the width), by using the current time in the animations duration as the x-axis UV, and the vertex number divided by the vertex count as the y-axis UV, you can find the offset for any given 'frame' of an animation!

To generate one we take the transformed positions of each of the vertices of a mesh, and then store the offset between them as a 3-dimensional vector, and then store than in RGB channels of an image. Before doing this, there is a pre-processing/planning step that needs to be done, where the 'maximum offset' a singular point can have needs to be defined. For Mall or Nothing, we assumed that 2 units (meters in our case) was a safe bet, but honestly that could have been clamped tighter. Then, the offset value is remapped from a range of negative to positive maximum offset, to the colour range of 0-255. That means that those grey splotches you see above are vertices that are roughly stationary at that steph of the animation!