#### Archived

This topic is now archived and is closed to further replies.

# Frame Interpolation

This topic is 6189 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Quake 2 achieved much smoother animation than Quake 1 partially because the mesh animations were interpolated, right? What would be a good way to start to implement this? The project I''m working on right now will probably end up using vertex-based animation, and I''d really like it to be smooth without having to store an ungodly high number of frames...

##### Share on other sites
Keep track of how meany interpolations you have done, then find a point between the 2 frames based on number of interpolations you have already done. You might also want put the fps into the equation as a guide for the number of interpolations.

Ben Gosney.

##### Share on other sites
I''m not quite sure I get what you mean. One way I thought of doing it was sort of implementing a "key frame" system like used in so many 3D modelling packages, where the animation data will be stored so as to say "Here''re the vertices for frame 0. Here''s the vertices for frame 1. They should move to this position over .1 seconds." and then during rendering, find the time since the current frame started, and just translate the vertices based on how much time has passed?

I''m sure it''s doable but it will require loads more overhead than what I have right now. Perhaps I could encode only the first frame, and then store the rest as "delta" values based on the previous frame, along with the time delta value.

Oh well, I''ve got alot of time to think about it since I just started the mesh implementation.

##### Share on other sites
I don''t think it will be as much work as you are picturing. It is just six multiplications and three additions. You are just scaling two vectors and adding them together. The scaling factor is the weight for the two positions for the vertex. If you are 25% of the way from one keyframe to the next then the position is 75% of the position in the previous keyframe and 25% of the position in the next one. Each frame you calculate the weight once because the time is constant for the whole frame. You could certainly do something like p1+(p2-p1)*(t-t1)/(t2-t1) but (t-t1)/(t2-t1) is a constant, call it w, and the equation can be rewriten as p1*(1-w)+p2*w. 1-w is also a constant, call it v, so for each vertex you only have to calculate p1*v+p2*w. Chances are there are far more wasteful things you do in your program than that.

##### Share on other sites
I don''t know how your animation system works. If your game has segmented models in which each keyframe is a set of rotations and origins of the different components, then things are a little more complicated. There have been some posts on the forums about this. Look up quarternions.

If, instead, each keyframe is a seperate model (with the same number of verteces), then you can interpolate the positions of the verteces. If verteces are ordered the same way in all keyframes, then you just need to linearly interploate between corresponding verteces as LilBudyWizer suggested. If they are not, then you need to determine which verteces correspond. This would best be done as a pre-processing step which would order the verteces in each keyframe for you. The simplest technique would be to pair verteces nearest each other.

##### Share on other sites
Yes, the drawing routine uses indices so every frame has the same vertices, just the positions change.

##### Share on other sites
There, I wrote a hacktacular if functional frame interpolation routine. Thanks for the suggestions! I''ll go improve it now.

1. 1
2. 2
3. 3
Rutin
15
4. 4
khawk
14
5. 5
frob
12

• 9
• 11
• 11
• 23
• 12
• ### Forum Statistics

• Total Topics
633661
• Total Posts
3013220
×