Additional animation for player models

[JasonX]

[Handshakes]

[necros]

[JasonX]

[leileilol]

Half-Life pulled it off with skeletal blending and bone controllers. It had one walking animation and one running animation. Bone controllers turned the skeleton appropriately.

We don't have this equivelant in Quake yet since a 1997 standard since Jedi Knight is WAY too new.

[frag.machine]

[necros]

it might be possible if you wanted to try something similar to the q3 approach. q3 used 3 separate models for all characters, legs, torso and head and kept each component glued to the other via a specially marked triangle called the tag on each of the other components.

of course, even that will not be quite the same as quake doesn't have tag points like q3 does. either you would have to animate each component so that it always looked correct when a zero'd offset relative to the origin of the main model, or you'd have to hard code position offsets for each frame which would be insane.

one thing you could add is the variable speed walk/run animation like in half life. that's to say, if you were walking into a wall and sliding along it slowly, your running animation would play slower than if you were just running straight ahead.

be wary though because this method can mess up frame interpolation in some engines like fitzquake that use .nextthink to determine how fast/slow to interpolate.

if you look at the stock run frame functions for the player, you'll realize that they always run at 0.1 second intervals (the frame macro sets that automatically).
while setting nextthink to higher or lower settings would in theory make the player run faster or slower, this isn't ideal because there are important checks that have to be made in that function that might be delayed too long if you are running slowly.
so we instead go the opposite direction.
we set self.nextthink = time;.
this will make the frame function run every game frame. (you can scale it back to maybe time + 0.02 or 0.04 if you want to increase performance, but honestly, any modern machine should handle it no problem)

next we have to create two new float .variables.
.frameCountGoal and .frameCount.
we're basically creating a proxy instead of incrementing self.walkframe.

.frameCount will increase by 1 modified by frametime every time the function is called, much like .frame was originally.
.frameCountGoal will be dynamically calculated based on movement speed.

finally, we move the self.walkframe = self.walkframe + 1 inside an if statement that checks when self.frameCount > self.frameCountGoal.

it might be wise to create two running animations if you go this route: one full tilt sprinting run and a more jogging run so you can switch from one to the other based on speed (you'll look stupid if you're jogging at light speed or sprinting like molasses). if you make the two animations have the same number of frames, you can even switch between the two preserving relative frames so that you don't always start each animation on the first frame making it look more natural.[/i]

[JasonX]

Q3 uses three different body parts and the engine rotates those. It's very smooth, but a pain to model for and, in my opinion, ugly.

[JasonX]