It’s my understanding that Update happens one time per frame, and Fixed update happens a fixed number of times per second.
I’m making a game that deals with frame precise things, this includes a system that records the player’s input, so that whatever they executed can be viewed exactly as done before. And, in theory this would work: however, when the frame rate is upset/drops this causes a the recording to behave incorrectly since the physics are put off a bit. Of course it only takes frame of nonidentical behavior of physics for the entire recording to become useless.
But if there is a way to have the physics’s Fixed Update, and all related functions (triggers and collision) only happen right after, or before Update, I would really like to know how that could be accomplished.
all of collision from my understanding occurs after FixedUpdate. What exactly are you doing between Update and FixedUpdate? It would be more helpful to know what you are trying to accomplish.
There’s no way to guarantee it that it goes fixed, update, fixed, update.
The sequence is here:
Note that the FixedUpdate has a return loop. This is stating that FixedUpdate might be called multiple times before Update is called. Or sometimes not called at all.
What basically happens is when we enter the execution order after rendering the last frame, the amount of time that has passed is determined, and from that the engine determines how many times physics should have updated.
So if the physics is running at it’s default 50 times per second, or once every 20 milliseconds. And 43 milliseconds has passed. Then physics is calculated twice (the extra milliseconds are held onto for the next frame).
In a perfect world where your framerate runs perfectly at the same rate as the physics update frequency, then they SHOULD happen one after the other. But that is theoretical and would seldom if ever be witnessed in the real world.
So to answer your question of:
They do all happen just before Update. But they could happen multiple times.
yield WaitForFixedUpdate() could at least allow you to defer work until fixedUpdate occurs, which might be helpful (or not). Generally I just code bearing in mind that there will be never anything synched, regardless. Timing bugs are something you need to get rid of early on.
Also take into account the maximum allowed physics timestep. If the fixed timestep is 20 ms but the max is 50 ms there will still be only 1 fixedupdate but that update will have reduced physics accuracy due to the longer step.
But generally, physics isn’t something you can rely on to do the same every time. The physx library like a lot of general physics library I know about isn’t deterministic, so results may vary (a tiny bit) over time. You may be able to find a deterministic physics library to use, but they’re mostly very specialized.
Because nvidia decided that Physx would not be deterministic for performance reasons, and I assume to align it with running well on GPUs. For now, it runs on CPU with Unity’s implementation but Physx is designed to work with both.
Yes, it wouldn’t be possible for Unity to make it deterministic without getting rid of physx and using something deterministic. Most games do not use deterministic physics.
So, to answer the OP. Using Unity physics is not an option to implement what you want to do. You would need to manage the physics deterministically on your own or used an external library that is built for such usage.