Is there a way, how to get deltaTime in FixedUpdate(), or is there a good reason, why Unity won’t provide the value in FixedUpdate()? As Time.deltaTime is the same as Time.fixedDeltaTime when read in FixedUpdate(), I’m unable to get the value just by reading Time.deltaTime.
What do you want to get out of it? It already tells you the time in between that and the last FixedUpdate.
You are in FixedUpdate. Time.deltaTime is your current delta time, and it makes sense that it is the same as Time.fixedDeltaTime.
Why?
Well, Unity cannot predict the future. Not yet, anyway. 
Keep in mind that Update() runs after FixedUpdate(). There is no way of knowing what deltaTime will be during Update() when you’re still in FixedUpdate, which runs after a fixed time so once deltaTime reaches 0.02s Unity calls FixedUpdate, and sometime before that Update() may or may not have run.
If you really, really badly want deltaTime then accumulate it in Update (accumulate because there may be more than one Update per FixedUpdate) and store it in a field and use that field in FixedUpdate and then reset it in FixedUpdate after you are done using it.
But if you actually do that, things will likely go wrong because Update’s deltaTime has no real meaningful application in FixedUpdate. It’s just some kind of value that tells you the last frame’s Update delta time, but that is in the past, not the current frame. You really don’t want to use that.
Is there a direct way?
No, there isn’t
Why Unity won’t provide the value in FixedUpdate?
Because deltaTime just makes no sense in FixedUpdate. Any usage of the true deltaTime inside FixedUpdate would actually make things worse, always, no exception.
Even though FixedUpdate runs just before Update, it does not run with the same frequency. You may get zero, one or several FixedUpdate calls right before an Update call. So if you would use the true deltaTime, things would not be time dependent.
So whatever your usecase might be, it certainly would abuse the purpose of FixedUpdate. If you really need it for some unorthodox usecase, you may be able to use smoothDeltaTime as I’m not sure if Unity will actually replace that as well when read from FixedUpdate. Though of course this is a smoothed version of deltaTime. Your only other option would be to capture Time.time every frame and calculate the difference between the current and the last time value. Note that Time.time stays constant throughout a frame.
Now I’m using previous frame deltaTime “before” fixed loop. Is this, what you mean by accumulation? I do this by running code from Update or from FixedUpdate depending on what run first in current frame. I’m fully aware of FixedUpdate/Update order.
Can Unity predict future? Probably not, but I kinda don’t have access to Unity source code to see how it’s implemented. It could theoretically work the way, where deltaTime is count on start of frame based on previous frame.
Why? Why not? There’re engines, that runs fixed update after update (Flax for example Script events | Flax Documentation (flaxengine.com)) I want my code to be less dependent on exact engine and I want to have option run “non-fixed update” before also after, not depending on used engine. I give you one example with old input system. New input values are available in time of running of FixedUpdate so I don’t want move player in FixedUpdate based on previous frame input values because it increase control response time by one frame. I want run fixed loop with fresh input values available from start of frame. If some transitions are involved in this case, I need deltaTime to calculate them.
I can’t imagine a scenario where you would need to know the time since the last frame in your FixedUpdate loop. Could you elaborate on exactly what you’re doing?
Read last part of my answer to CodeSmile.
No, you don’t. If you have anything to do with input in FixedUpdate, then you need to drive your input system in FixedUpdate mode.
Apparently you are not aware, but you can have N FixedUpdate call before any Update call. Where N is zero or any positive integer.
Which means you are calculating wrong numbers.
Anyway, obviously you do whatever you like, but this is just completely wrong in Unity.
I did, I read all of it. You didn’t really explain what you’re calculating with the number, you just said you don’t want to use an old number, for something.
In the example case I wrote, I need deltaTime to count transitions of inputs. I want to do it on start of every frame.
No, you probably don’t understand. Let’s say, I want achieve axis behaviour with button. In first FixedUpdate of the frame I read button, and if pressed, axis will increase by “nonFixedDeltaTime * transitionSpeed”. It works perfectly fine, I don’t need to calculate it every FixedUpdate, I’m not talking about transition of object movement, what would be problem of course.
Guys, look at the diagram below “Unity’s Time Logic” Unity - Manual: Time (unity3d.com). See the FixedUpdate “loop” part.
“Is fixedTime behind Time.time by at least one fixed step?” If the diagram is accurate, Unity must know deltaTime in time of execution fixed loop, otherwise they would not be able to do the comparation. It seems they just not provide it to user, or the diagram is just unaccurate.
So what you actually want is running stuff before FixedUpdate not inside FixedUpdate. In that case instead of doing hacky stuff to ensure stuff only happens during first FixedUpdate of current frame you might want to look into custom player loop Unity - Scripting API: PlayerLoop .
You might also want to take a look at the New input system, as it allows customizing when exactly in whole player loop the inputs are updated. Enum InputSettings.UpdateMode | Input System | 1.7.0
It doesn’t even sound like you need deltaTime at all. Why don’t you just increase “axis” if the button is down? It sounds like you already knew you can check input during FixedUpdate. It would not look more complicated than this.
float axis = 0;
void FixedUpdate()
{
if (Input.GetButton("Button"))
axis = Mathf.MoveTowards(axis, maxAxis, transitionSpeed);
else
axis = Mathf.MoveTowards(axis, 0, transitionSpeed);
}
It would do essentially the same thing that you described the code, and even gets around your “1 frame of delay” that you had such a problem with.
If that’s not what you really needed, then it seems like your explanation is not sufficient for me to understand you.
Forget about this. As soon as you subscribe to subclassing MonoBehaviour your code is tied to Unity. You will never ever switch engines and take a good portion of your code with you. That’s just not a thing.
Exactly because the next engine might work quite differently in how it calculates deltaTime. You are making a guess here based on another engine, which itself may be the stranger really. So for all we know you’re actually making your code less portable due to this assumption.
When you use FixedUpdate to drive your characters, they will be physics entities because anything else doesn’t make sense since you would update non-physics entities during Update. Check the Rigidbody component: it has interpolation options. You don’t have to do this yourself.
Also note that FixedUpdate by default runs at 50 Hz. There is nothing stopping you from cramming it up to 120 Hz if you want to - you wouldn’t do deltaTime anymore and most modern computers would be capable of handling this.
And like others have said, with the new input system you have the option to get input in Update, FixedUpdate or your custom timing loop.
If so, then you won’t want to use FixedUpdate(), because FixedUpdate() is not guaranteed to be run on every frame.
Well, if you really want Time.deltaTime in FixedUpdate(), your best choice is to make use of PlayerLoop, which is Unity’s customizable low-level main loop system. You can insert another update function after TimeUpdate (where Unity updates all the time infos), but before FixedUpdate (where MonoBehaviour.FixedUpdate() is been called, of course), and record and cache Time.deltaTime.
Less dependent doesn’t mean independent. I will touch MonoBehaviour only when necessary with use of some level of abstraction. In reality, the only I want from Unity is animation system, rendering, physics simulation and multiplatform build support. All other stuff (entity-component/ecs, serialization, “coroutines”, etc. will be/is part of transferable core. Transition isn’t easy but doable. But I would say, it’s going too far from my question. I just wanted to know, if is possible to get such value. Simple “probably not possible” would be more proper answer, I’m not here to solve if I should use new input system, or to solve any other problem. Sry. All that 50Hz, 120Hz etc. advices, I know all of that, so you are wasting your time a little bit.
…and I don’t want to use deltaTime in FixedUpdate() inproper way, trust me. It’s all about getting another “update event”, lets call it EarlyUpdate and is called on beginning of every frame no matter if FixedUpdate is called or not. It’s done by calling it in FixedUpdate or Update of script, which is set as first script in execution order. I cannot read Time.deltaTime directly of course, I have own TimeManager, where the value is set from previous deltaTime yet. If I could get current deltaTime, it would work even better.
Will I get the deltaTime before fixed loop, if I use this? Yes, my solution is maybe little bit hacky, but easy to implement and it’s causing probably no problems, has no performance cost, as the “hack” need to be done on one place only and once every frame only.
So this is why I have code also in Update().
If I insert update function to PlayerLoop after TimeUpdate to cache deltaTime, It will be still value from previous update, or am I missing something?
To prevent misunderstanding, I don’t need this “EarlyUpdate” event to work in the way that other update events work.
I don’t need execution order sorting or anything. I’m replacing unity entity-component functionalities by custom solution with own priority logic. I need just one “EarlyUpdate” call every frame. I can do it this way or that way. I wrote to this forum just to ask, if can I have the deltaTime (the same deltaTime value I will get in Update) during the time of fixed loop (“during” and “before” is practically the same in this case).
No. You probably should read through this blog as it disects the player loop system in detail. I’m not sure if it’s up-to-date, so make sure you check for yourself what systems and subsystems Unity currently has. I’m pretty sure the time and delta time is actually updated / calculated right in the first native subsystems “PlayerUpdateTime”. Keep in mind that Time.deltaTime is a property which dynamically can return different values depending on the current state and that’s what the property does. So specifically for the FixedUpdate callback it returns fixedDeltaTime for convenience as it makes it easier to move code from update to fixed update or vice versa without any change.
You probably want to hook into some of the “EarlyUpdate” subsystems (or add your own).