Why are we hard coding the movment values?

[mihaivladan]

Why are we converting the Input Values to just 0 or 1? The blend tree takes care of all the animation blending from the “raw” input values - if we add a new state between “Idle > Running” in the blend tree, don’t we need to add more IF statements in the code to make that functionality work?

Ex: I’ve added a Walking animation in the blend tree, so it’s Idle > Walking > Running (0>0.5>1). I’ve just added these two lines of code in the Update Animator Method, and it works flawlessly on both keyboard and Gamepad

Here is a screen recording of what I’m talking about: the movement is from Keyboard in the first part / Gamepad is in the second. By using the raw input values from the gamepad we can trigger the walking blend state. If we hardcode the value to be 1f there’s no way to add more states without adding more IF statements.

Input values - Keyboard / Gamepad

Am I missing something? In the Argon Assault Course, we just read and use the input values to drive the animations/movement, why convert them to absolute values here? Here is what I’m using in the video to drive the animator.

    private void UpdateAnimator(float deltaTime)
    {
        stateMachine.Animator.SetFloat(_targetingForwardHash,stateMachine.InputReader.MovementValue.y,AnimatorDampTime,deltaTime);
        stateMachine.Animator.SetFloat(_targetingRightHash,stateMachine.InputReader.MovementValue.x,AnimatorDampTime,deltaTime);
    }

[over_yonder]

It might be to avoid opening a can of worms around mapping unit circle inputs to a unit square - relevant for joysticks, which will return ~ 0.707, 0.707 for up-right (0.707 being the square root of 2, from Pythagoras for a 1,1, triangle’s hypoteneuse).

If you want to have analogue animator floats, you’d need to map it per example below. There’s different ways to skin a cat - this one will essentially clamp the input so that everything from top-right to bottom-right is considered ‘full rightness’:

        private void UpdateAnimator(float deltaTime)
        {
            var moveInput = StateMachine.InputReader.MovementValue;
            var rightness = Mathf.Clamp(moveInput.x * Mathf.Sqrt(2),-1,1);
            var forwardness = Mathf.Clamp(moveInput.y * Mathf.Sqrt(2),-1,1);

            StateMachine.Animator.SetFloat(TargetingForwardHash, forward, AnimatorDampTime, deltaTime);
            StateMachine.Animator.SetFloat(TargetingRightHash, right, AnimatorDampTime, deltaTime);
        }

[mihaivladan]

Thanks for the reply. In theory, I understand what issue you described; however, I’m having a hard time believing the whole Unity Input System/Monobehavior can’t do a simple square root divide if I press both up and right on a gamepad at the same time.

We also use Lerp for the free look system and that one gives values that have 5-6decimals. Based on what you’re saying that one should create even more “issues” due to misaligned values.

The only reason I can think of why using full values (0/1) in this course is the movement speed variable. That one is also hardcoded and doesn’t change based on blend tree animations (ex: walking animation is half the speed of the running animation). If you don’t change the speed variable, playing a walk animation would look like the character is skating on ice.

[over_yonder]

Yeah nothing to do with Unity’s capabilities, when I say “open a can of worms” I just mean “confuse people with complexity”. Considering it’s something they’ve done before they might have elected to leave it out and focus on new material (similarly with not having a walking animation or using mecanim like the first RPG course).

[mihaivladan]

Got it! Based on my experience with the RPG Combat Course, if they do a certain thing in a specific way, It might be tied to something else in a future lesson.

Having all those IF statements made it look like it’s part of a more extensive system, so I wanted to clarify if changing it now will not mess things up down the line.