Here begins the module 3 in the course "Video Games Creation, Art and Technology, Video Games Technology". In this module, we are going to learn 3D animation, Cal3D library, which we are going to use in our engine; animation types; cores and instances; artificial intelligence; animated models; the auxiliary classes we are going to use in our engine; bots and player. Video games animation started similarly to how classic animation worked in animation films. That is, capturing each of the animated model's frames and reproducing them on the screen. These were the first 3D video games. This kind of animation is called Keyframe animation. Later, with the polygons increase and the improvement in the modelling type and the graphics cards to render those models, the skeletal animation came. Skeletal animation, instead of being based on geometry captures animation for each keyframe, is based on the animation of the bones an animate model has. So, the picture at the bottom left would be the keyframe animation, where we have different captures of our animate model, and the image at the right side would represent the skeletal animation, in which we can see our model and some of the bones that make up this model. We are going to explain the pros and cons of each of these animation types. Keyframe animation pros are that it is relatively easy to implement, it has a little CPU load as the animation is precalculated, it comes directly from the geometry; and its cons are that as polygons increase, so do the data weight proportionally. That is, we need the geometrical model for each keyframe. This means for each keyframe we need all its vertexes and indexes in aim to be able to paint this geometry. If the vertexes size or number is very high, as we increase the frames capture, this data weight increases proportionally. Also, keyframe animations can give little fluid animations. Animations are captured in given frames. This means if we have a point between two captured animations, we will have to repeat one animation on the other. We can't blend animations. So, this will make animation less fluid. It's either this, or capturing more keyframes between them, but this would increase the data weight. On the other hand, skeletal animation's pros are keyframe animation's cons, and its cons are keyframe animation's pros. So, its pros are, first, that while polygons increase, data weight doesn't increase. Geometry would be in the memory only once. As vertexes and triangles data repeat only once, they aren't captured for each frame. And what is captured for each frame is the rotation position, basically the formation matrix of each of our geometry's bones. This, at a data level, is represented through quaternions. Each quaternion is composed by 4 floats. So if a geometry has between 30 and 80 bones, for each keyframe we would be speaking of between 30 and 80 for 4 floats. And also, if the geometry's vertex number increases, but the number of bones doesn't, the animation's size doesn't increase. Also the animations are fluid, as if they are made through bones, through quaternions, we can interpolate between one bone and another depending on the moment of the keyframe. That is, we can interpolate between a quaternion and another in a similar or lineal way, giving much more fluid animations than the ones by keyframe. Cons, we have the fact that it's not as simple to implement as keyframes animation, because we need to calculate the vertexes' position for each frame based on the bones transformation. Another con is that it has a high CPU load, as we just said, because we need to calculate each one of the vertexes. Although currently animation is made by shaders and we don't have this problem, it's not that serious because the graphics card does it through vertex. We will go to 3D Studio Max and we will open a 3D model and explain a little bit more how it works. Here we have an animate model made by a student in our master in 2010 where we can appreciate a bit how it works at a skeletal animation level inside 3D Studio Max. It will be explained with details in the art part but I want you to have a look at how both the idea and the theory work. We have our model, which is the character we see on the screen and has a certain geometry. A geometry we can see here in a gray color, And on the other side we have the bones. If we hide geometry we see the different bones, which are these elements represented here. These bones, which are painted in blue, represent our model's bones. Twice, the animator will have to animate, move and rotate each of these bones, and then our model will be animated. In this case we have a small animation on walking. If we hit play we see how it walks. OK. So, right now we have three concepts we have talked on. On one side, bones, on the other side, geometry, and the third is the skeleton, which consists on all the bones together. Once we understand this, we go to the next case. We go to the geometry part from 3D Studio Max. We have our character's different bones. Or, what would be the same, the zones which are affected by each of our character's uses. So, this part must be done by the modeller or the animator, it's the trivial part. Which what does is, on each bone, it associates it vertexes which are affected by those bones. So, the color zones we see here mean they are vertexes affected by this bone. What does this mean? This means if we transform or modify that bone, those vertexes will be modified by that bone. In example, if we go to a bone on the hand or the arm, we see the vertexes affected by that bone are the arm's vertexes. And then we have, on another side, that it is also affected by the shoulder's vertexes and some vertexes from the forearm and the elbow. These are heat points, which are more red or blue, define the weight of this bone by that vertex. This means they won't be affected by those vertexes the same way nor with the same percent which would affect the vertexes, they will affect more the ones which are in a blue color. Calculating a vertex's position, as I already said before, is currently made by shader. Where we will go to the code and we will see how we did it. Tabledata, effects, weight Index, that's it. We will open this file. We have our shader with the entrance vertex structure, which gives us the position, 4 weights and 4 indexes as using Cal3D for this animation will let us apply up to 4 different bones to a vertex, the normal and the texture coordinates. So, in the Vertex Shader what we will do is taking the starting position of the vertex and adding each of those positions to it, the transformation by weight for each bone associated to this vertex. So, if we look carefully, we have 4 indexes and 4 weights. From its position, it transforms for each of the transformation matrices of the bones by the vertex, by the weight of each of its associate bones. And the final result will be the position transformed by those 4 bones. Then if a vertex is linked to two bones, simply the third and fourth weight coordinate will have 0 as their value. Then, this is the way, these 4 lines from 37 to 40, are the way of calculating the vertex's geometrical position. In the normals we do something similar. In this case, it doesn't do it for the 4 vertexes, but only for the 2 first bones, so, it could also be for the 4 bones. So this would be the way to calculate the geometrical position of an animated model. So, once we've seen this, we must export our animated model to our game. To export our animated model, we will talk about 3 kinds of files: the mesh files, which will have the geometry information; the skeleton files, which will have the bones information; and then the animation files. Animation files will simply define each of the animation's keyframes, it will tell us the state or the formation material of each bone on the skeleton so that we can apply the animation to our model. So the final result will be something similar to what we see here on the screen. In a video games engine, things aren't usually created from scratch. They often use third-party components which are already programmed and operational. Middleware tools, etc. So, a skeletal animation library we are going to use is Cal3D, which will allow us to integrate animated models inside our video game through skeletal animation. So this Cal3D library is source-type. We can use it either at a commercial level and as a formative and/or educational level. So we will go to the web page to see how to download it and where is the own library's information. So here we find the library's web page. It's a library written in C++, independent from the platform. So it works with DirectX, OpenGL and libraries in specific platform graphics. And basically we will go to the download page to download it from the source. Here we have the different versions of the library we can find, as well as examples. I have already downloaded it and I usually use the 0.11 version of the library. So you've downloaded it and integrated it in our engine, so later I will go back to how to integrate from the engine.
