Is it "right" to use rigidbody forces to animate in Unity3D?

Question

I wan't to implement a frictionless spring in unity3D to animate a gameobject as if it where floating by moving up and down. I am doing it with an animation but if I use forces they can combine an create richer sequences.

I could do:

//Update
 rigidbody.addforce( springForce );

The force is just the change in the velocity so I could also do

//Update
rigidbody.velocity += Time.deltaTime * springForce / rigidbody.mass;

The question remains, is adding a force each frame efficient? Should I skip some frames or just do the animation to avoid performance issues? Note: I program for mobile.

Answer 1

The difference between Update and FixedUpdate is this:

Update is always called as quickly as possible. The time between calls is tracked in deltaTime. Even if "as quickly as possible" turns out to be really slow, only a single call to Update is made with a high DeltaTime value.

FixedUpdate is never called more often than the physics framerate. If things slow down and the time for several physics frames passes without the necessary calls being made, Unity will try to catch up by calling FixedUpdate multiple times. For example, if the physics framerate is 0.02 and slow code holds up the game for 0.06 seconds, Unity will call FixedUpdate 3 times to try and catch up.

You can probably see the problem at this stage: physics movement tends to be complicated with acceleration, deceleration, collisions etc. If you add forces in Update then the amount of force added and the exact timing with which it is added will vary based on the speed the game is running at. Also, if the game slows down, the physics engine will be doing multiple updates per physics frame to catch up (it works in the same way FixedUpdate does) and your Update method would be unable to compensate for this (actually, it is possible, but only if you basically duplicate the catch-up code Unity already has which is pointless)

To use your spring example, assuming you had all the spring behaviour correct but in Update instead of FixedUpdate, if the game was running fast then Update could be called several times with the object not moving - not because the spring force has failed to move it but because the physics engine has not yet run to actually pay attention to the force and make the object move. If the game was running slow then the object could hit the spring and then the effect of the forces on the object would be calculated multiple times before the spring was calculated again. This could cause the object to move a tiny bit out of contact with the spring and end up bouncing, or to actually interpenetrate the spring and force restitution to occur.

If an object is just moving in a straight line with no physics then its position over time is defined by very simple equations which can be evaluated at any value, so you can use Update.

Unlike the previous answer there is actually a good reason to use deltaTime in a FixedUpdate method - Unity automatically sets it equal to fixedDeltaTime in this case, so your code can adapt if you change the physics framerate.

Answer 2

First you would do physics updates in die FixedUpdate method. So the force wouldn't be applied every frame but every physics tick (default 0.02 seconds I think).

If you should do that heavily depends on your needs. If you want a realistic simulation of a floating object you probably need to apply the force every physics tick. Wether you should use a spring for that is another question. There are some floating scripts in the unify wiki:

http://wiki.unity3d.com/index.php?title=Main_Page

Or you could have a look at this very interesting script:

http://forum.unity3d.com/threads/72974-Buoyancy-script

When adding a force in Unity through the use of AddForce you have the choice of a couple of ForceModes (http://docs.unity3d.com/Documentation/ScriptReference/ForceMode.html). So it might be a little different to your change of velocity depending on the mode you will use.

Another point: When using FixedUpdate you won't need to use Time.deltaTime as the ticks always have the same time-lag.

If you decide to apply the force less often you can change the time between physics ticks to increase performance:

http://docs.unity3d.com/Documentation/ScriptReference/Time-fixedDeltaTime.html

http://docs.unity3d.com/Documentation/ScriptReference/Time-timeScale.html