@Zeth vertex weights are not that long in games since the computations are heavy...standart HL uses software skinning and vertex weights would use 4time the power of non vertexweights models, that's why older games doesn't support it.
My wording was that older mesh
formats from 1999 allowed vertex weighting (which they do). If we exclude tech demos from research groups/GPU creators and consider commercial games only, yes, you may hit the 2001 margin.
Anyway i thought about vertex animations and there are some problems with it wich are the reason why it isn't used that much. First they are huge to store, 2nd they are **** to blend, just look at zeq2lite when flying from left to right, the model flattens. 3rd without submeshing it's hard to blend mutiple animations for different part of a model together, you most over have no hirarchial structure.
ZEQ2-lite uses morph-based vertex animation NOT pose-state based vertex animations. There's quite a huge difference. Morph-based vertex animations are essentially just snapshots of the ENTIRE mesh every single frame. This is why Quake 3 naturally can perform vertex animations, but yes, it's also why the file sizes are so large. The flattening of models, however, is not due to the vertex animation format (at least not fully). The reason it occurs is because the engine naturally interpolates the previous frame with the next (sort of an automatic vertex tween). Since many of ZEQ2-lite's animations were designed in single frame styles, there's no animation data to propagate the tween and thus the model contorts to try and predict the transition. If bone data existed OR if the animations had a higher frame count, a normal and natural tween would occur.
Additionally, you don't need to submesh the model with pose-state vertex animations. Just like skeletal blend masks (which I'm sure you use to play individual bone-based animations on specific parts), you can use a vertex pose state on a particular set of vertexes with a simple mask. The result is that the file size is very small and the vertex-pose can be weighted to any value you choose on any region of the model.
Most games today use bones for a simple reason...it's faster and easyer to hardware accelerate. To animate a vertex animation based model you would have to store current vertex and the vertex of the next frame and blend. Wich means storing at least 2 times the data on the GPU and you need to parse the new geometry to the GPU every frame wich is slow aswell.
Just to clear any misconceptions, let me say that morph-based vertex animations are actually much faster than skeletal animations (but use more memory, obviously). Pose-state animations are only slightly slower, but that's only if are aren't using a vertex shader for hardware skinning (which you should be unless your bottleneck is GPU-oriented already [which it shouldn't be]). Even if you were using pose-state animations on the CPU, you'd see similar (if not better) performance than using bones to track the changes -- not to mention how much easier it'd be on your artists. Modern games do not use skeletal based animations exclusively but rather rely on what I mentioned above -- facial expressions / clothing and so forth with pose-state vertex animations and core limb movement handled with skeleton animation.
I can understand completely though if time of development overhead would be a complication.