Lower body animations fix #72
Conversation
…t product between velocity and view vectors to set leg animation
|
Could edit this slightly so in ComputePoseParam_BodyXY instead of defining a third vector eyeSide2D which is eyeForward2D rotated by 90 degrees, we just use eyeForward2D in the sideDot(Product) definition but with x and y switched around and x multiplied by -1. Less readable but will save us a bit of memory and maybe a bit of computational complexity |
|
Could also define our own normalisation function which only divides the first two values of a 3D vector by the magnitude of only the first two values, allowing us to use the 3D Vectors in the dot product calculation and removing the need to define eyeForward2D and velocity2D |
…ittle fun modification to thirdperson view
|
Went ahead and added my workaround for the upper body animations too to this branch @Rainyan |
|
Hi, thanks a lot for the PRs. I'll try and get to reviewing these ASAP, hopefully this weekend. |
There was a problem hiding this comment.
Can discard changes to this file, was doing this more for fun but it actually made debugging other problems trickier as you cant see the whole playermodel anymore
| m_bReloading = m_pOuter->MyCombatCharacterPointer()->GetActiveWeapon()->m_bInReload; | ||
| } | ||
|
|
||
| return (m_bReloading && (static_cast<CNEO_Player*>(m_pOuter)->GetFlags() & FL_DUCKING)); |
There was a problem hiding this comment.
Thought this cast might be redundant as we can get player flags from the base player class, but I'm fairly new to c++ and I wonder if this might actually cause some problems with invalid memory access down the line (CNEO_Player inherits all the properties of its base class and then some, so it takes up a different amount of space in memory to what m_pOuter is defined as I really don't know and welcome feedback)
| if (bWaitAtEnd) | ||
| { | ||
| flCurCycle = 1; | ||
| return; |
There was a problem hiding this comment.
I think not having a return here was causing a problem with looping animations because of lines 386 to 388, but I've made other changes since then so might have to test again.
| BaseClass::ClearAnimationState(); | ||
| } | ||
|
|
||
| void CNEOPlayerAnimState::ClearAnimationFlags() |
There was a problem hiding this comment.
I wanted a way of clearing the flags defined in this class without clearing the flags in the base class (meaning without calling BaseClass::ClearAnimationState())
|
|
||
| float speed_x = speedScale * forwardSign; | ||
| float speed_y = speedScale * sideSign; | ||
| eyeForward2D.NormalizeInPlace(); |
There was a problem hiding this comment.
Normalizing a vector involves division which could make this a very expensive operation
| { | ||
| sideSign = -1; | ||
| } | ||
| Vector2D eyeForward2D = eyeForward.AsVector2D(); |
There was a problem hiding this comment.
Potentially don't have to define new vectors if we can somehow isolate and normalise the first two components of this 3D vector on their own
|
|
||
| float forwardDot = eyeForward2D[0] * velocity2D[0] + eyeForward2D[1] * velocity2D[1]; | ||
| Vector2D eyeRight2D = Vector2D(eyeForward2D[1], eyeForward2D[0] * -1); // eyeForward2D rotated by 90 degrees | ||
| float sideDot = eyeRight2D[0] * velocity2D[0] + eyeRight2D[1] * velocity2D[1]; |
There was a problem hiding this comment.
This is nice to read but maybe to save some resources we could delete line 443 and have line 444 read
float sideDot = eyeForward2D[1] * velocity2D[0] + eyeForward2D[0] * -1 * velocity2D[1];
…witching to a non-zoom enabled weapon
2 participants
m_pPlayerAnimState->Update() expects two angles (pitch and yaw) in degrees, not two parts of a vector. Now its fixed
ComputePoseParam_BodyXY used m_nButtons to work out in which direction the legs should move. Since m_nButtons is not a networked variable, it wasn't possible to play leg animations for any other players except the local player. Now ComputePoseParam_BodyXY instead computes the player direction of travel in relation to the players camera (dot product between camera angle and velocity for whether player is going forwards or backwards and dot product between camera angle rotated by 90 degrees and velocity for whether the player is going left or right)
Retaining the speedscale and normalising the two vectors results in the smoothest animation.
NOTE Since division is a computationally expensive operation, can discuss whether normalising the two vectors for every player object every update is worth it