3
\$\begingroup\$

I currently have my own custom first person controller, and the code to rotate the camera and controller based on the mouse position deltas looks like this:

public void ApplyRotation()
{
    this.transform.transform.Rotate(new Vector3(0, Input.GetAxis("Mouse X") * this.Sensitivity * Time.deltaTime, 0));
    this._VerticalRotation += Input.GetAxis("Mouse Y") * this.Sensitivity * Time.deltaTime;
    this._VerticalRotation = Mathf.Clamp(this._VerticalRotation, -85, 85);
    Camera.main.transform.eulerAngles = new Vector3(
        -this._VerticalRotation, 
        Camera.main.transform.eulerAngles.y, Camera.main.transform.eulerAngles.z
    );
}

Right now, I'm using Time.deltaTime in the rotation code to keep the rotations framerate dependent, but I'm not sure if I should be doing this when I'm dealing with the mouse. Should I keep this framerate dependent, or should it be framerate independent?

\$\endgroup\$
6
\$\begingroup\$

Yes, you need to keep Time.deltaTime into account when you use Input.GetAxis, because the values it returns are also deltaTime-adjusted.

You can read this in the documentation:

This is frame-rate independent; you do not need to be concerned about varying frame-rates when using this value.

The example code in the documentation makes it clear that multiplying by deltaTime is how it is supposed to be done:

 float translation = Input.GetAxis("Vertical") * speed;
 float rotation = Input.GetAxis("Horizontal") * rotationSpeed;
 translation *= Time.deltaTime;
 rotation *= Time.deltaTime;
 transform.Translate(0, 0, translation);
 transform.Rotate(0, rotation, 0);

It would be a different situation when you would use Input.mousePosition and compare the value to the previous value. The reason is that the mouse position changes are directly related to the physical distance the player moved their mouse across their desk between two frames. Higher update rate means you take more samples which means you measure smaller differences.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ I Googled this question because I had a problem with my camera movement, completely unrelated to Unity. I was calculating it by comparing mouse positions, but then multiplied it by deltatime. Your last sentence in your answer basically saved me from spending hours trying to fix the bug it caused. :) \$\endgroup\$ – TomsonTom Apr 10 '17 at 14:39
  • \$\begingroup\$ Kinda late to the party, but how exactly do they mean by "This is frame-rate independent; you do not need to be concerned about varying frame-rates when using this value."? I interpret it as "we have already calculated this to be frame-rate independent, so you need not". But then they proceed to multiply it by Time.deltaTime again which makes me think Input.GetAxis is in fact frame-rate dependent. What did I miss? \$\endgroup\$ – Bruno Ely Dec 17 '18 at 9:33
  • 1
    \$\begingroup\$ @BrunoEly late reply but speaking specifically about the asker's use of GetAxis. Using it with a mouse axis gives you an absolute difference in position of the mouse since the previous frame. Typically you don't want to include delta time in that or moving the mouse the same distance gives you different results if e.g. you do it at a different speed or e.g. the framrate is different. Sometimes you want that, and mouse look is not often a time like that. \$\endgroup\$ – Ruzihm Nov 20 at 23:54
  • \$\begingroup\$ And in those cases, it is more sensible to be dividing by deltaTime to calculate the velociy of mouse travel (velocity = delta position / delta time)! \$\endgroup\$ – Ruzihm Nov 21 at 0:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.