Hi ! I'm a lighting artist , currently working on some anime titles. One thing that I still don't really understand about game is frame rate control. Because in game's world , everything is dynamic , there might be more objects in this area and causing frame rate to drop from 60 to 20 , but how do game engine update animation movement according to frame rate ? What's the frame rate that animators are using while creating animation content for the game?
This can get kind of technical, but it’s an important consideration nonetheless. Let me try to answer your questions in reverse order.
First off, whenever an animator creates an animation, there’s a base frame rate at which it is captured or created. Typically, most animators I know work at 60 frames per second when creating source animations. Sometimes they work at 120 when they need a lot of granularity (e.g. anything with really minute movements, like facial expressions) or are working on a game that’s very animation-intensive. Sometimes they work at 30, because the frame rate for the game is locked. This is the theoretical maximum that the animation can play at to be true to the source. Should the frame rate of the game exceed than the animation’s source rate, you’ll most likely get interpolation (i.e. the animation system’s best guess) between actual source frames. This actually sets a maximum cap in terms of how smooth or real an animation can be, though it doesn’t do anything to something like camera movement granularity or other updates.
So then we need to actually figure out how a game’s animation system actually plays the animation data. In order to understand this, we need to understand just what sort of data we need in order to play an animation. In order to play an animation, we need two things - for a given bone we need to know where it is (position), and when it is at that location (frame time). If we have a bone at position X at frame N, and then it moves to position Y at frame N+1, then we can display it at the appropriate locations in the game. So what happens when our game’s frame rate differs from the source data’s frame rate? This is where we have to start doing our interpolating.
So imagine that we sourced our animation at 60 frames per second, but we’re playing back on screen at 30 frames per second because there’s a whole bunch of things being drawn at once and the CPU is chugging on all of the calculations it has to do. So if we want to figure out where the bones are at each display update, we need to figure out where they are at that time. Typically we load the entire animation into memory at once, so the animation system can easily ask the animation “Where are all of your bones at frame #5? What about at frame #29?” and get the answer in negligible amounts of time. All we need to do is know what to ask.
A simple way of calculating where the bones should be on the next frame is to store off when you started playing the animation, and then calculating how far into the animation you should be when the next frame is drawn (based on your current frame rate). So, for example, if you started at 0:00:00, and you know that your next update happens at 0:00:66 (66 milliseconds later), and you know that you’re running at 30 fps, then you calculate “At my current frame rate, how many frames does 66 milliseconds translate to?”. Let’s say that the answer is two frames (at 30 fps). Then the system can ask the animation “Where are your bones on frame #2?”, get the answer, and calculate where the bones should be relative to the world and display it. This forms the basis for looping an animation.
It can get more complicated if the result is in between frames. Imagine that it was 50 milliseconds instead of 66. Then, you could theoretically end up with your display time having to show a fraction of a frame’s worth of advancement. So what do you do in a situation like that? You can pick one of the two frames bordering where you’re supposed to be. This can end up “slicing” off frame data or padding one frame an extra few milliseconds and cause the animation to sometimes look a little choppy. You can try interpolating between the two frames to get a more exact look, but that can take extra calculation since you have to do a bunch of mathematical calculations for every single bone of every single thing that’s animating. But it would look a lot better.
This slicing problem is very hard to notice with the naked eye at higher frame rates, but much more obvious at lower ones. This is one of the reasons that some developers will lock their game’s frame rate at 30, especially if they know that performance may be an issue. Locking their frame rate means that they can source all of their animations at that same rate, and then they don’t have to ever worry about accidentally slicing animation data because of desynchronization between the display and the source data.
Of course, this entire explanation is an oversimplification of a very complicated problem to solve. There are all sorts of ways to build an animation system, and there are lots of engineers who devote their entire careers to expanding, improving, and creating animation systems. Different games have different needs as well, so things like a deformation system would make a lot of sense in a one on one fighting game, but less so in a FPS or RPG. You probably wouldn’t need much facial animation or a complicated blending system for a RTS, but you would for any action-adventure game that involves a lot of climbing, jumping, and running around. Still, for any animating and engineering hopefuls out there, it would be a good idea to learn some of these core principles of how an animation system actually works.
areudirty
turnnoffyourmind
gummygunk
germansingergirl
stormborns
kianamaiart
