Making games with Unity often uses 3D characters, and skeletal animation is also used. The impact of skeletal animation on performance is actually very large. Before talking about this problem, let's talk about the principle of skeletal animation.
I have done a variety of skeletal animations before, including writing 2D skeletal animation systems (similar to the more popular keel system now), and 3D skeletal model animations in stage3D of flash. The principle of skeletal animation is actually the same:
First of all, you need to have a model, 2D or 3D. These models are composed of vertices. The vertices of the 2D model are the four vertices of a quadrilateral, and the vertices of the 3D model are the triangle vertices of each Mesh mesh.
Then, you need to build a set of bones. These bones are in a tree structure, that is, there is a parent-child connection relationship. When the parent bone is moving, the child bone moves with the parent bone. Levels can also move on their own without affecting the parent bone.
Next, you need to make a correspondence between the vertices of the model and the bones, which are called skin weights. What skinning does is to specify how many bones a vertex is affected by, and then when the bones move, the vertices follow the bones according to the percentage of the weight. For example, a vertex is affected by 2 bones, the weight of the first bone is 30%, and the weight of the second bone is 70%. When two bones move at the same time, the first bone moves 10 meters to the left, and the second bone moves 10 meters to the right. If the right direction is the positive direction, then the actual position of the vertex should be -10*0.3 +10*0.7 = 4, which is 4 meters to the right. In the actual calculation, we will not simply multiply the percentage, but will use the matrix to calculate the final coordinates of the vertex after it is normally affected by each bone matrix, and then multiply by the percentage to add.
Finally, let’s talk about the skeleton parent-child relationship. For each child's bone, it is necessary to obtain its parent first, convert the local coordinate system through a matrix, calculate the local displacement, rotation and scaling of the child relative to the parent, and then convert the coordinate system to the world coordinate system to obtain the relative relative value of the child. The displacement, rotation and scaling of the parent are based on the actual position of the world coordinates, and the actual coordinates of the child bone in the final animation are obtained. If a character has more bones and the nested parent-child relationship is more complex, then the process of calculating the coordinate system conversion will be more complicated and the more CPU operations will be consumed.
In response to this problem of bone consumption, the game engines of all generations have their own solutions. For example, the very early Warcraft 3 model animation used vertex animation. This method is as follows. First, do the skeletal animation of the model in the 3D software, and then when exporting, calculate the actual coordinates of each vertex in the current frame frame by frame or how many frames apart, and finally only export each vertex of the vertex. Frame coordinate information without exporting bone information.
The advantage of this approach is that there is no need to calculate the coordinate relationship of the bones when the game is running. The current frame coordinates of all vertices are directly read, and then the vertex coordinates are set to solve the problem. Therefore, when the number of vertices of the model was very small (about 300 triangular faces for a character model), the character was in a fixed shape (no need for local dressing), and the frame rate requirements were not high, this greatly guaranteed the game's performance. operating efficiency.
But the disadvantages of this approach are also obvious. With the increase of the number of faces of the character model and the increase of the frame rate, the exported animation file will increase many times. Then, since the bone information is not exported, the information of a certain bone cannot be modified during the playback of the skeleton animation. Special animation effects (for example, the hand can be stretched according to the distance of the target when throwing a fist, etc.), and finally the most serious one, losing a basic function of skeletal animation, that is, dynamic skinning and dressing, each set of skeletal animation information Only for one model.
Later, when I was doing the skeletal animation of stage3D, I referred to some of this practice and made some improvements. When importing and running, I first calculated the actual coordinates of all bones in each frame of the skeletal animation, and then saved them. In this way, there is no need to calculate the parent-child matrix relationship every frame, only direct skinning calculation is required. In this way, the capacity of the exported file is guaranteed (after all, the flash page game is still very particular about the file size), and it can also be dynamically skinned, because only the bones are fixed, and it has nothing to do with the model. However, doing this still cannot change the bone information to do special effects during playback.
Having said so much, it is estimated that you have a certain understanding of the principle of skeletal animation. Then I naturally think of some efficiency issues that affect the playback of skeletal animations:
1. The number of vertices of the model itself
As you can see from the skin weights point of view, the more vertices there are, the more times each vertex's final coordinate needs to be calculated during playback.
2. The number and complexity of model bones
From the calculation of the parent-child relationship of the bones, it can be known that the more bones, the more times the matrix coordinate system is calculated.
In order to make the skeletal animation smooth, in general, we will specify the number of faces and bones of the character model in the game. For example, in a game with slightly better effects, the protagonist has about 3,000 faces, and the mobs have about 1,000 faces. Then the number of bones for humanoid characters is generally around 30.
In the Unity engine, there is an optimized function for bones. Here is a practical example to illustrate:
We import a monster model, and then in the Hierarchy panel, we can see all the bones on this model.
Select the original fbx file of the model in the project panel, you can see the setting parameters of the model import in the Inspector panel, and there is an option of Optimize Game Objects in Rig, check it.
Then drag the model into the scene. Now you can see that only the mesh mesh is displayed below the model, and those skeletal structures are gone. At this time, you can see that the animation of the character can be played normally.
At this time, you will think of a problem. If I add some control nodes to some bones, for example, I bind an object to the bones of my hand for weapon binding, then I can't see the bones now. Can't be bound like this? In fact, there is still a way, go back to the fbx import settings:
Click the plus sign in the lower right corner to select some bones you specify to exclude, these bones will not be hidden.
At this time, drag the fbx into the scene again, and you can see that the excluded bones we just selected appear on it.
After this is processed, first of all, there is no need to generate so many bones in the scene, and the number of scene objects is greatly reduced, and then Unity will help you simplify the matrix transformation of bone calculation (the specific processing method is not officially explained, it is estimated that it is similar to when I was in Stage3D. processing), which can reduce the consumption of skeletal animation playback.