<p>It works exactly the way you describe. Most 3D games work on <em>keyframe</em> animations, where the human animator sets the important positions (for each joint or whatever is being animated) and the times they should be shown. The times are usually a number of "frames", but these are just intervals of 1/60 s, regardless of what frame rate is actually achieved on the client machine. The computer <em>interpolates</em> between those keyframe positions to decide what to draw at any given time.</p>

<p>For example, let's say an animation has keyframes on frame 0, 6, and 12. These are the positions to show at the beginning of the animation, 6/60 s later (that's 0.1 s), and 6/60 s after that. The first frame is drawn with the pose from the first keyframe.</p>

<p>Let's say the game is running really slowly, and the next frame starts being assembled 0.05 s later (which would give a 20 fps frame rate). The animation system uses interpolation to make a pose that's halfway between the first and second keyframes, because the time is halfway between 0 and 0.1. Next, imagine things are speeding up a bit, and the next frame is drawn 0.04 s later. It's 0.09 s since the start of the animation, so the animation system makes a pose that's 90% from the first keyframe to the second keyframe.</p>

<p>If this frame rate continues, the next frame will be generated at 0.13 s. This time the animation system has to interpolate between the second and third keyframes, taking 70% of the second and 30% of the third. Note that the second keyframe was never drawn in this example, but it contributed to the poses that were drawn, through interpolation.</p>

<p>Now to finish off the example quickly, let's assume the computer really slows down so the next frame is another 0.07 s later, making 0.2 s since the start of the animation. This is exactly the time that the third keyframe was set for, so the animation system just uses that pose. Although the animation was designed to take 13 frames (including the one at the start), we've finished it in just 5 frames of jerkiness, but it still takes the same length of time, 0.2 s.</p>

<p>In summary, it doesn't matter what time each frame actually comes out on the end system, because we can make whatever pose we like via <em>interpolation</em>.</p>

CC BY-SA 4.0
2019-02-09T17:42:41.603Z
What about moving a shape around with the keyboard? In this case, there is no way of knowing where the next 'keyframe' is going to be and therefore you can't interpolate anything to get a consistent speed.
That_one_guy
CC BY-SA 4.0
2019-02-09T10:41:08.787Z
2019-02-09T10:41:08.787Z
Dan Hulme
<p>I recently noticed that in all games, no matter what system you play on or what specs you have, your character will always move at the same speed even if there is  no frame rate limit. I was wondering how this worked because if you were to add the same value to a variable, the animation would be faster on faster processors or graphics cards. I heard somewhere that you could use the time between frames to reduce the speed. I do not see how this would work. So how would you get a consistent speed across all systems?</p>

<real-time><animation>
Consistent animation speed across systems
That_one_guy
# Consistent animation speed across systems

(Asked by: username_0 on 2019-02-09)

I recently noticed that in all games, no matter what system you play on or what specs you have, your character will always move at the same speed even if there is no frame rate limit. I was wondering how this worked because if you were to add the same value to a variable, the animation would be faster on faster processors or graphics cards. I heard somewhere that you could use the time between frames to reduce the speed. I do not see how this would work. So how would you get a consistent speed across all systems?

**Tags:** real-time, animation


---

## 1 answers

### Answer by username_1 on 2019-02-09. Score: 1

It works exactly the way you describe. Most 3D games work on *keyframe* animations, where the human animator sets the important positions (for each joint or whatever is being animated) and the times they should be shown. The times are usually a number of "frames", but these are just intervals of 1/60 s, regardless of what frame rate is actually achieved on the client machine. The computer *interpolates* between those keyframe positions to decide what to draw at any given time.

For example, let's say an animation has keyframes on frame 0, 6, and 12. These are the positions to show at the beginning of the animation, 6/60 s later (that's 0.1 s), and 6/60 s after that. The first frame is drawn with the pose from the first keyframe.

Let's say the game is running really slowly, and the next frame starts being assembled 0.05 s later (which would give a 20 fps frame rate). The animation system uses interpolation to make a pose that's halfway between the first and second keyframes, because the time is halfway between 0 and 0.1. Next, imagine things are speeding up a bit, and the next frame is drawn 0.04 s later. It's 0.09 s since the start of the animation, so the animation system makes a pose that's 90% from the first keyframe to the second keyframe.

If this frame rate continues, the next frame will be generated at 0.13 s. This time the animation system has to interpolate between the second and third keyframes, taking 70% of the second and 30% of the third. Note that the second keyframe was never drawn in this example, but it contributed to the poses that were drawn, through interpolation.

Now to finish off the example quickly, let's assume the computer really slows down so the next frame is another 0.07 s later, making 0.2 s since the start of the animation. This is exactly the time that the third keyframe was set for, so the animation system just uses that pose. Although the animation was designed to take 13 frames (including the one at the start), we've finished it in just 5 frames of jerkiness, but it still takes the same length of time, 0.2 s.

In summary, it doesn't matter what time each frame actually comes out on the end system, because we can make whatever pose we like via *interpolation*.

> **Comments:**
> **username_0**: What about moving a shape around with the keyboard? In this case, there is no way of knowing where the next 'keyframe' is going to be and therefore you can't interpolate anything to get a consistent speed.  

---

