VBGamer (© 2002) - Keyframe Theory

Keyframe Theory
cbx	So I have finished the writing the code and 3DS MAX script for a video demonstration I am working on for my website. When I began to wonder about keyframed animation, and my existing code that does keyframe animation contained within my DX9Tools library. As I looked at the Track View in 3DS MAX I began to wonder about how to go about creating a second video demonstration that would show how to export animation data for the mesh data that I would be exporting from MAX. I cirtianly was not looking forward at writing all the timing code and math that is involved in creating such a thing. Then I thought in my head "Well why don't I just export 30 keyframes for every 1 sec of animation" That way I could avoid all the math and timming code involved in implementing keyframed animation system and I could simply retrieve a keyframe value simply by using an index. So here is the data table I came up with ... 4 bytes per key value (this value represents an animated x rotation, or z position etc) Times 30 FPS ------------- 120 bytes per 1 sec of animation Times an average animation length of 5 sec ------------------ 600 bytes per 5 sec of animation Times 9 tracks needed for animation (xyz key values for position, rotation, and scale) --------------- 5400 bytes total per 5 sec of animation ( if each xyz axis for position, rotation, and scale were all animated ) Times 2400 animations with an average of 5 sec per animation in the game (200 objects in the game each object has 12 animations so 200x12=2400 animations) ------------- 12,960,000 bytes total needed for game (only if all game animations are loaded in game at once and each object has 12 animations and each animation is 5 seconds in length) So basically you can have 200 objects and for that 200 object in you game you will need to allocate 12.9 megabytes for keyframe animation. Sounds pretty resonable to me considering how much easier it is to write code for, as well as making your code run faster. The code will run faster because you will never have to calculate position, rotation and scale values at runtime. So what does everyone thing about this? Do they think that sacrificing 12Mb of mem is worth it to make creating the keyframe animation code simpler/easier to work with?
Scorpion_Blood	i think 12mb isn't alot for nowdays... who his the guy that have less than 128mb?
cbx	quote: Originally posted by Scorpion_Blood i think 12mb isn't alot for nowdays... who his the guy that have less than 128mb? That's what I am thinking. If you game is targeting hardware requirements of 512Mb of memory, what's a measly 12Mb. Also that data table is a little decieving an hard to figure because if you are storing keyframed animation data for a 3D bipedal human character then that character needs at least 8 joints for it's arms and legs in order to do a run (Shoulder/Elbow/hips/knees), so for a running animation you would take up ... 8 joints x 3 xyz rotation axis per joint x 600 bytes (5 sec animation times 30 FPS) ---------- 14,400 bytes needed for a running animation for a 3D bipedal human character's running animation. Even 25,000 bytes would still seem within reason. Also that the running animation would be 5 seconds long in unlikely, it would be more like 2 to 2.8 seconds long, but just to push up the numbers a little I specified 5 seconds of animation.
Eric Coleman	The descriptiong you're giving doesn't sound like keyframed animation at all.
cbx	quote: Originally posted by Eric Coleman The descriptiong you're giving doesn't sound like keyframed animation at all. It's still key framed animation, it's just that the key frame values for the animation would be precalculated and saved to disk by the 3d modeling application doing the exporting. Thus simplifying and freeing up time in the game loop for other things, rather then spending time calculating the inperpolation needed between keyframes at run time.
Eric Coleman	Your first post mentions storing scaling and rotation values, and that implies some sort of skeletal animation. keyframe animation, as applied to 3D graphics, is just storing different versions of the 3D model in different poses. keyframe animation uses LOTS of memory. A 3D model with 1000 vertices would be 32000 bytes for a single frame, assuming only a point, a normal, and a 2D textture coordinate. 8 numbers * 4 bytes each * 1000 vertices. A 5 second 30 FPS animation would be 4800000 bytes (4.8 MB). And that's just for one very low poly model.
cbx	I'm only refering to the actual Key values involved, when creating a animation in 3DS MAX for example. When I say animation I mean either skinned mesh character, or just a basic mechanical/machine animation. When you say "keyframe animation, as applied to 3D graphics, is just storing different versions of the 3D model in different poses." that would be tweening. I'm not tweening, or saving different meshes out in different poses. Example: at frame 0: there is a x rotation key value of 0 degrees at frame 12: there is a y rotation key value of 23 degrees So what the exporter would do is calculate/generate all x rotation keys between frames 0 and 12 and save them do disk. That way in our game when we draw a mesh we simply use an index to retrieve the value for the current frame of animation. Rather then having to calculate interpolation.
Eric Coleman	That sounds a lot like skeletal animation to me. Even with that method you do use "key frames" for different bones, but they don't have to be tied to a frame rate or even to each other. A Leg bone could have 5 key frames for a given animation while a torso could only have 2.
cbx	I'm not focusing so much on the mesh itself only the values of the keys. I will try to finish off the sample soon and post it so every one can see what I am talking about.
VBBR	The only problem with this method is that you're using frame-based animation, which can cause a lot of problems. I certainly prefer to spend some little time calculating positions real-time based on time elapsed than spending processor power to do the math needed to keep a steady framerate (and that's not to mention that if the machine is slower than you expect the game will be unplayable).
Almar Joling	I wish I knew how to do the skeletal animation by shaders, instead of looping through all vertices and applying the matrices to them. It's near unacceptable slow ;)