Mod_LoadAllSkins - Bug Fix

framegroups simplify skeletal animation a fair amount. each 'frame' is an entire animation, and supporting multiple blends is required anyway - assuming you have the ability to animate different parts independantly.
that said, they're too unreliable without csqc.
most skeletal formats revive the idea.

on the other hand, skingroups can generally be better served by a shader (with sawtooth fading or whatever to smooth it out).

i knew glquake broke a lot of the animated skingroup feature, (i.e. forcing it to be either 1, 2, or 4 frames) but I didn't know about the timing bug -- is this the bug that causes it to animate at 20Hz instead of 10?

(I used this for the landing beacon in rub2m2, and I had to duplicate frames -- 2 on, 2 off -- so that it would blink at 10Hz to match my lightstyle. If that is actually a bug, I guess that means my beacon will blink too slowly in any fixed engine.)

(update: just tested in winquake, the timing appears to be the same there. Now i'm confused... why is it 20Hz?)

skingroups and framegroups animate at per-frame intervals. except in glquake where it uses only the first frame's interval for all frames. that is, (win)quake can have different durations for each individual frame/skin. Generally though, you'd be crazy to use different intervals for different frames.
no idea where you're getting the 20hz from, but that is specified in the model, and I know of no engine bugs that would trigger it. Check whichever tool you're using to generate your model I guess.

Just checked the vanilla source; it's definitely 10hz in GLQuake:

  Code:

anim = (int)(cl.time*10) & 3;

WinQuake is based on cl.time + currententity->syncbase, with the actual skin coming from a nasty lookup on the intervals table, so if that contains a 20hz interval then it would give 20.

This opens an interesting question. There are other cases where content is designed for the (incorrect) way GLQuake handles things - I'm thinking fullbrights and overbrights here. Should the same Dilbert-esque "put the bugs back in" principle apply, or be given as an option, here too?

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)

i'm more confused now... so first of all, in my memory, I had to have 2 frames on, 2 frames off in a skin animation, to get the same rate of blinking that 1 frame on, 1 frame off achieved in a bsp texture animation.

Just checked the source and everything seems to be based on (int)(cl.time*10), so i don't know why it would be different for bsp textures vs. skins vs. lightstyles.

Also, I looked at my quakec and this is my lightstyle that matches the skin animation:

  Code:

lightstyle(16, "mmaammaammaammaa");

So, it appears that everything is doubled except for the bsp textures.

/me does some digging....

Okay, this might be the answer. In Mod_LoadTextures(), there is code to sequence the animated bsp textures, starting with this #define:

  Code:

#define ANIM_CYCLE   2

I think if that were set to 1, we would have 10Hz bsp texture anims. With it set to 2, we get 5Hz anims. As a side note, it appears that quake engine code is completely capable of having variable-length frames for bsp texture animation, though the data has no way to specify it.

GLQuake with skingroups always assumes that there are 4 skins in the group - if there are less than 4 it fills in the missing skins from those that are already there. So, hypothetically, if ypu have 2 skins in a group it will animate the sequence 0|1|0|1. So far as I can see that should still give you 10hz animation, but I haven't done any testing at all so I might be talking bollocks.

This discussion has been great, by the way. It's motivated me to fix up my own handling of groups, and I've got this nice little helper function that works with MDL framegroups, MDL skin groups and SPR framegroups:

  Code:

int Mod_AnimateGroup (entity_t *ent, float *intervals, int numintervals)
{
   if (!ent) return 0;
   if (!intervals) return 0;
   if (!numintervals) return 0;

   float time = cl.time + ent->syncbase;
   float fullinterval = intervals[numintervals - 1];
   float targettime = time - ((int) (time / fullinterval)) * fullinterval;

   for (int i = 0; i < numintervals - 1; i++)
      if (intervals[i] > targettime)
         return i;

   // default is the last animation interval (consistency with software Quake)
   return numintervals - 1;
}

There's a small bit of special-case handling needs to be done with MDL frame groups:

  Code:

      int addpose = Mod_AnimateGroup (ent, frame->intervals, frame->numposes);

      if (addpose > 0)
         frame_interval = frame->intervals[addpose] - frame->intervals[addpose - 1];
      else frame_interval = frame->intervals[0];

      // go to the new pose
      posenum += addpose;

Otherwise it's quite cool and works well.

Yeah, i think there is no actual bug; the answer is that lightstyles and skingroups animate at 10Hz, and bsp textures animate at 5Hz, and none of this is a bug, but it confused me for a bit. (since i assumed bsp was 10Hz, I assumed everything else must be wrong somehow.)

lightstyles and skingroups animate at 10Hz, and bsp textures animate at 5Hz

:O
And suddenly, something so obvious just become, well, obvious to me. Just took me like, 15 years, to realize it. D'oh!
Thank you, metlslime, for showing me the obvious.

10hz for BSP textures, surely?

  Code:

reletive = (int)(cl.time*10) % base->anim_total;

10hz for BSP textures, surely?

  Code:

reletive = (int)(cl.time*10) % base->anim_total;

TBH I'm confused now. I know you're right (and I already saw this code snippet before) but there are some animated textures that don't, well, feel like 10Hz animations (the red hot grates on the slipgates comes to mind as an example). But probably it's just a subjective effect.

for BSP textures, its 5hz.

Yes, the code uses time*10 for 10hz, but it also counts each frame twice with the ANIM_CYCLE thing. each frame is basically duplicated. hence 10/2=5.

Yuck - you're right.

It seems hideous, but the code took extra pains to make it different. Is there some non-obvious benefit? Maybe something in qtest needed it?