Game Engine BASICS (4) (model and animation, details level)

Part 2: Model and animation, detail level

Role Modeling and animation
How your role model looks on the screen, how easy it is to create them, textures, and animations are crucial to the 'uncredentials' factor modern Games are trying to accomplish. The role model system gradually becomes more complex, including a high polygon number model and a better way to move the model on the screen.

Now you need a skeleton model system with skeleton and grid details layers, single vertex skeleton evaluation, skeleton animation ignoring, and the angle of stay in the game. These have not even begun to involve some of the best things you can do, such as animation mixing, reverse skeleton kinematics (ik), and single skeleton constraints, as well as realistic textures of photos. This list can be further listed. But what are the things we really talk about here after we talk about all these things in professional words? Let's take a look.

Let's start by defining a grid-based system and a skeleton animation system. In a grid-based system, you need to define the position of each point in the world of the model mesh for each animation worker. For example, you have a model with 200 polygon hands and 300 vertices (note that there are usually not three to one relationships between vertices and polygon, because a large number of polygon often share vertices-using bars and slices, You can greatly reduce the number of vertices ). If the animation has a 10-digit animation, you need to have 300 data points in the memory. There are a total of 300x10 = 3000 vertices, each of which consists of X, Y, Z and color/Alpha information. You can see how fast this growth is. Quake I, II, and III both use this system, which does have the ability to dynamically deform the mesh, such as swinging the skirt or floating the hair.

In contrast, in a bone animation system, a grid is a skeleton composed of a skeleton (the skeleton is the object of your motion ). The mesh vertices are related to the skeleton, so their positions in the model are relative to the skeleton, rather than the grid representing the position of each vertex in the world. Therefore, if you move the skeleton, the position of the vertices that constitute the polygon changes accordingly. This means that you only need to make the skeleton movement. In typical cases, there are about 50 skeleton-significantly saving the memory.

Benefits of adding a skeleton Animation
Another advantage of skeleton animation is the ability to "Estimate" each vertex Based on the skeleton that affects the vertex. For example, the skeleton movement of the arms, the shoulder, the neck, and even the trunk can affect the mesh in the shoulder. When you move the trunk, the mesh moves like a role. The overall effect is that 3D animation is smoother and more credible, and requires less memory. Everyone wins.

Of course, the disadvantage here is that if you want to make organic things exercise well, such as hair, or shawls, in order to make it look natural, you have to put an astonishing number of skeleton inside, this will increase the processing time.

Other things that a skeleton-based system can bring to you are the ability to 'ignore 'a specific level of skeleton-"I don't care about what an animation wants to do to this skeleton, I want to point it to a specific point in the world ". This is great. You can let the model focus on events in the world, or keep their feet on the ground where they are standing. This is all subtle, but it can help bring a sense of reality to the scene.

