Closed corbin-poteet closed 6 months ago
There is a drawback to this fix - the spine continues to follow the camera, so it can "snap" when the player rotates the camera at a very high speed or in slow motion.
I've tried to tackle this issue before, but without success, so I'm not sure about this fix.
https://github.com/Sixze/ALS-Refactored/assets/16257871/1d3794bb-7e1c-45b8-956e-2fdd1a50ab7b
I have reworked the spine rotation logic. It now produces a similar result to this PR, but without causing new issues.
6ed5c89699972cac294ec6fe1b9d6b5cec0c9117
Before: After:
The character's spine only allows rotation while aiming, so transitioning from the
Aiming
toViewDirection
rotation mode causes the spine to snap back to a non-rotated state instead of blending with the rest of the animation transition. This is especially apparent when moving at 45 degree angles, as the spine snaps to the pelvis's yaw rotation offset independent of the blend between the two animation states.By allowing the spine to rotate in any rotation mode besides
VelocityDirection
, we produce more natural looking transitions after aiming, while maintaining the function of the spine rotating to match the pelvis.This also allows the user more control over the spine's rotation through the
ViewBlock
andAllowAiming
animation curves because of their new use inUAlsAnimationInstance::RefreshSpineRotation()
when the character is not aiming. For example, if the user wants the spine to not rotate back to the pelvis's yaw rotation during an overlay pose, they can setAllowAiming
to 1 for the duration of that overlay's pose.