IsKinematic and MoveRotation / MovePosition

Unity Engine
1

Hi guys I’m trying to clarify some good practices in my mind concerning the Rigidbody, the IsKinematic parameter and the methods MovePosition/MoveRotation.
Here’s what I understood for now, according to the documentation and some forums researches:

  • Rigidbody (3D):

  • IsKinematic true

  • Use Rigidbody.position for teleporting.

  • Use MovePosition for continous movemement that needs the Interpolate parameter to be effective and/or if you need the velocity property to be updated. (means that if you don’t need velocity reading and Interpolate is none, there is no benefit using this method rather than “teleporting” small steps with Rigidbody.position)

  • Use Rigidbody.rotation for instant rotation.

  • Use MoveRotation for continous rotation that needs the Interpolate parameter to be effective and/or if you need the angularVelocity property to be updated. (means that if you don’t need angular velocity reading and Interpolate is none, there is no benefit using this method rather than “teleporting” small steps with Rigidbody.rotation)

  • IsKinematic false

  • Use Rigidbody.position/rotation for teleporting/instant rotation.

  • Use physics methods as AddForce/AddTorque, velocity/angularVelocity for physical movement/rotation.

  • Do not use MovePosition, this method is dedicated to kinematic rigidbodies (as mentionned in documentation).

  • You can use MoveRotation (as the doc do not mentionned the kinematic state anywhere) for continous rotation that needs the Interpolate parameter to be effective and/or if you need the angularVelocity property to be updated. (means that if you don’t need angular velocity reading and Interpolate is none, there is no benefit using this method rather than “teleporting” small steps with Rigidbody.rotation)

Am i correct?
What about Rigidbody2D? it looks like it have differents behaviours…
I hope @Edy will land on this thread

2

Oh yes…

I want to share the following list, hopefully everything is correct :eyes:. if someone spot something wrong please let me know.

  • It doesn’t contain any good practice (sorry, maybe this is what you are looking for), only direct results from my own experiments (mostly 2D vs 3D stuff).

  • It also shows what happen to interpolation (I’ll assume all the bodies have interpolation turned on) if you call X method before the simulation (e.g. FixedUpdate) and after the simulation (e.g. OnCollisionEnter). I won’t mention the interpolation target pose (which can be important), only interpolation as a “smooth transition” from A to B. I’ll probably say something like “it does/doesn’t work” (that’s all).

  • I’ll ignore MoveRotation for now, sorry.

  • (Rigidbody type)

  • (Method/property called)

  • (Some aspect/property)

  • 2D: …

  • 3D: …

The list:

  • Kinematic:

  • Position:

  • Velocity:

  • 2D: not affected.

  • 3D: not affected.

  • Position:

  • 2D: rb2D.position = yourTarget after the call.

  • 3D: rb.position = yourTarget after the call.

  • Interpolation:

  • 2D:

  • [u]Called before the simulation:[/u] It works.

  • [u]Called after the simulation:[/u] interpolation gets reset.

  • 3D:

  • [u]Called before the simulation:[/u] interpolation gets reset.

  • __ Called after the simulation__: It works! (for more info check this thread ). It seems this is some kind of bug.

  • MovePosition:

  • Velocity:

  • 2D: not affected.

  • 3D: affected (based on the distance the body traveled over “fixed time step” seconds.

  • Position:

  • 2D: it doesn’t change after the call (it only gets flagged internally as a target). After the simulation rb2D.position = yourTarget.

  • 3D: it doesn’t change after the call (it only gets flagged internally as a target). After the simulation rb.position = yourTarget.

  • Interpolation:

  • 2D:

  • Called before the simulation: it works.

  • Called after the simulation: it works.

  • 3D:

  • Called before the simulation: it works.

  • Called after the simulation: it works.

  • Dynamic:

  • - [u]Position:[/u]
    - [u]Velocity:[/u]
    - 2D: not affected.
    - 3D: not affected.
    - [u]Position:[/u]
    - 2D: rb2D.position = yourTarget after the call.
    - 3D: rb.position = yourTarget after the call.
    - [u]Interpolation:[/u]
    - 2D:
    - [u]Called before the simulation: It works.[/u]
    - [u]Called after the simulation: interpolation gets reset.[/u]
    - 3D:
    - [u]Called before the simulation: interpolation gets reset.[/u]
    - [u]Called after the simulation: interpolation gets reset.[/u]

  • MovePosition:

  • Velocity:

  • 2D: not affected.

  • 3D: not affected.

  • Position:

  • 2D: it doesn’t change after the call (it only gets flagged internally as a target). After the simulation the rb2D.position = yourTarget.

  • 3D: The RB is teleported to the target after the call.

  • Interpolation:

  • 2D:

  • Called before the simulation: it works.

  • Called after the simulation: it works.

  • 3D:

  • [u]Called before the simulation:[/u] interpolation gets reset.

  • __ Called after the simulation__: It works! (for more info check this thread ). It seems this is some kind of bug.

Hope it helps.

3

I did some tests on this and, unfortunately, it does not appear that MoveRotation interpolates the transform unless isKinematic is true. It’s just like MovePosition, in this regard. I would have to guess that this is just an omission in the Unity documentation.

1 Like
4

and when setting the physics frame rate to be the same as Update so interpolation isn’t necessary - MoveRotation (and probably MovePosition) will often result in short periods of jittery motion when isKinematic is false.

So if using MoveRotation on a non kinematic rigidbody then it may be better to use it in Update instead of FixedUpdate. A typical scenario for this is when creating a rigidbody based player controller where the camera is a child of the rigidbody.

1 Like