In the skeleton system, you can even specify "I need to apply this special animation to the model leg, while a different gun carrying or shooting animation is played on the model trunk, and the different animation effects that the guy (role) shouted play in the model's head ". Great. Ghoul2 (using Raven's animation System in Soldier of Fortune II: double helix and Jedi knight I: outcast) has all these nice things, specifically designed to allow programmers to use all of these ignoring capabilities. This saved animation is as hard to believe as you do. I don't believe this rescue on an animation like you. raven has an animation for the role to walk and an animation for standing and opening fire, and merges the two animations in the form of walking and opening fire at the same time, instead of requiring an animation to indicate the role to walk and open fire.

More skeletons in the closet
The previously described effects can be achieved through a hierarchical skeleton system. What does this mean? It means that the actual position of each skeleton is relative to its parent, rather than that of each skeleton directly located in the space. This means that if you move your father's skeleton, all its child and child skeleton will also move, without any extra effort on the code. This is something that allows you to change the animation at any skeleton level and pass down through the rest of the skeleton.

It is possible to create a non-hierarchical skeleton system-but at that time you cannot ignore a skeleton and expect it to work. All you see is that a skeleton on the body starts a new animation, unless you implement a system that transmits information down, otherwise, the original animation is maintained for other frames under the skeleton. The first step is to start with a hierarchical system, and you will automatically get these results.

Many today's animation systems are beginning to see some new features, such as animation mixing. It takes a short time to transform from a playing animation to another one, instead of suddenly changing from an animation to another one. For example, you have a role walking and then it stops. Instead of suddenly changing the animation, you don't just need to stop his legs and feet in an invalid position. Instead, you need to mix them in half a second, so that the feet seem to naturally move to a new animation. It cannot be too high to evaluate this effect-mixing is a subtle thing, but if it is used correctly, it is really different.

Inverse Kinematics
Inverse Kinematics (ik) is a specialized term discarded by many people and has little to say about its true meaning. Ik is a relatively new system in today's games. With Ik, programmers can move one hand or one leg, and the rest of the model is automatically located, so the model is correctly oriented. And the rest of the joints with the model are themselves, so the model is correctly oriented. For example, you will say, "Good, hand, pick up the cup on the table" and point out the position of the cup in the world. The hand will move there, and the body behind it will adjust itself so that the arms can move, the body will bend properly, and so on.

It is also the opposite of Ik, called forward kinematics, which is essentially the opposite of the order in which ik works. Imagine a hand, a hand attached to the arm, and an arm attached to the body. Now imagine you hit your body heavily. Generally, the arm twines like a gash, and the hand at the end of the arm vibrates. Ik can move the body and let the rest of the limbs move in real ways. Basically, it requires the animators to set a large amount of information for each type of work-like the range of motion that the joint can pass. If the skeleton moves in front of a skeleton, the percentage of the skeleton moves, and so on.

Like it now, although it is good, it is a big problem to deal with, without it you can have different combinations of animations to get away. It is worth noting that the real ik solution requires a hierarchical skeleton system instead of a model space system-otherwise, they all take too much time and cannot properly calculate each skeleton.

LevelsGeometric System
Finally, we should quickly discuss the level of detail (in comparison with the level of detail used in the discussion of MIP ing) related to the geometric complexity of the scaling model ). Assuming that most PC games now support a huge range of processor speeds and the dynamic nature of any given visual scenario that you may render (either one role or 12 on the screen ?), You usually need some systems to deal with such situations. For example, when the system approaches the limit and tries to draw 12 roles on the screen at the same time, each role has 3,000 polygon, and maintain the real compaction rate. In such a scenario, the dashboard is designed to assist. In the most basic case, it is the ability to dynamically change the number of polygon of the role you draw on the screen at any given time. In the face of reality, when a role is far away, there may be only 10 pixels on the screen. You really don't need 3000 polygon to render this role-maybe 300 is enough, in addition, it is difficult for you to tell if you are on a business trip.

Some DSS will require you to build multiple versions of the model, and they will rely on the close proximity of the model to the observer to change the dump level on the screen, and how many polygon are being displayed at the same time. A more complex system will actually dynamically reduce the number of Polygon on the screen, at any given time, any given role, dynamically-Messiah and sacriice ice include this style of technology, although it is not cheap in terms of CPU. You must be sure that, compared to simply rendering the entire thing first, your DLE system does not spend much time calculating the polygon to be rendered (or not rendered ). Either method will work, because we are now trying to plot the number of Polygon on the screen, which is very necessary. Note that DX9 supports hardware-executed adaptive geometric scaling (tessellation ).

To sum up, we can get a model with smooth motion, visual credibility of its performance and movement, and realistic display on the screen. Smooth animations are often obtained by combining manually created animations and motion capturing animations. Sometimes you just create a given animation manually-when you are doing something you cannot do in real life for a model-for example, you can't really bend backwards, or kick your leg on a walking bicycle like lui Kang In Mortal Kombat 4, and usually get out of the game when it's done! Motion capturing animation-in fact, video capturing live actors run through the animation you want to see on the screen-is a way to get realistic things. A realistic thing makes a normal game look great and can hide many things. For example, in the NFL blitz, the model on the screen has about 200 polygon. When they are standing at rest, they look terrible. Once these models run, they have fast and smooth animations, and many of their ugliness disappears. What the eyes can easily see is a 'lifelike 'animation rather than the structure of the model itself. A good model designer can mask most of the model defects.

I hope these will give you insights on model and animation issues. In Part 5, we will go deeper into the construction of the 3D world and discuss some physical, motion, and effect systems.