Re: [hlcoders] laggy animations
-- [ Picked text/plain from multipart/alternative ] Thank you so much for that explanation Paul. Our team of two programmers (myself and another person) have been digesting what you've been saying to try and crack at the problem. I've been actually trying to fix m_flCycle in c_baseanimating all night last night, but now I realize that's probably not where the source of the problem is, according to your description. Yes. Indeed we are doing multiplayer, and we have plenty of gestures, so this is a must-fix. Thankfully, not a complete show-stopper since the last patch. Can you please give an example of what the prediction code looks like (a line or two would do it)? I'm still only a month and a half into studying the source engine code. I'm guessing it probably looks like: BEGIN_PREDICTION_DATA( C_HL2MP_Player ) END_PREDICTION_DATA() and probably using some macro that I haven't found yet. >>This is essentially what I said in the VERC forum but hopefully this summary >>will help you understand better. Definitely. Thanks again. I'll post another email on the status of this once we've exhausted trying everything you've mentioned. >>I noticed in a few places that it sets the player's pitch the same as >>eyeangles using SetLocalAngles, and then changes it back. Is there any real >>reason for this, ever? I've noticed that this causes a back and forth stuttering. Commenting it out will resolve the problem, but I'm not 100% sure if that's the right way to fix it. For everyone having third-person animation issues (specifically HL2DM), our team has gathered a wiki page dedicated to fixing it. It can be found at: http://berimbau.pbwiki.com/Fix%20third-person%20client-side%20animation -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] laggy animations
I work with mike. I'm a bit confused with CMoveHelperClient::PlayerSetAnimation part. I'm not sure how to add that support. In c_baseplaer.cpp there's a SetAnimation function with the FIXME comment there. Is this what I should fix or should I focus on that method? I'm a bit confused on On 8/14/06, Paul Peloski <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Hi Mike, Unfortunately since you are doing multiplayer (you said "HL2DM game") you are probably using prediction for players with latency, so, you have to predict the animation sequences of the local player if you want to show them (third person.) You need to preidct the stuff that SetAnimation does on the server. First thing to do would be to make SetAnimation a shared function so that client and server are using the same logic to set player sequences. Once you have that, you just need to make sure that the client is calling SetAnimation in CMoveHelperClient::PlayerSetAnimation and in C_BasePlayer::PostThink to mimic what the server does. Then, you need to fix m_flCycle for the local player since if it comes down from the server it will mess up what the client's SetAnimation is doing, so copy what Valve has done in C_BaseCombatWeapon::Interpolate, which is making m_flCycle cycle properly independent of the server. This is still not complete, because you will notice that C_BaseAnimatingOverlay does not have the same methods available on the client as the server, so if you want to use gestures / layered animation you will need to make a version of C_BaseAnimatingOverlay that will work on the client. It should be a matter of adding the code necessary to make RestartGesture() work on the client. This is used for playing gestures like attacks and signals, if your custom player model doesnt have any gestures you may not need to do this. Another thing is to check into CPlayerAnimState, which Garry already mentioned does some funny stuff that can muck up your animation and positioning (ie, calling SetLocalAngles when the function is called ComputePoseParam_BodyYaw?!) If you just wanted a single player, it would just be a matter of tracking down the source of the jitter and fixing it, but for multiplayer you will definately want to predict the animations, since even if you smooth out the jitter completely, you will still notice that the animations lag behind what the local player is actually doing, since his movements are predicted but his animation has to come down from the server. This is essentially what I said in the VERC forum but hopefully this summary will help you understand better. Paul On 8/14/06, Michael Chang <[EMAIL PROTECTED]> wrote: > Yeah. I've been a long-time participant in that thread. If you look at the > latest posts, there is still no proper solution. > > I don't think this is directly related to third-person, simply a bug in > client-side animation. > > Please help. Thanks! > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Sean Bryant ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] laggy animations
-- [ Picked text/plain from multipart/alternative ] Hi Mike, Unfortunately since you are doing multiplayer (you said "HL2DM game") you are probably using prediction for players with latency, so, you have to predict the animation sequences of the local player if you want to show them (third person.) You need to preidct the stuff that SetAnimation does on the server. First thing to do would be to make SetAnimation a shared function so that client and server are using the same logic to set player sequences. Once you have that, you just need to make sure that the client is calling SetAnimation in CMoveHelperClient::PlayerSetAnimation and in C_BasePlayer::PostThink to mimic what the server does. Then, you need to fix m_flCycle for the local player since if it comes down from the server it will mess up what the client's SetAnimation is doing, so copy what Valve has done in C_BaseCombatWeapon::Interpolate, which is making m_flCycle cycle properly independent of the server. This is still not complete, because you will notice that C_BaseAnimatingOverlay does not have the same methods available on the client as the server, so if you want to use gestures / layered animation you will need to make a version of C_BaseAnimatingOverlay that will work on the client. It should be a matter of adding the code necessary to make RestartGesture() work on the client. This is used for playing gestures like attacks and signals, if your custom player model doesnt have any gestures you may not need to do this. Another thing is to check into CPlayerAnimState, which Garry already mentioned does some funny stuff that can muck up your animation and positioning (ie, calling SetLocalAngles when the function is called ComputePoseParam_BodyYaw?!) If you just wanted a single player, it would just be a matter of tracking down the source of the jitter and fixing it, but for multiplayer you will definately want to predict the animations, since even if you smooth out the jitter completely, you will still notice that the animations lag behind what the local player is actually doing, since his movements are predicted but his animation has to come down from the server. This is essentially what I said in the VERC forum but hopefully this summary will help you understand better. Paul On 8/14/06, Michael Chang <[EMAIL PROTECTED]> wrote: > Yeah. I've been a long-time participant in that thread. If you look at the > latest posts, there is still no proper solution. > > I don't think this is directly related to third-person, simply a bug in > client-side animation. > > Please help. Thanks! > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] laggy animations
-- [ Picked text/plain from multipart/alternative ] Yeah. I've been a long-time participant in that thread. If you look at the latest posts, there is still no proper solution. I don't think this is directly related to third-person, simply a bug in client-side animation. Please help. Thanks! >>Checkout >> http://www.chatbear.com/board.plm?a=viewthread&t=826,1113377026,18039&id=835790&b=4991&v=flatold -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] laggy animations
--
[ Picked text/plain from multipart/alternative ]
I noticed in a few places that it sets the player's pitch the same as
eyeangles using SetLocalAngles, and then changes it back. Is there any real
reason for this, ever?
On 8/14/06, Skillet <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Apparently that fix is unrelated to third person local player
> animations. I
> also implemented it and saw that the local player crowbar animation still
> seemed low framerate. It's not a showstopper, luckily.
>
> None of the fixes in that SDK forum thread address the problem IIRC.
>
> Did you ever run into player model pitch problems in third person? That's
> my last big problem remaining with it (besides this animation issue). The
> pitch pose parameter works great until the player fires a weapon, then for
> a
> moment the pose parameter stops being used and it does absolute pitching
> (based on view angles). This causes a choppy effect where you can see a
> double image of the player model, one using the pose parameter (just the
> head/upper body tilted, as it should be) and one using absolute pitch (the
> entire model tilted forward or backwards). Goes away with cl_predict set
> to
> 0.
>
> I haven't looked at it too in depth, so it may be a simple misplaced call
> to
> SetLocalAngles or something.
>
> On 8/14/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote:
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Checkout
> >
> >
> http://www.chatbear.com/board.plm?a=viewthread&t=826,1113377026,18039&id=835790&b=4991&v=flatold
> >
> > On 8/14/06, Michael Chang <[EMAIL PROTECTED]> wrote:
> > >
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Hello guys, my first time posting to this list. Please bear with me.
> > >
> > > This is directly related to something Paul Peloski mentioned earlier,
> > with
> > > removing.
> > > >> > if ( !IsSelfAnimating() )
> > > >> > {
> > > >> >m_flAnimTime = engine->GetLastTimeStamp();
> > > >> > }
> > >
> > > I am trying to implement a bug-free third person HL2DM game. I've been
> > > doing
> > > so for the past month and a half.
> > >
> > > I've implemented the above, but the upper body animations still seem
> to
> > be
> > > laggy / jerky / low framerate. (as seen from the crowbar animation).
> > >
> > > If anyone else can help out, that would be great. Thanks.
> > >
> > > ~Flux
> > > --
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > >
> > --
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] laggy animations
--
[ Picked text/plain from multipart/alternative ]
Apparently that fix is unrelated to third person local player animations. I
also implemented it and saw that the local player crowbar animation still
seemed low framerate. It's not a showstopper, luckily.
None of the fixes in that SDK forum thread address the problem IIRC.
Did you ever run into player model pitch problems in third person? That's
my last big problem remaining with it (besides this animation issue). The
pitch pose parameter works great until the player fires a weapon, then for a
moment the pose parameter stops being used and it does absolute pitching
(based on view angles). This causes a choppy effect where you can see a
double image of the player model, one using the pose parameter (just the
head/upper body tilted, as it should be) and one using absolute pitch (the
entire model tilted forward or backwards). Goes away with cl_predict set to
0.
I haven't looked at it too in depth, so it may be a simple misplaced call to
SetLocalAngles or something.
On 8/14/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Checkout
>
> http://www.chatbear.com/board.plm?a=viewthread&t=826,1113377026,18039&id=835790&b=4991&v=flatold
>
> On 8/14/06, Michael Chang <[EMAIL PROTECTED]> wrote:
> >
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Hello guys, my first time posting to this list. Please bear with me.
> >
> > This is directly related to something Paul Peloski mentioned earlier,
> with
> > removing.
> > >> > if ( !IsSelfAnimating() )
> > >> > {
> > >> >m_flAnimTime = engine->GetLastTimeStamp();
> > >> > }
> >
> > I am trying to implement a bug-free third person HL2DM game. I've been
> > doing
> > so for the past month and a half.
> >
> > I've implemented the above, but the upper body animations still seem to
> be
> > laggy / jerky / low framerate. (as seen from the crowbar animation).
> >
> > If anyone else can help out, that would be great. Thanks.
> >
> > ~Flux
> > --
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] laggy animations
--
[ Picked text/plain from multipart/alternative ]
Checkout
http://www.chatbear.com/board.plm?a=viewthread&t=826,1113377026,18039&id=835790&b=4991&v=flatold
On 8/14/06, Michael Chang <[EMAIL PROTECTED]> wrote:
>
> --
> [ Picked text/plain from multipart/alternative ]
> Hello guys, my first time posting to this list. Please bear with me.
>
> This is directly related to something Paul Peloski mentioned earlier, with
> removing.
> >> > if ( !IsSelfAnimating() )
> >> > {
> >> >m_flAnimTime = engine->GetLastTimeStamp();
> >> > }
>
> I am trying to implement a bug-free third person HL2DM game. I've been
> doing
> so for the past month and a half.
>
> I've implemented the above, but the upper body animations still seem to be
> laggy / jerky / low framerate. (as seen from the crowbar animation).
>
> If anyone else can help out, that would be great. Thanks.
>
> ~Flux
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] laggy animations
--
[ Picked text/plain from multipart/alternative ]
Hello guys, my first time posting to this list. Please bear with me.
This is directly related to something Paul Peloski mentioned earlier, with
removing.
>> > if ( !IsSelfAnimating() )
>> > {
>> >m_flAnimTime = engine->GetLastTimeStamp();
>> > }
I am trying to implement a bug-free third person HL2DM game. I've been doing
so for the past month and a half.
I've implemented the above, but the upper body animations still seem to be
laggy / jerky / low framerate. (as seen from the crowbar animation).
If anyone else can help out, that would be great. Thanks.
~Flux
--
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
