Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Nasty interpolation bug - and fix!

| Inside3d Forums Forum Index -> Programming Tutorials

View previous topic :: View next topic
Author | Message
--- | ---
mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Mon Jan 12, 2009 1:28 am Post subject: Nasty interpolation bug - and fix! |

I suppose most people have implemented some variant on the old QER interpolation tutorials, but there is an incredibly nasty bug in them which you won't really notice owing to the way Quake handles memory. The cause of this is the fact that Quake reuses entities; so if you gib a zombie, it will reuse the zombie entity but switch it's model to h_zombie. Of course, the old interpolation data for the zombie will reference pose numbers that the h_zombie model doesn't have, and so you'll have a stray pointer for a period of one frame until things settle back down. As Quake's memory is one big contiguous block, this won't matter too much - you'll just have some invalid data in there for that one frame (unless you're really tight on memory), but if you do any work on changing the memory system (such as to full dynamic with no limits) you'll begin to be bitten.
The fix is really simple, just find the CL_ParseUpdate function (in cl_parse.c), and look for the block starting "if (model != ent->model)". You'll want to add this code somewhere in the block:

Code:
// if the model has changed we must also reset the interpolation data // pose1 and pose2 are critical as they might be pointing to invalid frames in the new model!!! ent->frame_start_time = 0; ent->frame_interval = 0; ent->pose1 = ent->pose2 = 0;
ent->translate_start_time = 0;
ent->origin1[0] = ent->origin1[1] = ent->origin1[2] = 0;
ent->origin2[0] = ent->origin2[1] = ent->origin2[2] = 0;
ent->rotate_start_time = 0;
ent->angles1[0] = ent->angles1[1] = ent->angles1[2] = 0;
ent->angles2[0] = ent->angles2[1] = ent->angles2[2] = 0;

That's about it; I'm not certain if all of these are needed, but when switching models it's probably better to start with a totally clean slate.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

MeTcHsteekle Joined: 15 May 2008 Posts: 397 Location: its a secret |

Posted: Mon Jan 12, 2009 1:38 am Post subject: |

ugh i got to get back to engine exparaments soon again, the last time i used pheniox's interpolation tutorial it had this strange effect with the between map shots [the part that shows you the kills secrets time], it had this kind of cutting off stuf, like some parts of the level wee fine, but most of it was clipping and all the entityes [like dead stuff] wasent showing :S i dont know what i did.
but right now im working onsome kind of a mod [got some weapons in, and the nailgrunt [separate from solder.qc, has a nailgrunt.qc and i got it on a map along with quakeguy and the quakeguy.qc]
_________________
bah

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Mon Jan 12, 2009 1:50 am Post subject: |

Yeah, there's lots of things wrong with that code. It was great for it's time, and a massive step above what vanilla Q1 did, but it still needs a good thorough working over; it's over 8 years old, after all. Bugs come out in the field. The positional interpolation should be in CL_RelinkEntities rather than in R_RotateForEntity for starters; just so much cleaner and less hacking around special situations required.
Animation interpolation is probably better calculated at load time (especially now that memory is no longer a pressure); expand the verts x3 or x4 and fill in the interpolated verts.
Muzzleflashes.
And this bug, of course...
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Dr. Shadowborg Inside3D Staff Joined: 16 Oct 2004 Posts: 726 |

Posted: Mon Jan 12, 2009 4:40 pm Post subject: |

mh wrote:
Muzzleflashes.

Don't forget the problem that chaingun / miniguns have too, given that they rotate...
Another annoyance I've noticed is that when switching weapon models, a lot of engines with interpolation have an annoying tendancy to display the first frame of a model before switching to whatever frame it was on the previous model. (hence destroying the effect of doing quake2 style weapon changes. i.e. weapon gets putaway down, new weapon gets pulled out and up.)
Too bad there isn't some script system where you could like, tell quake the name of the model, then give it a list of frame ranges / frames where it's not allowed to interpolate.
_________________
"Roboto suggests Plasma Bazooka."

Back to top |

MeTcHsteekle Joined: 15 May 2008 Posts: 397 Location: its a secret |

Posted: Mon Jan 12, 2009 6:01 pm Post subject: |

ive seen the model morph quicky in tothe next also _________________ bah

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Tue Jan 13, 2009 6:20 am Post subject: |

Also I have noticed that large angle changes that are interpolated create a noticeable spin especially when I respawn, or go into observer mode. So, i've added this... in GL_RMAIN.C in R_RotateForEntity

Code:
// always interpolate along the shortest path //R00k: don't interpolate angles > 90??? if (VectorLength(d)< 90) { for (i=0 ; i<3 ; i++)
{
if (d[i] > 180)
d[i] -= 360;
else if (d[i] < -180)
d[i] += 360;
}
glRotatef (ent->angles1[1] + (lerpfrac * d[1]), 0, 0, 1);
if (!shadow)
{
glRotatef (-ent->angles1[0] + (-lerpfrac * d[0]), 0, 1, 0);
glRotatef (ent->angles1[2] + (lerpfrac * d[2]), 1, 0, 0);
}
}
else
VectorCopy (ent->angles2, ent->angles1);

