Splitting one event's code between Update and fixedUpdate

I am cleaning up some code to get rid of some bad practices that I have been getting away with until now. I am well aware that you should deal with rigid bodies and forces during fixedUpdate and not Update. Right now I am not doing this. This is what I am currently doing (using psuedocode for simplicity and abstraction) because this is a general problem I need to get my head around. This script is attached to the camera.

function Update(){

 if (Input.GetButtonDown("Fire1"))
 {

 var ray1 : Ray = camera.ScreenPointToRay(Input.mousePosition);
 var hit1 : RaycastHit;

 if(Physics.Raycast(ray1 , hit1))
 {
 //simplified psuedo code here for sake of simplicity and to keep things relevant.
 Scale the mesh only (not the collider) using iTween; //So needs to be done in Update
 Apply force to collider at the hit point; //This needs to be done in the Fixed update 
 }
 }
}

All of my code for this is working fine, I’m not seeing any problems (yet) so no help needed with the implementation. Just best practice on how to extract the Apply force line and put it in the FixedUpdate. I am sure if I leave this the way it is and play the game on a faster/slower machine - I’d see something glitchy happening.

Would I need to set up another raycast in fixedUpdate with only the apply force stuff in there, keeping the original raycast check in the update function to do the scaling?! This seems wasteful and backwards. There must be a ‘proper’ way to do this kind of thing.

Should I create separate scripts or functions for both the scaling (update) and the force (fixedupdate), then call them both from another script during the update?

What I am trying to say in a nutshell:

  • One event/action is happening (object
    clicked on by mouse)
  • Two things need to happen (one in
    FixedUpdate, one in Update)

What is the best practise for this suposedly fairly common scenario?

Thanks so much everybody.

FixedUpdate is only required if you have a continous force that you want to apply. For one time impulses you can or should use Update. Never use FixedUpdate to process events. Keyboard or mouse events can be dropped or processed multiple times if they are used in FixedUpdate. This is because everything is based on the Update cycle. FixedUpdate might be called one or several times per update or in some cases not at all.

Some examples (those assume a FixedUpdate rate of 60 fps):

  • At high framerates (~120 fps) FixedUpdate is called every second Update call. That means if an even happens in between two FixedUpdate calls, it isn’t processed.
  • At low framerates (~30 fps) FixedUpdate is called two times per frame. That means GetKeyDown will return true for two FixedUpdate cycles because the state only changes per frame.

So, again: Do everything in Update, only physics related stuff that is applied over several frames should be placed in FixedUpdate.

edit:
Just to clarify: FixedUpdate is called along with Update, just in a different way. It’s calling is “fixed” (not fix).

Here’s the basic logic how FixedUpdate works:

// C#
float gameTime = 0.0f;
float fixedTime = 0.0f;
float fixedTimeStep = 0.02f; // 1/50 == 50fps

void UnitysInternalMainLoop()
{
    while(true)
    {
        Update();
        gameTime += Time.deltaTime;

        while (gameTime - fixedTime > fixedTimeStep)
        {
            FixedUpdate();
            fixedTime += fixedTimeStep;
        }
    }
}

This is just pseudo code. As far as i know the fixedupdate-cycles are executed before Update, but the concept is the same.

answer at the end of text 8)

FixedUpdate instead of Update should be used if you interact (e.g. read) some data from physics engine. this is because if you read data in U instead of FU you can read some data twice (two frames while 1 fixed update) and make unnecessary calculations, and also you can miss some threshold if your FPS is low (1 U for 5 FU), cause FU is always has fixedDeltaTime

so you can apply forces in Update or FixedUpdate of your choise - this force will be applied only on FixedUpdate stage.

it’s just little cheap to calculate for example summary force from 3 Updates and apply it once in FixedUpdate

don’t calc things like raycast twice without really need.