A lot of people say physics should/is done in fixed update. Is there any reason why rigid-body interaction should not be done in update?
The simulation for both 2D/3D is run (by default) during the fixed-update (after the script fixed-update). You can change this by changing the simulation mode in the physics settings to run per-frame or manual via script. It’s not hardwired to running in a FixedUpdate, it’s just the default.
Typically applying things like forces are done in the script FixedUpdate because physics runs immediately after the scripts are called.
This is a separate discussion as to why FixedUpdate is the default which is to remove any frame-rate dependency.
You can perform queries whenever you like, they are a read operation. You typically apply forces in the fixed-update because if you were to do it per-frame then the force would be frame-rate dependent.
There’s nothing stopping you setting absolute values though whenever you like such as setting the velocity of a Rigidbody however if you do this per-frame, that doesn’t change the fact that it won’t be used until the simulation runs which might be during the FixedUpdate.
So, if I want to control when simulation runs, it looks like I should set
Physics.autoSimulation to false during the main start() and then
Physics.Simulate to force simulation.
It seems also that I would need to set autosynch transforms to false and call synchtransforms at the same time too.
…“the scripts”: do you mean the autoSimulation and synchTransforms scripts?
This statement:
does not make sense. Is it not true because[edit] all motion and forces are proportional to deltatime (for the update method being used) and therefore, [by the multiplication[edit] of deltatime] normalised to motion/forces per second. I.E. the use of fixedUpdate should have nothing to do with per-second motion or force proportionality.
And again:
appears to be incorrect because if the physics is being implemented correctly then it will always be proportional to deltatime, whatever that is for a single frame.
So what am I missing, when I run the physics, does it not already know what the deltatime is from the last time it was run?
No. The simulation output is dependent on the time step. Calling simulate five times with a time step of 0,02s will give you significantly different results than calling it one time with a 0,1s time step. Outside of the fact that the simulation becomes very unstable at large timestep (especially joints and collisions), having a variable timestep generally mean unstable and unpredictable results.
1 Like
Physics run at a fixed rate mainly for consistency of the simulation, especially when resolving constraints and collisions. Even being “implemented correctly”, the result of the physics simulation will be different depending on the time step used. Some features even require a minimum simulation rate to be supported, such as joints. The maximum stiffness of a joint the simulation can support is directly dependent of the physics rate. Low physics rates will make the joint unstable and/or imprecise.
Also, PhysX (the underlying 3D physics engine in Unity) is not stateless, meaning that some state values are carried over from the previous simulation step to the current simulation step (i.e. caching and optimization). If deltatime changes between simulation steps then the calculations will be inconsistent as they are mixing different deltatimes, resulting in weird and unexpected effects.
Here’s a thread with a detailed description of the kind of weird collision effects you may experience with varying delta times:
https://discussions.unity.com/t/785978/7
If your physics simulation uses the deltaTime from Update then there may be large jumps with inconsistent results at the times at which the frame rate drops occasionally. This situation is not rare at all, and typically happens several times during a normal run: application starting (first frame), switching applications (alt-tab), OS interruptions, async loads… When that happens, anything that is being moved by the physics will experience a large distance moved in a single step, causing effects like bypassing collisions or being launched huge distances when the frame rate is back to normal. Just one frame with delta time too large can make the joints blow up.
1 Like
@Edy thanks for the clarification and link. I will probably have a question or two on the thread you linked.
Also, I was not suggesting that longer dt times be used ( @Edy and @Gotmachine ) because my update loops generally run faster than, say, a 60 Hz, fixedupdate loop. I wanted to investigate the assertion that since dt for a single frame makes the physics from that frame proportional to unit time, the physics should be consistent. If some cached values are carried across frames under the assumption that dt is not changed then that is will indeed invalidate a variable rate approach.
Another question: is it Unity that uses these cached temporal optimisations or developers only?
This is not just about previous frame state. Fundamentally, a discrete rigidbody physics simulation doesn’t yield the same results at different time steps. Collisions will behave differently because penetration depth will be different. Joints will also behave differently because distance travelled with a given state is different. They will be more stiff at lower time steps and more floppy at higher time steps. And a game framerate is highly unstable. Even in very stable games, there is a large frame time variance, and you will have occasionally huge frame times for reasons totally outside of your control, so a physics timestep tied to framerate will result in inconsistent and unpredictable effects.
This being said, I know some games are using a variable physics timestep to have some flexibility in the framerate synchronization, but I don’t think it goes above a 10-20% variation.
It will be proportional to delta time indeed, which is not good if the delta time varies from frame to frame since most systems are non-linear. This boils down to variable timestepping vs fixed timestepping.
Advancing a simulation using a variable timestep will generally yield much worse results than using a fixed one, at least when using common integration schemes (symplectic Euler, Runge-kutta, etc). Note this is not specific to Unity.
Yeah, I had to go back and edit that, I was trying to say it is proportional …, edited to:“Is it not true because[edit] all motion and forces are proportional to deltatime (for the update method being used) and therefore, [by the multiplication[edit] of deltatime] normalised to motion/forces per second”
Ah well 
Internally, Unity does something equivalent to this when updating physics:
float accumulator = 0;
void Update() // Unity's internal update, called once per frame
{
accum += Time.deltaTime;
while (accumulator >= Time.fixedDeltaTime)
{
FixedUpdate(); // Unity calls FixedUpdate() so you can do your physics stuff
Physics.Simulate(Time.fixedDeltaTime); // then it updates physics
accumulator -= Time.fixedDeltaTime
}
}
Hence the “physics stuff must be done in FixedUpdate” mantra: FixedUpdate might be called zero, one, or multiple times per frame with a fixed delta (depending on how much not-yet-simulated time there’s accumulated), while Update is always called only once per frame with a variable delta.
It’s fine to call Physics.Simulate() manually in Update() and do your own physics update loop, but if you’re relying on Unity’s automatic physics update, then FixedUpdate must be used to apply forces, impulses, etc. Otherwise the internal physics update and your physical calculations would be completely out of sync.
2 Likes
Yes! I only recently read and added a comment to the page on Physics-autoSimulation to get clarification on the combined use of Update and fixedupdate.
“By default, physics is updated every Time.fixedDeltaTime during the play mode. It happens automatically as part of the regular game loop.”
which sounds exactly like the algorithm you wrote, so thanks for clarifying. I am curious about whether the calls to the unity internal Update and FixedUpdate are synchronised but if fixed is called from within Update then perhaps it is.
Furthermore, this does explain quite well why, if you are going to use addforce etc, you would need to do it in fixed. That is unless addforce accumulates until simulate is called - which would be quite simple to do and it would work as long as the force increments are kept proportional to time.
From my perspective, when moving (translating) the character, addforce leads to some acceleration which changes velocity and that leads to displacement. Then, as the character moves, unity take drag etc into account.
I jump straight to displacement because I have no need for precise character simulation and animation works as expected.
In both cases, after displacement, there may be a collision and that is resolved with normal physics (again taking mass, drag, etc into account).
I tend to do what is most efficient and not change that unless there is a problem.
Thanks again for taking the time and for your patience
1 Like