Admittedly when I managed to get different rate framegroups to work I was using darkplaces, so it's possible that regular engines have no support for it and darkplaces had slightly broken support for it, I will go away and check this weekend(hopefully).

As for the 10Hz thing, it isn't hardwired into quake that things animate at that speed, but there are 4 reasons why it is almost exclusively used.


1: It's the rate at which all the existing quake models are animated. So anything new usually follows that pattern.


2: The QC shorthand way to define animation functions in quake like

void() ogre_stand6 =[ $stand6, ogre_stand7 ] {ai_stand();};

implicitly assume a 10Hz rate, they insert a self.nextthink = time + 0.1; at the start of the function. You could change that in the function body:

void() ogre_stand6 =[ $stand6, ogre_stand7 ] {ai_stand();self.nextthink = time + 0.05;};

but it's awkward, and also the original nextthink remains before it.
(I think a nice fix would be a way to specify $fps in the $frame macros, and then have the compiler insert the correct nextthink time when expanding animation functions. But I've barely managed to get FTEQCC to compile, so it may never happen.)


3. It is the framerate which the game will guarantee - if the game is being so slow that it can't achieve 10 fps then it will slow down game time. You might set thinks every 0.05 seconds and have them still occur every 0.1 second in game. Of course, in the real world quake is 10 years old and so never runs slow, but it's a nice theoretical.


4. The other limits of the mdl format start to show once you start animating at higher framerates. 256 frames only gives you 12 seconds of animation at 20fps, and you have to cram all of a monster's death/pain/attacks into that length of time. Often doable, but pretty tight. Also, the compression of the vertex coordinates means you get rapidly diminishing returns on increasing the framerate. The result wobbles might be worse than keeping 10fps and letting the engine interpolate at higher precision.


I don't think any of those things is enough to completely kill working at higher framerates though. What I'd like to see is some specified use of it. Keep 10 fps on unimportant/low motion animations like idle poses. But when you have a big sweeping motion like a sword slashing, increase the framerate for that to 20. This gets around both of the problems of point 4 there.

If you do run into problems where you have too many frames to increase the framerate, it may be possible to abuse framegroups to provide the interpolation you need. This does rely on two things - that you can set custom framegroup fps, and that when you enter a non-random framegroup from a different frame, it starts animating from the beginning. 

OK, so in further poking around am I right to assume that an MDL will either be using simple frames OR group frames? There's no mix and match going on, correct? 

You can in fact have both in the same model, it is possible to combine the zombie crucifiction frames into one framegroup and make crucified zombies static(but then you don't get the random duration of frames or the sounds, so it's not a PRO TIP or anything). Doing that doesn't affect the rest of the frames in the model, so regular zombies work as normal.

Also, changing the rate is inconsistant: in glquake engines the duration is taken from the first frame, in winquake it reads each frame duration correctly. There's an argument there that the bug should be fixed in glquake engines there, but best practice is probably to use the same rate for the entire framegroup, and set it in each frame so that winquake handles it the smae.

The bad news is that when rendering a framegroup which isn't random, the frame to render is just calculated from the world clock, rather than the time since that framegroup was set (That is assuming I've read the relevant code correctly). This means you can't abuse framegroups to provide increased interpolation with the same number of frames on the QC side. 

Ahh OK. Well, good to know then. i'll need to handle it all gracefully then, no shortcuts. :) Thanks... 

When I tried to combine the skull of Lostsoul with the flame2.mdl I was overtaken by the fact that Quark407 in model import reakts:
can't handle framegroups.

Is there a way to break this options so I can manipulate the modelframes? 

open flame2.mdl in qme, remove frame groups, save, open in quark. 

framegroups, does this mean
the parts of vertices within a frame like the different flame parts,
or different frames?

The only way to avoid this "no framegroups supported" for me is by exporting a flame2.dxf and import it back as a new model. Then I can reimport the multiple frames, and quark can import it. 

