Regarding the static vertex data, most of the implementations I've seen use a UByte*4 for the associated bone indicies and a UByte*4 for the weights for those indices. This limits each vertex to being associated with only 4 bones, and if a vertex is associated with less bones, then it also performs same math as if it were associated with 4 but it uses weights of 0.0 for the extra bones.
I've usually seen the dynamic/animated bone data represented as a 4x3 (or 3x4) matrix containing rotation/scale/translation transforms relative to the bind-pose.
Incidentally, I don't have this working yet, but I'm packing indexes with a ratio of 3:1 into float vectors while maintaining 8-bit precision (I haven't done the actual math as to what the maximum practical precision is, but the packing is the same as RGB2Float), limiting the model to 255 bones, which should be enough in even the most fringe cases, but it enables more concurrently influencing bones without increasing storage. As for packing weights into a byte values, that results in a precision of 0.0039. I'm actually fairly curious as to whether this is enough (if it is, I'll definitely want to pack my weights as well). Incidentally, I'm limiting myself to 4 concurrent data streams since I'm using transform feedback to do the skinning, which supports 4 bones at most for now as the largest vector stream that can be passed to TF is vec4, which limits the number of weights that can be blended.
Where does the magic number 24 (or 48) come from? ;P
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.
Oh, that's from the Bob model discussed above
Modern FPS games often have ~50 characters on-screen at once
I'm doing a sports game at the moment with 30 characters, each with 60 bones, and who all have multiple different animation sources blended together unpredictably and IK applied on top -- the whole skeletal update part is still fairly cheap and only takes up a few milliseconds.
A fair point, but it really boils down to what the game is about. I'm personally targeting a non-kinematic solution (which, admittedly, begs the question why would one need skeletal animation anyway?).