Suggestions for performance upgrades to the Makaqu codebase

[Sajt]

I can't remember all the improvements at the moment, but one of them is certainly the timed framegroups. Most Quake engines with interpolation doesn't interpolate framegroups correctly.

This should probably be a cvar, because some mods might have garbage in the MDLs and rely on it not actually being used by most engines... (Well, I don't know of any such mod, but you never know)

[mh]

I can't remember all the improvements at the moment, but one of them is certainly the timed framegroups. Most Quake engines with interpolation doesn't interpolate framegroups correctly.

This should probably be a cvar, because some mods might have garbage in the MDLs and rely on it not actually being used by most engines... (Well, I don't know of any such mod, but you never know)

GLQuake doesn't time them properly either, so it seems reasonably safe to assume that anything made since about 1996/1997 is based on the assumption that the engine it's used in will behave the same as GLQuake.

[Spike]

does anyone (other than nexuiz, which uses a different format entirely) actually use framegroups?
static flame models, which use a single framegroup per instance... yup, that's pretty much it, and those generally don't look any better with interpolation. :P

[leileilol]

OpenQuartz had framegroups for their terrible weapon idle animations

I use framegroups and skingroups on weapons sometimes, to variate muzzleflash shapes or to make charge throbs

What's really left out in the support rain, is framegroups on sprites.

[mh]

Framegroups are a horrible horrible idea that only complicate the MDL format. The basic reasoning behind them is fine (client-side animations to save on bandwidth) but framegroups are not actually needed at all for it - the whole thing could have been done with regular frames just as easily.

[frag.machine]

does anyone (other than nexuiz, which uses a different format entirely) actually use framegroups?
static flame models, which use a single framegroup per instance... yup, that's pretty much it, and those generally don't look any better with interpolation.

NPC models in Prydon Gate. And, IIRC, rogue uses skins groups, too.
But I gladly would ditch it entirely if someone come with a better idea for client-side animations.

[leileilol]

I wouldn't ditch it. I like the system. What's wrong with it? Is it because you can't really specify exact frames in sv qc? That's the whole point.

Darkplaces has a .framegroups file for non-MDL formats.

[mh]

It's just ugly and it complicates something that needn't be complicated. Plus it's completely unnecessary; all that needs to be done is to adjust the protocol so that a makestatic also specifies start and end frames for auto-animation (and optionally intervals), and then you can do auto-animation without framegroups.

On the other hand it is a legacy format that does need to be supported, but with a clean sheet of paper design removing framegroups would be the first thing to be changed in the MDL format (removing skingroups would be the second).

But like I sometimes say: think about what you want to achieve rather than how you want to achieve it. Is the objective here to get "effect X" working, or is the objective to use framegroups?

[Spike]

darkplaces starts animating framegroups based on receival time. other engines just animate based on map start time.

framegroups are actually kinda useful with lots of frames, as it means you can blend one animation into another without suddenly changing the entire animation.
thus with csqc controling the animation start times (actually, the time into the animation), framegroups can be used as entire animations with easy blending from one to another, and they rock.
but without csqc, they're just goofy and not worth the effort, tbh. they work for otherwise static objects, but that's it.

note that you can animate a player running forwards by increasing the framegroup's time by distancetraveled/animationspeed each frame to get an animated model who's feet don't slide, if you then blend that animation into other animations based on the direction of motion, and split by bone, then framegroups are godly. But only really for skeletal models with some proper animation code (read: csqc).

[mankrip]

it seems reasonably safe to assume that anything made since about 1996/1997 is based on the assumption that the engine it's used in will behave the same as GLQuake.

GLQuake is broken in many aspects, and I think it would be a mistake to break existing functional features of WinQuake to match it.

GLQuake set the standard for translucent water, bilinear texture filtering, and that's about it. Its mirrors and shadows never became popular due to being heavily bugged.

Well, I'm actually working on dynamic colormap generation right now, which will allow for redefining and switching fullbright colors on and off in runtime, but that'll be just an extra feature; the point is actually to eliminate the need for mod authors to generate colormaps from their custom palettes on their own, and to reduce initial loading times from the disk. Fullbright colors will still be on by default.

What's really left out in the support rain, is framegroups on sprites.

I remember reading something about the lack of framegroup support on sprites; thanks for the reminder, I'll check it.

[frag.machine]

I wouldn't ditch it. I like the system. What's wrong with it? Is it because you can't really specify exact frames in sv qc? That's the whole point.

Darkplaces has a .framegroups file for non-MDL formats.

Because it's hardwired and broken, for a start ? You need to limit the use basically to sequential animations with fixed intervals (IIRC the individual intervals values provided in the .mdl format are ignored in GLQuake, as the random frame flag). I'd rather prefer to have the ability to define the sequences (down to individual frames, not only first/last) and their intervals in a config file, at client side.

[Sajt]

I can't remember all the improvements at the moment, but one of them is certainly the timed framegroups. Most Quake engines with interpolation doesn't interpolate framegroups correctly.

This should probably be a cvar, because some mods might have garbage in the MDLs and rely on it not actually being used by most engines... (Well, I don't know of any such mod, but you never know)

GLQuake doesn't time them properly either, so it seems reasonably safe to assume that anything made since about 1996/1997 is based on the assumption that the engine it's used in will behave the same as GLQuake.

You mean software Quake did time them "properly"?

By the way, I don't know if DarkPlaces looks at the time value for every frame, I think it just takes the first one and uses that for the whole framegroup. Because the way they are stored in the file is retarded (they are cumulative, like 0.0, 0.1, 0.2, 0.3, 0.4), so you can never really know how long the last frame is supposed to last.

[mh]

I can't remember all the improvements at the moment, but one of them is certainly the timed framegroups. Most Quake engines with interpolation doesn't interpolate framegroups correctly.

This should probably be a cvar, because some mods might have garbage in the MDLs and rely on it not actually being used by most engines... (Well, I don't know of any such mod, but you never know)

GLQuake doesn't time them properly either, so it seems reasonably safe to assume that anything made since about 1996/1997 is based on the assumption that the engine it's used in will behave the same as GLQuake.

You mean software Quake did time them "properly"?

By the way, I don't know if DarkPlaces looks at the time value for every frame, I think it just takes the first one and uses that for the whole framegroup. Because the way they are stored in the file is retarded (they are cumulative, like 0.0, 0.1, 0.2, 0.3, 0.4), so you can never really know how long the last frame is supposed to last.

I believe from my reading of r_alias.c that the interval times are actually supposed to represent the time at which the frame ends rather than at which it starts, which would make more sense.

So software Quake yould get the full duration of the group:

Code: Select all

fullinterval = pintervals[numframes-1];

Then derive the target time we're aiming for:

Code: Select all

targettime = time - ((int)(time / fullinterval)) * fullinterval;

Then check the individual intervals to see which frame to use:

Code: Select all

for (i=0 ; i<(numframes-1) ; i++)
{
   if (pintervals[i] > targettime)
      break;
}

Note the use of > and not >= in that last snippet.