Frame groups, as I've come to learn over the weekend, are basically a collection of frames that are special in that they will animate autonomously without having to tell the server about it. Each frame is a complete animation frame, just like the simple frames in other models. 

the different parts in one frame make quark tell it is a framegroup.

I know nothing about servers and how it works in quake.I just wondered why one frame left in qmle after deleting all other frames in flame2.mdl still errored quark with framegroups.

It is the same error I had after decomposing a death frame to divided parts. After saving they were all melted together again. 

It looks like MDLs have support for animated skins but no MDL that I ever open has one. Can anyone recall a model that had an animated skin on it in a mod or anywhere else? 

but i believe you are refering to skingroups?

i've heard people talk about that but never found out how to do it, myself. 

Sorry, yes, skin groups. I see them in the spec and was just wondering if they've ever actually been used. I guess once these tools are further along I'll just test them out and see what they are. 

on Nehahra? They have like facial animation as in the mouth texture has two frames. Also isn't there some blinking? 

Well, how are these skingroups used? I'm going to assume that it's like the frame groups - some sort of automated animation system. If that's the case, I guess they could have had a moving mouth with blinking thrown in here and there to make it work (no lip syncing at all but that's probably a given in the Quake engine). 

i believe the talking and blinking (not sure about the blinking, that may have just been random?) was handled via impulse commands and that the 'actor' players would do that themselves. or it just occured to me, they maybe did it in post in a demo editor. 

just to clarify, do you mean something like painskins (sweeeet)?

http://www.inside3d.com/showtutorial.php?id=95

Or, an animated concurrent effect? 

i managed to do that once when i was about 15.

Bring back painskins! 

HT

No, that tutorial looks like it's just bumping up to another skin index. The skingroup stuff looks like an auto animate deal.

Preach! :) 

You can auto animate skins, it's pretty much the same deal as the frames, you can designate a collection of skins as a single skingroup, they autoanimate according to timings set in the model. I have no idea if the random flag works on them, or if the same glquake bug for duration exists. If you want an example of a model which does it, dig in the quoth pak1.pak for a model called pickup.mdl. The last two skins, which are for the health and megahealth, have such animations to make the lights blink.

Necros: how you do it in qme is arrange the skins in order, then right click on the first one and select "Append Skingroup To Previous Skingroup". Repeat until all the skins in the animation are combined, and then save the model again. 

i'm pretty sure these are the analog to framegroups in models and sprites, basically client-side looped animation.

based on the engine code, it looks like glquake has pretty half-assed support for skin groups, for example every skin is given 4 pointers to textures, and almost all the time the 4 pointers are to the same texture, but when loading a skingroup it gives them unique pointers. If you have more than 4 skinframes, it drop some.

So effectively you can only have 1, 2, or 4 skinframes in a group in glquake. If you have 3, it will animate 1, 2, 3, 1, 1, 2, 3, 1... and if you have 5+, it will animate (e.g.) 5, 2, 3, 4, 5, 2, 3, 4...

Also, not sure if the model format supports intervals for skingroups, but glquake clearly only does 10Hz animation for them.

My guess is there's one model somewhere in the mission packs using this feature, and that required them to add this minimum of support to glquake when they wrote it. 

Christ metlslime, pull the curtain back again, that's hideous!

Informative though, cheers really. 

Haha, horrible! Well, good to know that supporting that can go at the bottom of the priority list at least. :P 

Blinking health items at least.

Possibly some really shitty animated soul sphere swirling is possible . . . in four frames.

Can't think of a decent monster application - glowing eyes? 

"Blinking health items at least. "

Huh, that's true. OK, I guess that'll be my test case for loading skin groups then. 

"Can't think of a decent monster application - glowing eyes?"

I think many cool ideas could be done there. Glowing demon eyes, blinking lights on enforcer armor, blinking eyes, etc. Could be neat.