I’m manually calling physics.simulate each frame because I want a deterministic game. But I use a bunch of assets from the store because I’m no programmer and they will use time.deltatime. What will the result of this be? Will delta time use the fixed step value I use with physics.simulate or will it still use the real time between frames?
If so, what can I do about it?
I don’t follow. Physics.Simulate is just you asking to simulated the physics scene. It has no relationship whatsoever with time. Maybe you’re confusing scripts that use the FixedUpdate with physics. Physics is only one system that uses FixedUpdate; animation and other stuff uses it too but granted, physics is the one that mosts devs talk about.
The callbacks you get are NOT physics related. What you do in them might of course. They are simply a callback that Unity makes. If you have other scripts that do work in it then they’ll still work whether you call the simulation step or not.
If you use scripts that assume physics is running during the FixedUpdate but isn’t because you’re manually stepping it some other time then no, they won’t work given their assumptions. Maybe they’ll sort of work but if they ask physics to do something, it won’t get actioned until the simulation runs when you run it manually. The actual details are down to what they are asking to be done etc.
Maybe you have a specific example because the above is all a bit hand-wavy.
Sorry, I don’t have any example since this is something I just considered as a problem that will come up in the future. But I think you got it, I meant when you use delta time with physics. But I also want other things that can use delta time to be deterministic, like shaders for example.
So a better question might be; Is it possible to tell Unity to always return the step value (from my manual physics call) whenever time.deltatime is called from any script in the project?
About the fixed update not being called, I don’t know what to ask to get around that problem.
Sorry, I just don’t follow the question. “called from any script” or “return the step value (from my manual physics call)” don’t mean anything specific. What’s a “manual physics call”?
Could you use some real Unity things here as an example, maybe a script? Just not terms like “physics call” etc.
No I don’t like asking about specifics since I want to learn what makes this work and then apply that to any specific issue that might happen.
What’s unclear about manually do a physics call? That’s what it says in the manual about Physics.Simulate.
What I do is I run this script every frame.
using UnityEngine;
public class Physics_update : MonoBehaviour
{
public float step;
void Update_physics()
{
Physics.Simulate(step);
}
}
Step is set close to 60fps which the game is capped at. If I do this the manual says I get deterministic physics.
However, I think that anything that’s using Time.deltaTime will still be nondeterministic, correct? And since I use 3rd party assets for lots of things there will be many such cases. It could be anything from moving objects to animations.
So if I understand this correct, if Time.deltaTime were to always return the same value, then it would be deterministic.
So I want something to override the value you get from Time.deltaTime and instead use the step value in the script above so everything matches the physics update.
Changing every instance of Time.deltaTime in every script to the step variable is not very possible so I wonder how to do this.
Or if I completely misunderstood how this works I would like to know too.
Without a specific question, you won’t get a specific answer. If you’re looking for comprehensive general details then you’re not going to get all that on a forum because this is what tutorials and other material is for. Expecting people to help without being specific isn’t going to work.
I don’t know why you’re asking me that. I said I didn’t follow what you were asking because it didn’t make sense as a question I can understand because you’re using your own terms which only mean things to you. If you want me to help you, I need to understand what you’re asking.
Not 100% deterministic no because floating-point differences on devices but it’ll be consistently called on all devices on average at the fixed rate yes so determinism will be as high as it can be given those limitations.
Correct, a variable time-step means no level of determinism but not just for physics but for anything that is frame-rate dependent.
Ignoring floating-point differences on devices, it’ll be consistent on average yes.
I have absolutely no idea why you want to do this although I can see you do. You’re saying how do I change how code runs in other 3rd party scripts and apart from changing their source, there is no way.
You seem to be under the impression that FixedUpdate and/or Time.deltaTime is driven by physics which is incorrect. The game/project is mostly driven by Time itself. All things you use that are driven by time should continue to work. If you want to update your physics to run (say) at half the current time and you don’t want to scale down the global time then no, there’s no way to tell everything else in Unity to use this because they’re not driven by physics but driven by the global time. It just sounds like you’re asking to invert what’s driving 3rd party scripts.
@MelvMay Ok, this is how I was thinking about all this. In the manual it says if you disable auto simulate and then use physics.simulate with a fixed time step you get deterministic physics. But if you use an asset that uses the physics engine you are probably 99% guaranteed that delta time is used, making everything nondeterministic anyway. The same goes for animations or anything really, nothing will be deterministic unless you program everything yourself.
So I thought the simplest way to fix this would be to tell Unity that when auto simulate is disabled, delta time should always be the same value as the step value you use with physics.simulate. That way you can use everything as it is without any changes and still have everything deterministic. Above you say that giving delta time a fixed value will make things deterministic with some exceptions so this should probably work in theory.
Is my reasoning completely off here? How would you make a deterministic game without programming everything yourself? If that’s not possible, wouldn’t that make disabling auto simulate mostly pointless?
I don’t know why you would think 99% of 4rd party physics things would use a variable time-step for physics. Most things use fixed delta-time. Personally, I don’t like conversations about “things” which is why I’m trying to ask what specific “thing” you mean.
You mention animations but when did use fixed delta-time? hey are visuals only, they are frame-based nearly always. What’s the problem here?
Also, you switch between Time.deltaTime and Time.fixedDeltaTime in your comments so you need to be clear on which you mean.
I’m wondering if you think that FixedUpdate is some magic bullet that gives you 100% determinism, it doesn’t. It can improve determinism or at least consistency but it doesn’t do that; in the end, it’s driven by the frame-rates on the local device. Where is determinism important to you; specifically?
I don’t understand what is broken. I’m not sure you have an actual real example that you can show me or if this is just off-the-top of your head worry because of some misunderstanding. I just don’t know. It’s clear there’s a problem in your head, just not mine.
I just don’t follow what your worry is nor if you’re hitting a real problem here or if you’re just worrying “just in-case”. The fact that you don’t discuss this in some specific tangible way makes me believe this is just worrying/misunderstanding.
Might a 3rd party physics “thing” be expecting auto-simulation at a fixed-update? Maybe. I don’t know which specific “thing” you mean. Wondering if manually simulating is pointless because of these speculative things isn’t something I can advise you on.
Get your 3rd party thing. Try it. Does it work? Anything else is speculation and I cannot help you on that.
Sorry if I didn’t answer your question and went all over the placed but I feel your questions are quite nebulous not something I feel I can answer.
When Physics.autoSimulation is false and you call Physics.Simulate(timestep) then only the Unity internal physics calculation is performed, and it will use the timestep you’ve feed it with. FixedUpdate is not invoked when you call Physics.Simulate. FixedUpdate is still called by Unity at the rate defined at Time > Fixed Timestep.
When read from within FixedUpdate then Time.deltaTime always returns the fixed timestep configured in Time > Fixed Timestep (that is, Time.fixedDeltaTime). Assets that are properly designed use FixedUpdate for their physics and and logic calculations, while they use Update for the visual stuff.
However, here comes the tricky part:
- When Physics.autoSimulation is true then there’s an internal physics update after each FixedUpdate event, so scripts can rely on that.
- When Physics.autoSimulation is false then FixedUpdate is still called at the rate defined by Time > Fixed Timestep, regardless you’ve called Physics.Simulate() or not. So assets that rely in the internal physics update being called after each FixedUpdate call (likely all assets) will likely misbehave. There might be two internal physics updates between each FixedUpdate call, or two FixedUpdate calls between each internal physics update.
A possible way to keep those assets happy would be ensuring to call Physics.Simulate() right after each FixedUpdate call. You may do so by calling Physics.Simulate(Time.deltaTime) from FixedUpdate in a script with its Execution Order configured to execute after all other scripts. However, this would be no different than simply leaving Physics.autoSimulation=true!
Some references for learning more on this:
https://docs.unity3d.com/ScriptReference/Physics.Simulate.html
https://docs.unity3d.com/ScriptReference/Physics-autoSimulation.html
https://docs.unity3d.com/Manual/ExecutionOrder.html
1 Like
Yo thanks for this explanation. It made everything make more sense. But there are some confusing things.
[quote=“Edy, post:9, topic: 894755, username:Edy”]
When Physics.autoSimulation is false and you call Physics.Simulate(timestep) then only the Unity internal physics calculation is performed, and it will use the timestep you’ve feed it with. FixedUpdate is not invoked when you call Physics.Simulate. FixedUpdate is still called by Unity at the rate defined at Time > Fixed Timestep.
[/quote]So if I got this correctly, what you say is that FixedUpdate will run on the realtime interval I set in the time options as normal, but it will use my (Physics.Simulate) timestep for calculations instead of the time between frames?
[quote]
When read from within FixedUpdate then Time.deltaTime always returns the fixed timestep configured in Time > Fixed Timestep (that is, Time.fixedDeltaTime). Assets that are properly designed use FixedUpdate for their physics and and logic calculations, while they use Update for the visual stuff.
[/quote]Then this should be a non issue if I set fixed timestep to the same value as the Physics.Simulate timestep?
[quote]
However, here comes the tricky part:
- When Physics.autoSimulation is true then there’s an internal physics update after each FixedUpdate event, so scripts can rely on that.
- When Physics.autoSimulation is false then FixedUpdate is still called at the rate defined by Time > Fixed Timestep, regardless you’ve called Physics.Simulate() or not. So assets that rely in the internal physics update being called after each FixedUpdate call (likely all assets) will likely misbehave. There might be two internal physics updates between each FixedUpdate call, or two FixedUpdate calls between each internal physics update.
[/quote]Since it’s not possible divide 1/60 (I want it to run at 60fps) I have to round the timestep value. If I for example round it so it becomes slightly higher than 60, that would mean FixedUpdate will be called twice every X frame, right?
Why is this a problem if I only call Physics.Simulate once per frame? Will it still do all the calculations in the first call, then do them again meaning for that frame everything will move twice as fast?
If so, is there a way to make FixedUpdate run max once per frame?
[quote]
A possible way to keep those assets happy would be ensuring to call Physics.Simulate() right after each FixedUpdate call. You may do so by calling Physics.Simulate(Time.deltaTime) from FixedUpdate in a script with its Execution Order configured to execute after all other scripts. However, this would be no different than simply leaving Physics.autoSimulation=true!
[/quote]Then this is not an option since I want the game deterministic enough to be able to record demos and have them replayed without desyncing.
if you call it every frame, your physics results won’t be deterministic anymore, because framerates aren’t deterministic.