Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualMatias Goldberg

Posted 11 September 2013 - 06:09 PM

To slightly add to what AllEightUp said:

I only really see interpolation useful between animations and paramterizing animations. But an animation itself should have a full set of matrices per bone for each animation. If we can calculate it before runtime and it will always be the same, why not?

First of all, you're calling "animations" "animations", but also calling "keyframes" as "animations".

Interpolation/blending between animations is what happens when I have a character performing two animations at the same time i.e. walking and shooting. I want both to be active.

Interpolation between keyframes is when, inside the same animation (i.e. walking), the game is in a frame that lies in the middle of two keyframes; thus the result is obtained mathematically.
Like you said, you can calculate all keyframes at preprocessing time for a given framerate. Say if your game will run at 60fps, you would have to save the matrices/keyframes once every 16.666ms; and then play them.
But more often than not (particularly in PC), your game won't be running at exactly 60 fps, so you may want to interpolate. If you're running at 120fps, you'll have to interpolate i.e. at frame 89 you're actually in the middle between keyframes 44 & 45.

If you're running at 30fps you'll have to drop half of the keyframes. Now... if you're running at 32fps, you will have to drop 28 keyframes, but the problem is that you're not running at a framerate that is a whole divisor of 60. As such, when you're rendering frame 31; you would be somewhere between keyframes 58 & 59. You're actually at keyframe 58.125; which doesn't exist. You have to interpolate.

If you choose not to, and use keyframe #58 instead (which is the closest one to the theoretical 58.125) you could witness some jerkiness/stuttering in the animation. How visible this artifact is depends on the actual framerate at which you're rendering.

 

So the thing is, interpolation is almost unavoidable if you choose such technique, because even if your sampling frequency is too high, missmatches between the playback framerate and the framerate it was encoded with can cause artifacts.

 

Another issue worth mentioning is that high sampling frequency (i.e. 60fps) cause the memory consumption to skyrocket. A modestly detailed walk animation loop for a human rig with around 50 bones sampled @60fps can easily reach 20 MBs. And you won't get much more detail/quality than sampling at 15-30fps (for a videogame).

Also considering that computing power keeps improving (and animation is highly parallelizable) but memory bandwidth growth is stalled, if you're planning to have hundreds of animated objects in your scene, interpolating with relatively low sampling frequencies could give you much more performance than just preprocessing the whole thing at high framerates and playing it with no interpolation.


#1Matias Goldberg

Posted 11 September 2013 - 06:06 PM

To slightly add to what AllEightUp said:

I only really see interpolation useful between animations and paramterizing animations. But an animation itself should have a full set of matrices per bone for each animation. If we can calculate it before runtime and it will always be the same, why not?

First of all, you're calling "animations" "animations", but also calling "keyframes" as "animations".

Interpolation/blending between animations is what happens when I have a character performing two animations at the same time i.e. walking and shooting. I want both to be active.

Interpolation between keyframes is when, inside the same animation (i.e. walking), the game is in a frame that lies in the middle of two keyframes; thus the result is obtained mathematically.
Like you said, you can calculate all keyframes at preprocessing time for a given framerate. Say if your game will run at 60fps, you would have to save the matrices/keyframes once every 16.666ms; and then play them.
But more often than not (particularly in PC), your game won't be running at exactly 60 fps, so you may want to interpolate. If you're running at 120fps, you'll have to interpolate i.e. at frame 89 you're actually in the middle between keyframes 44 & 45.

If you're running at 30fps you'll have to drop half of the keyframes. Now... if you're running at 32fps, you will have to drop 28 keyframes, but the problem is that you're not running at a framerate that is a whole divisor of 60. As such, when you're rendering frame 31; you would be somewhere between keyframes 58 & 59. You're actually at keyframe 58.125; which doesn't exist. You have to interpolate.

If you choose not to, and use keyframe #58 instead (which is the closest one to the theoretical 58.125) you could witness some jerkiness/stuttering in the animation. How visible this artifact is depends on the actual framerate at which you're rendering.

 

So the thing is, interpolation is almost unavoidable if you choose such technique, because even if your sampling frequency is too high, missmatches between the playback framerate and the framerate it was encoded with can cause artifacts.

 

Another issue worth mentioning is that high sampling frequency (i.e. 60fps) cause the memory consumption to skyrocket. A modestly detailed walk animation loop for a human rig with around 50 bones sampled @60fps can easily reach 20 MBs. And you won't get much more detail/quality than sampling at 15-30fps.

Also considering that computing power keeps improving (and animation is highly parallelizable) but memory bandwidth growth is stalled, if you're planning to have hundreds of animated objects in your scene, interpolating with relatively low sampling frequencies could give you much more performance than just preprocessing the whole thing at high framerates and playing it with no interpolation.


PARTNERS