by taniwha » Thu Jun 07, 2012 11:15 pm
Why use varying rates (for skins, anyway): 0.4s on, 0.2s off (and other such things).
I agree that varying rates doesn't make as much sense for frame animations, but even then, it has its uses. The only real problem I can see with varying rates in frame animation is it would produce possibly weird results with lerping since the lerp blend factor covers the whole frame time. Yet another point in favor of csqc (qc controlled interpolation curves (and I'm still working on merging the nq and qw clients enough that they share entity code before doing any real csqc work:/)).
As for "fixing": GLQuake may have been an attempt to put a band-aid over the problem of the alias model format, but since it was never "documented" as such (separate program supporting the changes), I feel it should be treated as a band-aid: something to be removed as soon as possible. What to do about content designed for GLQuake's brokenness? Per-model flags (from an external file? can the data be auto-detected?) that control the load-time conversion of the data to the correct format.
QuakeForge is very much a "GLQuake was buggy, SW Quake is right" type engine. If anything, I will go down the load-time conversion path (though for the fullbright issue, that might need shader selection). QF already has per-model flags for 2x scaling (gl-eyes), fullbrignt rendering (torches), no shadows (torches, grenades), etc. Made a difference to alias rendering speed, and greatly improved the readability of the code. I moved the logic from the alias renderer to the model loader.
Talking about torches, I took a good look at their animation in blender: it seems the artist may have intended the animation to ramp up to the last frame, snap back to the first and at the same time rotate the model 90 degrees, thus giving the main flame a continuous spinning effect. I haven't tried it yet, though (more csqc?:P)