Hi, everyone, I was just wondering if there was a way to achieve a LateFixedUpdate() function effect, because I am trying to stay with fixed update for my game, and I need a late update function. All help is appreciated!!! :)
Here's an idea:
I do this with all my code. This is a little confusing if you don't program, but it is actually faster than having lots of Update() calls.
I create an event manager, then have all then have all my class have a psuedo-update function that they add to the event. Then I fire the event and they all get fired.
Unity is single treaded. So if you call a function Unity will finish it before it continues onto its next task. So if you have two events, the second one should be called after the first one is completely finished working similar to a LateFixedUpdate().
Here is a sample:
using System;
using UnityEngine;
using System.Collections;
public class TickManager : MonoBehaviour {
public event Action tick;
public event Action lateTick;
// Use this for initialization
void Start () {
StartCoroutine(FixedTick());
}
IEnumerator FixedTick() {
for(;;) {
if(tick != null)
tick();
if(lateTick != null)
lateTick();
yield return new WaitForFixedUpdate();
}
}
}
This will create 2 events. Then you can have classes register to them.
using System;
using UnityEngine;
using System.Collections;
public class SomeClass : MonoBehaviour {
// Use this for initialization
void Start () {
TickManager eventManager = (TickManager)FindObjectOfType(typeof(TickManager));
tickManager.tick += new Action (Tick);
tickManager.lateTick += new Action(LateTick);
}
void Tick () {
//This will get called as frequently as FixedUpdate
}
void LateTick () {
//This should be called after the first one.
}
}
By the way, if someone more knowledgeable than myself can tell me that my understanding of Unity's threading is completely wrong then please do ;).
EDIT: I managed to get it working with javascript. The first code needs to be in C# because I don't believe you can do events in javascript. But the second code can be in js with the following syntax:
var tickManager : TickManager;
function Start () {
//using function types. Similar to an implicit delegate.
tickManager.tick += Tick;
tickManager.lateTick += LateTick;
//Also supports anonymous functions
tickManager.tick += function() {
Debug.Log("Tick");
};
}
function Tick () {
Debug.Log("Fired on a FixedUpdate interval");
}
function LateTick () {
Debug.Log("Called after the prior method");
}
OP, please unmark the current answer as correct. It is most certainly not correct and folks who come here and read it will get some misinformation.
@Peter G, your understanding of Unity’s threading is partially wrong! All physics operations are running in their own thread which you cannot access. Almost the entirety of Unity with regard to managed scripts is indeed running in a single thread. All SendMessages and MonoBehavior callbacks (except for OnAudioFilterRead which runs on the audio thread) will be run in the main thread.
With your code, you are merely firing an event immediately after FixedUpdate. While indeed it will run after FixedUpdate it will not have the desired effect that OP is looking for and it will not mimic the LateUpdate. In fact, anything that happens in your LateTick would work identically if it were just put in FixedUpdate.
Let me explain:
First, Unity will call all the FixedUpdate methods. At some indeterminate time (and this is why your method wont work) Unity will run the physics tick on the physics thread. Eventually the physics tick will complete and all the Transforms that were affected by it will be updated. Your LateTick will have run before the actual physics tick updated the Transforms.
In reality, there is no 100% solid way to pull off a LateFixedUpdate. The closest thing to a LateFixedUpdate would be a collision callback such as OnCollisionStay. The reason for this is that the OnCollision* method will be called on the Unity main thread after the physics tick has run the simulation and moved all the Transforms.
Just for any beginners reading, if you stumble on to the type of problem outlined in the question here,
the trivial solution is almost always nothing more than using the script execution ordering system.
It’s exactly why Unity added it, and it resolves 99.99% of such issues.
So, the other answers are correctly mentioning all the reasons for which you should not have to do this, and this is fine. However, if you find yourself in a situation where there is a definite need for code to execute after FixedUpdate, the physics timestep and collision/trigger callbacks but before the next FixedUpdate frame, there is a way to do it.
In my case, we needed behaviour that prioritised particular triggers in a complex hitbox system, which required code to execute after all the trigger events. The code could have been pushed to the start of the next fixed update frame but that would potentially result to it executing an actual rendered frame late.
This is indeed possible and is exactly what WaitForFixedUpdate does. The current order of execution of callbacks and the physics step, as of Unity 5.4 and since at least Unity 5.2, is the following:
- FixedUpdate callbacks are executed
- Physics systems are stepped.
- Collision callbacks are executed
- WaitForFixedUpdate coroutine yields return.
- Steps 1-4 are repeated if if several physics steps can fit in the current update step.
- Update callbacks are executed.
Here’s an example on the profiler timeline, with the steps annotated with the fixed frame count:
Also note that this completely contradicts the current Unity documentation. I have consulted with Melv from Unity, who is responsible for the Physics2D system, and this is the intended behaviour. The documentation team has been notified to update the documentation.
The documentation has now been updated to reflect this information. The diagram was modified to show WaitForFixedUpdate returning after the physics update and all collision callbacks. Note that the text has not been modified and still states that it is run after all FixedUpdate calls are done. This should really now be the accepted answer for this, seeing that it actually answers the question.
The best way to implement a late fixedupdate would be to implement a parallel implementation of FixedUpdate either in Update or LateUpdate. Since Update runs after the physics update it would be enough there. However we need some clever tricks to accomplish that.
Basically it would work like this:
// LateFixedUpdateGenerator.cs
using UnityEngine;
public class LateFixedUpdateGenerator : MonoBehaviour
{
int currentFrame = -1;
float lateFixedTime = 0;
void Start()
{
lateFixedTime = Time.fixedTime;
}
void FixedUpdate ()
{
// catchup if FixedUpdate is called several times a frame
if (currentFrame == Time.frameCount)
{
InvokeLateUpdate();
}
currentFrame = Time.frameCount;
}
void Update ()
{
if (Time.fixedTime > lateFixedTime || Time.fixedTime == 0f)
InvokeLateUpdate();
lateFixedTime = Time.fixedTime;
}
void InvokeLateUpdate()
{
lateFixedTime += Time.fixedDeltaTime;
SendMessage("LateFixedUpdate", SendMessageOptions.DontRequireReceiver);
}
}
Just attach that script to a gameobject and other scripts on that game object will receive a LateFixedUpdate. So you can simply implement one like this in other scripts on the same gameobject:
void LateFixedUpdate()
{
// ...
}
The idea is that “Time.fixedTime” represents the current time from the physics systems point of view. If that value is increased a new Physics frame happend. Since we simply keep track of that value, if it hasn’t changed between two frames (Update calls) no FixedUpdate has been called in between.
On the other hand if we enter FixedUpdate for the first time it should happen in a “new frame”. So inside FixedUpdate we can use the frame counter to detect a new frame. However if FixedUpdate is called a second (or third, …) time within the same frame we can detect that and just before the next FixedUpdate is called we quickly call our LastFixedUpdate for the last FixedUpdate call. The only problem is that in the case where FixedUpdate is called multiple times in a frame, the Time.fixedTime value inside LateFixedUpdate doesn’t match the value it was in the corresponding FixedUpdate. Only the last call will match.
For example:
// method fixedTime
// -----------------------------------
// FixedUpdate 5.0
// LateFixedUpdate 5.0
// Update 5.0
//
// FixedUpdate 5.2
// LateFixedUpdate 5.4 <-- wrong
// FixedUpdate 5.4
// LateFixedUpdate 5.4 <-- correct
// Update 5.0
//
Besides that little problem, everything else shoud work as expected. So the position should be updated in LateFixedUpdate.
Of course you need to set the execution order of the “LateFixedUpdateGenerator” before the normal time:
