Mod_LoadAllSkins - Bug Fix

Post tutorials on how to do certain tasks within game or engine code here.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Mod_LoadAllSkins - Bug Fix

Post by Spike »

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).
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Re: Mod_LoadAllSkins - Bug Fix

Post by metlslime »

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?)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Mod_LoadAllSkins - Bug Fix

Post by Spike »

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.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Mod_LoadAllSkins - Bug Fix

Post by mh »

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

Code: Select all

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?
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Mod_LoadAllSkins - Bug Fix

Post by taniwha »

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)
Leave others their otherness.
http://quakeforge.net/
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Re: Mod_LoadAllSkins - Bug Fix

Post by metlslime »

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: Select all

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: Select all

#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.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Mod_LoadAllSkins - Bug Fix

Post by mh »

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: Select all

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: Select all

		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.
Last edited by mh on Sat Jun 09, 2012 12:08 am, edited 3 times in total.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Re: Mod_LoadAllSkins - Bug Fix

Post by metlslime »

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.)
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Mod_LoadAllSkins - Bug Fix

Post by frag.machine »

metlslime wrote: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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Mod_LoadAllSkins - Bug Fix

Post by mh »

10hz for BSP textures, surely?

Code: Select all

reletive = (int)(cl.time*10) % base->anim_total;
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Mod_LoadAllSkins - Bug Fix

Post by frag.machine »

mh wrote:10hz for BSP textures, surely?

Code: Select all

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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Mod_LoadAllSkins - Bug Fix

Post by Spike »

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.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Mod_LoadAllSkins - Bug Fix

Post by mh »

Yuck - you're right. :evil:
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: Mod_LoadAllSkins - Bug Fix

Post by qbism »

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?
Post Reply