RigidBody2D Performance with AddForce on WakeUp

I recently explored using RigidBody2D.AddForce to move my sprites around on the screen, instead of translating the gameobjects directly in FixedUpdate.

When the user pauses my game, I was saving the velocity of the RigidBody2D and then setting IsKinematic to true.
When the user resumes the game, I would re-apply the Force and wake up the RigidBody2D object.

I noticed that when the user resumes, there is a delay before the objects starts moving again, and it is a small delay and it is intermittent, but very noticeable. Does it take Unity a few cycles before it is able to process all the wakeup’s across all the objects? Switching back to my transform.Translate() method, there is no delay when the game resumes.

Is Physics2D expensive computationally?

Not sure what you mean by wakeup’s here, you mean wake the rigid-body?

If nothing is happening then wouldn’t you be better off taking all the rigid-body out of the simulation by using: Unity - Scripting API: Rigidbody2D.simulated

If not that, then store the velocity and reapply that when you unpause.


As nearly all physics changes, any change made is dealt with during the next fixed-update and subsequent fixed-updates.

Some changes such as changing the body type happen instantly in that any existing contacts are clear but new ones are not recalculated until the next fixed update thus you won’t get any callbacks until then.

Asking is Physics2D is expensive computationally is pretty vague, maybe you can be more specific there but henerally it’s very cheap; the dominant computational costs typically rise as the number of contacts between colliders rise as well as using continuous collision-detection on dynamic rigid-bodies. Moving dynamic bodies directly yourself can be expensive as contacts have to be continually recalculated (don’t do it).