Back to top |

dreadlorde Joined: 24 Nov 2009 Posts: 86 |

Posted: Mon Mar 01, 2010 12:04 am Post subject: |

I seem a bit late to the thread but I have question about the interpolation tutorials mh was talking about: are they available anywhere? _________________

Ken Thompson wrote:
One of my most productive days was throwing away 1000 lines of code.

Get off my lawn!

Back to top |

reckless Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger |

Posted: Mon Mar 01, 2010 3:14 am Post subject: |

not sure if the site is still up but google for phoenix quake.

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Wed Jun 23, 2010 9:56 am Post subject: |

dreadlorde wrote:
I seem a bit late to the thread but I have question about the interpolation tutorials mh was talking about: are they available anywhere?

Late but ...
http://quakewiki.net/archives/qer/tutorials/tutorial1.html
Lately I've been thinking about interpolation and software renderers. I've looked through the ToChris engine source code (available @ quaddicted.com/engines ) and the software renderer is heavily rewritten.
I am certain I ran across a conservative engine partial interpolation like aguirRe WinQuake or JoeQuake's WinQuake renderer, but at the moment I can't seem to locate it. I think it was motion interpolation only.
I'll probably continue to examine the ToChris engine and see if I can isolate the interpolation. That plus skybox support are things that interest me quite a bit.
At least in my head, it doesn't seem like interpolation in a software renderer should be any harder than in OpenGL ... but maybe I'm just oversimplifying MH's commentary (with Metlslime ?) about alternate interpolation ideas.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Wed Jun 23, 2010 10:31 am Post subject: |

I've done frame interpolation in software Quake but haven't released the code. If memory serves all of the changes are confined to one d_ file, and you have to switch a small bit of asm to C. I'll dig it out this evening. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Wed Jun 23, 2010 11:32 am Post subject: |

FTE had interpolation in its software renderer. The biggest pain is probably the assembler. Which is hand optimised, and unreadable, not only because it uses the x87 in more than a few places, but yeah, the asm functions can be replaced with their C equivelents.
The engine actually has two methods of drawing models (hence why software rendering was prefered over gl rendering for some time - bigger players, I think). You probably don't actually need to interpolate all paths.
One obscure thing to ensure is correct is bbox aproximations. If the model is completely on-screen, frustum checks are ignored. This means that if your bbox is a single frame and not the max size, you can get obscure crashes when the assumed bbox size is smaller than the actual size with it interpolating near the edge of the screen. Off by 1 pixel = crash.
Tbh, I don't really remember much more.
Hurrah for mh.
_________________
What's a signature?

Back to top |

reckless Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger |

Posted: Wed Jun 23, 2010 4:59 pm Post subject: |

i think joequake also had it not sure though... might be closer to standard quake.

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Wed Jun 23, 2010 5:27 pm Post subject: |

Never doing a trivial_accept is enough for the bbox thing. Anyway, I've found the code! It's actually mostly r_alias.c, but the changes in there were quite extensive, so a tutorial would just consist of "replace this line with that line" over and over again for quite a bit. I'm going to just do a QuakeTastic upload of the full r_alias.c together with a few implementation notes; if anyone's interested in dissecting the changes further they can grab their favourite diff tool and work on it with that.
OK, here we go: Software Quake Frame Interpolation
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Programming Tutorials | All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group