When does unity’s physics 2D caculations happen? is it like a script that I can change when it happens here:
Or it always happens at the end of the frame, or the start, or something else?
1 Like
Here is some timing diagram help:
Two good discussions on Update() vs FixedUpdate() timing:
By Default, Physics is updated by calling FixedUpdate() that can be clearly shown in Project Settings > Physics 2D > General Settings > Simulation Mode:
“The speed” of calling is defined as 0.02 seconds by default in Project Settings > Time > Fixed Timestep:
1 Like
But when does it happen, at the start? So
void FixedUpdtae()
{
//does it happen here?
rb.velocity = velocity;
//does it happen here?
}
So if I have more than one script with fixed update, will the physics calculation happen multiple times?
No, physics calculation will happen once in Fixed Timestep.
But Multiple FixedUpdate() functions will be invoked during the calculation step.
Declaring FixedUpdate() function in your script, you just create a subscription to the calculation step.
Please refer to the timing diagram I already posted above. It shows:
Generally you cannot count on ANYTHING timing-wise from FixedUpdate() because:
- it might not even run this frame
- it may run many times in one frame
1 Like
Thanks, it is weird that fixed update can happen multiple times per frame, but I guess it makes sense
Of course, if you have Hundreds of Objects with their own Update(), FixedUpdate(), ect. predefined Unity functions - it will weird. More over, it will cause performance issues one day.
But for such situations you need to use Data-Oriented Technology Stack that is kinda advanced topic.
However, you can develop in the usual manner without it, if you don’t plan to create a game with big amount of action objects.
2D Physics calculations happen when Physics2D.Simulate happens. The SimulationMode2D (as shown above) controls if it should be called by you manually (Script) or automatically by Unity either during the FixedUpdate stage or during the Update stage of the PlayerLoop. In both those cases, simulation happens after all the scripts have had their callbacks executed i.e. after all FixedUpdate calls happen or Update calls happen. This is because the script-callbacks are registered against the PlayerLoop before lots of other things. The ordering that the specific script-callbacks happen is controlled by the execution order thus that only controls the script callbacks and nothing else. It doesn’t change when things are called by the PlayerLoop (physics, animation etc) and those are in a specific order for a very good reason (system dependencies etc).
You should also know that FixedUpdate isn’t called by physics, it’s part of the player loop. Many things are called during the FixedUpdate including animiation, 2D/3D physics and lots of other things. Same goes for Update and all the other PlayerLoop stages (LateUpdate etc).
Rather than considering things like this “weird” you should consider it an opportunity to understand “why”.
The idea is that FixedUpdate gives you a regular time-step that keeps up with game-time. If game time has progressed a lot (maybe you’re spending too much time in your scripts) then FixedUpdate lags behind and needs to be called multiple times to catch-up. Not doing this means things that are registered against it would loose time and lag behind. Again, physics is not controlling this, it’s a user of it just like you are.
1 Like
Is this because of compatibility issues only (I mean for the users that can use accidentally or purposely the Physics operating in Update(), for example), or there may be another reason?
However, there are topics like this that broke what I supposed about compatibility.
P.S. I just re-read your sentence. Did you mean alongside instead of during?
I’m not sure what you mean by compatibility here but you can run physics using a fixed time-step or a variable time-step which is a common choice of physics engines. Lots of pros/cons for each if that’s the part you’re referring to.
So the “FixedUdate” isn’t defined as being the script FixedUpdate callback. It’s described as the PlayerLoop stage. The PlayerLoop has many stages, some of which call scripts, some that don’t.
If physics is set to be called during the FixedUpdate stage then it will be, after the Script execution of FixedUpdate callback happens.
Clearly the scripts are often referred to as “being” the FixedUpdate or Update but it’s actually not the case. 
I think to clarify what Melv is saying, there’s a ton of stages to the player loop that are handled by the player loop API. You can see all the ‘FixedUpdate’ stages of the player loop here used interally by the engine: UnityCsReference/Runtime/Export/PlayerLoop/PlayerLoop.bindings.cs at master · Unity-Technologies/UnityCsReference · GitHub
Not sure if their order in the source code refers to their usage order.
3 Likes
It seems that the order listed in the source reference is indeed the order registered and a great idea to show this reference, completely forgot about using it here!
For sure, you can see in the “FixedUpdate” entry that you get “ScriptRunBehaviourFixedUpdate” (script callbacks) before “Physics2DFixedUpdate” (simulation step if selected). Physics is registered in various other things for per-frame simulation as well as interpolation if required.
1 Like
Thanks, but will using physics2D.simulate(time.deltaTime) cause any bugs?
And Can I use it, and somehow not make the actual physics2D calculation happen?
I have a collision script, and it needs to know the object’s velocity, so I need to use physics2D.simulate(time.deltaTime), but then the physics calculation happen twice.
Correct me if I’m wrong
I’m not following what you’re trying to ask here. Nobody suggested to use this so it’s not clear why you’ve decided it’s a way to solve any issue. If you read what was said, you’ll see it was just a way to call it yourself instead of Unity calling it automatically. It’s not special or difference in any way.
You need to describe properly (in more than few words) what you want here otherwise things are just confusing i.e. what does “needs to know the object’s velocity” mean? Read the velocity property of the Rigidbody2D.
With all due respect, @MelvMay describes advanced things which can be confusing for beginners. There is a high probability that you do not need to use manual physics simulation throughout your entire career. That’s a very specific need.
I would suggest not simulating physics manually, but trying to figure out how you can achieve your goals with automatic physics simulation by default.
So, is this a task?
Then
by this way:
This is what I’m trying to achive: I have a collision script, to check if the object will collide, the script has to know the distance to the wall, and the object’s velocity.
It is automatic in dynamic, and I’m using dynamic rigidBody2D, but I’m using is trigger for certain reasons.
If one object with mass 1 and velocity.x = 1 is pushing another object with mass 1 and velocity,x = 1, the velocity will 0.5, this is one example how the velocity can be different from the first’s object velocity, and the collision scripts needs to know the true velocity, after all calculations.
Calculating the velocity is possible, but harder then just dividing the velocity by shared mass, and at this point of calculating the velocity, then why use the automatic calculation in the first place?
1 Like
Why can’t you use this function?
It seems that @belpory wants to effectively simulate movement and find the velocity after a collision without actually moving it (??) from what I can see above. This is obviously advanced (if you require accuracy) and requires more knowledge. Note that I never once suggested to use manual simulation; this was in direct response to your questions. 
@belpory
Without that knowledge, it’s best to use one of the many physics queries to detect a future collision then use your own method to calculate the velocity. The alternative is much more complex involving manual simulation using proxy bodies.
The reason I used is trigger, is to make one way platforms. I have now seen used by effector.
https://www.youtube.com/watch?v=7rCUt6mqqE8 (second 29)
Can you please explain what it is?
sorry I wasted your time, but thanks.