But what if I want a super slow-motion effect that effectively drops the game speed to 1/10th? That would force me to precompute waaay too many frames for each animation. Also, I'd prefer the accuracy of real-time bone interpolation. That's a good suggestion though. Maybe precomputing a few extra frames to increase the framerate of each animation to 3x, and then not using slerp but simple lerp+normalizing on the quaternion in a vertex shader would produce accurate enough motion. You could even precompute with bicubic interpolation too.
Question: is the "what if" actually a realistic expectation? Will you be implementing bullet time?
If the answer is yes, then you could do some dynamic branching - if the required animation speed drops below a certain threshold (say, the precomputed framerate), then interpolate the skeleton for that model on the fly. Note that bone interpolation is cheap for an average model. 30-60 bones isn't that big of a deal really and it's okay to do it when needed. The real optimization you should be looking into here is the actual number of updates per second. If you're running hundreds of models at 100 FPS, then updating them each frame is going to affect said FPS. If you update each skeleton every other frame, you won't be compromising any visual quality and you'll have effectively halved the work load. What is really expensive here is the skinning, which is done on the GPU. Note that the Bob model actually has a relatively low poly count (around 800 vertices) - take a proper model with 10k vertices and 50 bones and you'll be looking at roughly the same animation load on the CPU, but a 15 times more expensive skinning phase on the GPU. Vertices ramp up as time goes on. There's really no need to ramp up the number of bones in most cases.
Each frame requires about a kilobyte of data, Each animation may be shared between different meshes if they have the same skeleton layout, so the number of animations won't be that many. Let's say 20 units with different animation sets, each with 10 different 2 second animations. That'd be 20 x 10 x 2x24 frames of raw data --> each frame is 33 bones x 7 floats x 4 bytes per float --> 20x10x2x24x33x7x4 = 8.45MBs of data. Multiplying the number of frames by 4 is still just around 35MBs of data, so precomputing is a very possible solution. Nice idea!
It's likelier you want to store your animation as a list of matrices, not 7 floats, for faster access. Also, think about it realistically - if your model comes at 24 FPS, then multiplying it by 2 will be enough for any human. 100 keyframes per second will give you smooth slow motion, which you very likely won't be needing.
Its also good to note that not much animated stuff actually is rendered in any game other than an RTS. In that case you could worry about doing other things.
I don't really understand what you're saying...? ._.
What dpadam450 means is that the only genre in which you will realistically encounter a large number of models that need to be animated individually is an RTS games. In a general case you'll have 10 models tops running around at one time, which is a beeze to animate on the CPU.