I was wondering, which of the following implementations would be the best way to do animation in a 3D game that uses key frames. Here, a Key is nothing more than a completely seperate model which is really all the points of the first model in a different posistion. Like.... one key would be the model with his arm half way out, and the other key would be with his hand all the way out. When the program adds all the frames in between, it looks like he moves his hand from half way to all the way. basis: v1 == vertex in key1 v2 == same vertex in key2 vi == vertex after key frame interpolation all v''s contains fields x, y, z 1) The program keeps track of how much time has passed from when the animation sequence started, finds the percentage, and puts vi that percentage difference from v1 to v2. Stop when v1==v2. [flaws] can cause bad "skipping" on low end machines 2) Each loop, add a set amount to v1 until it reaches v2. Cap the frame rate so that it doesn''t get too high. [flaws] easy to animate too fast or too slow.. too dependant on machine speed... frame capping is bad. 3) Something I haven''t though of? How did you all do it in your projects. http://www.animerave.com

Option 1 is definitely the way to go. Option 2 is just option 1 with a capped framerate. Plus you would have a much bigger timing problem on a low end machine with #2.

Option 1 shouldn''t cause any skipping, it''s just a view of the animation at that point in time. Do you mean that the calculations slow down the framerate?? With many vertices, I could see the percentage multiplies taking longer than the simple additions, but this is how the Quake games do it (from what I hear), so it shouldn''t be TOO bad...




Zeus Interactive