I was wondering what you would think would look better and be the least stress on hardware for an animation or a flip book style for displaying movements of characters. This is also for a mmorpg so there'd be other actors involved. (by flip book style i mean taking a picture of the model then moving it a few degrees and so on then putting it into a .avi or even showing 1 picture then another)

That would be 2D vs 3D. 2D is usually more stressful on memory, where 3D is more stressful on the CPU and GPU. 2D can become extremely demanding of memory if you're creating a game with many animations or character types. A typical 3D animation would cost about 35 kb, where a list of 2D sprites to do the same thing in eight directions would usually be in the megabytes, depending on scale and bit depth.

Mario64 actually used "flipbook" style, and it was 3d. As the above poster said though, it might be easier to program a flipbook style, but the amount of space to store all the frames for the models or sprites is huge.

Sorry, I forgot about the keyframed mesh animation method. I've never really understood why that's used. It seems pretty wasteful. I guess it must use less processing?

Quote:Original post by justdan
I was wondering what you would think would look better and be the least stress on hardware for an animation or a flip book style for displaying movements of characters. This is also for a mmorpg so there'd be other actors involved.

(by flip book style i mean taking a picture of the model then moving it a few degrees and so on then putting it into a .avi or even showing 1 picture then another)

They result to the same thing. OpenGL and DirectX don't know and mostly don't care anything about "animation" beyond the matrix transforms necessary to accomplish them. You render a frame and display it. If you want to animate, you do a 3D matrix transform on your vertices and then render them. You must be talking about precomputing and storing the results of the transforms. Doing this it takes up memory, and memory is precious. Look at how long the levels in HL2 take to load. It takes much less memory to define the "bones" and "skin" and do transforms on fly.

"Flip book" animation might end up looking worse, since it is harder to scale with the hardware. If you store 30 frames/second, thats the best its going to do. OTOH if you store alot of fps and your render can't handle it, then you will have to pick a frame to render and it probably won't look as smooth.

Ya it's going to be a 3d game so it's not 2d vs. 3d there are ways to do it like you just said=). So do you think animations would be the best way to go? It wouldn't limit or over work the computer and it'd probably be easier to store.

Quote:Original post by Jiia
Sorry, I forgot about the keyframed mesh animation method. I've never really understood why that's used. It seems pretty wasteful. I guess it must use less processing?

Well, as I understand it, key frame animation takes the best of both worlds. On one hand, there are keyframes that are loaded into memory, which will be smaller than storing full 30 frames/sec of animation. Then when the animation is played, pixels are interpolated between keyframes. This is much cheaper than calculating free-form mesh deforms and motion.

So, rather than rotating a limb by a certain amount every frame and the figuring out its new location, you simply interpolate based on some curve function, the current position, and the next keyframe. Most interpolation functions are much much cheaper than rotation.

As for the topic on flip-book style animation, well, one thing about flip-book style animation is that you can throw framerate out the window. Animation doesn't need to bo super fluid. Many times you can get away with half the frame rate. Also, with a few texture compression tricks, you might not need to use up that much storage space in memory. The irony is that sprite animation was created because of limited storage and processing power. They don't take up megabytes, usually like in the low kilobytes range. Of course, if its in 3D, then you probably have to think up some other trick, but I don't feel its completely impossible.

Quote:Original post by Anonymous Poster
Well, as I understand it, key frame animation takes the best of both worlds. On one hand, there are keyframes that are loaded into memory, which will be smaller than storing full 30 frames/sec of animation. Then when the animation is played, pixels are interpolated between keyframes. This is much cheaper than calculating free-form mesh deforms and motion.

I think you're a bit confused. Skeletal animation doesn't use anywhere near as much memory as the method you speak of.

• I could load in 5 minutes of animation for about the same memory price as your 30 seconds. I need nothing more than a bone list of quaternions and vectors for each keyframe, where you need a vertex model.
  
• All of the vertex processing with skeletal animation is unloaded onto the GPU. So performance loss, if any, is very much worth it.
  
• Your method relies on the size of the mesh. The higher resolution your mesh, the more memory you need to make the animations. Skeletal animation could use thousands of animations for a 70,000 poly warrior and stay well within reasonable video card memory requirements.
  
• Oh, skeletal animation doesn't use video memory. It uses system memory, which is like buying dirt. It's very cheap.
  
• Skeletal animation is universal. I can load in thirty completely different character models (fat guys, skinny guys, big guys, small guys, girls, women, apes, monsters and so on) and let them all use the same running animation.
  
• Related to above, skeletal animation also allows skinmesh clothing to be sported by characters and also animate using the exact same animation as the character wearing it. Is wearable clothing & armor even possible with the keyframe mesh system?
  

Quote:So, rather than rotating a limb by a certain amount every frame and the figuring out its new location, you simply interpolate based on some curve function, the current position, and the next keyframe. Most interpolation functions are much much cheaper than rotation.

Huh? It sounds like you have no idea what you're talking about. A rotation, a bone rotation, is exactly that, interpolated between state keyframes. You're saying that interpolating 1500+ vertices is faster than interpolating 30+ quaternions and vectors? I would like to wager on that.

Bone keyframes can be as far spaced as you want, as well. Which means each bone can be individually optimized to have as few frames as possible while still having the same play time. In other words, in a 4 second jump animation, the left forearm could use 50 keyframes, where the left hand, which doesn't move much, could end up only needing 5 keyframes. Both animate for 4 seconds, but the keys look like this:

.X..X..X..X..X..X.....X..X..X....X..X - Left Forearm.X..................X...........X...X - Left Hand

Quote:Animation doesn't need to bo super fluid.

I hate to disagree with you so much, but I am again.

Quote: The irony is that sprite animation was created because of limited storage and processing power. They don't take up megabytes, usually like in the low kilobytes range.

Erm, not if it's in today's market. Megabytes are us. Trust me, I've created very simple 8-bit heavily animated games. Those little dudes use up about three megs each.

Vertex animation, like the one used in quake, is slightly easier to program, and has somewhat better performance. Considering that back in the days of software renderers, polygon count had to be very small, that's why the memory used by vertex animation was not that much larger than in skeletal animation.
Also vertex animation is somewhat more flexible, though smooth rotating movement might need high frame rate or non-linear interpolation.