- Aug 2, 2002
- Best answers
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.@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.
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.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.
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.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.
Weighted vertexes in themselves do not effect triangle count, no. You have essentially the same vertexes as you normally would. The difference is that you are assigning the vertexes to more than one bone. Rather than a single bone influencing the vertexes movement, you can create a blend or "weight" value (a number from 0 to 1.0 gauging the percent). This weight value will let you control exactly how much influence the bone's movement has on the vertexes final position.My knowledge on models is quite slim, but do weighted vertexes automaticly increase the polycount ?