Is it possible to set the fixedDeltaTime to a value independent of FixedUpdate’s rate?
If so, where and how?
Is it possible to set the fixedDeltaTime to a value independent of FixedUpdate’s rate?
If so, where and how?
FixedUpdate runs on the fixedTime, why do you have this need?
In the original post of this thread: https://discussions.unity.com/t/661750
… there is discussion of manual simulation. I’m wanting to do that, but divorced from the FixedUpdate() rate, by means of a different fixedDeltaTime… I presume.
Way down this thread, you’ll see some dribble from me.
No. The FixedUpdate frequency is driven by Time.fixedDeltaTime.
The documentation shows you how to run the simulation manually here and shows you an example of performing the simulation using Time.fixedDeltaTime updates. If you simply want to use the delta-frame-time then as I said in the thread you referred to then simply perform the following in the Update callback:
private void Update()
{
Physics2D.Simulate(Time.deltaTime);
}
You can add this to any GameObject in your scene. If you want you can also control the order this Update is called in relation to other scripts then you can use Script Exectution Order Settings.
You should try to be more clear though. Saying you want to do manual simulation just means you want to do so in script. You don’t specify if you want to do so in fixed-update or frame-delta so I just assumed you wanted frame-delta.
Doesn’t this just change one dependency to another?
In this, you’re simply changing the frequency of the manual simulation to that of the Update() as opposed to the FixedUpdate().
What if I want the manual simulation to occur at a faster rate than both of these things?
Sound like you want to set the fixed delta time to epsilon, haha
You might wanna tell us what you’re trying to achieve.
I have no idea what that means. You have two choices for event functions in your scripts: FixedUpdate (executed at a fixed frequency of your choosing) or Update (executed each frame). These are not dependencies, they are your only choices.
As I said, you’ve only said you want to do the simulation manually and I showed you how to do that but you’re following up with odd statements. What is it that you want?
That’s a vague thing to ask TBH. You can step the simulation in whatever time-delta you wish either by manually doing this per-frame or using auto-simulation which runs in the fixed-update and change the fixed-update frequency to whatever you like.
I agree. I’ve already told you the above several times now so unless you can provide a clear explanation of what it is you want then I’m not sure I can help you further even though I’d like to.
BTW: You mentioned you’re fairly new to Unity so have you tried reading through the scripting overview? Look at execution order and event functions in particular.
I’m sorry if my understanding is failing…
I want manual simulation to occur faster than Update() and faster than fixedUpdate().
For the sake of discussion, let’s assume I want manual simulation to occur 4x faster than either of these, and that they’re both at 60fps.
Can this be done?
How?
As I said here and in the other thread. Set the fixed-update to whatever you like in the TimeManager settings!!!
The thing is, if you set the fixed-update to 240Hz and you have your rendering locked to 60Hz then it cannot call the fixed-update at 240Hz as it’ll only ever be called at 60Hz (the game engine is a big synchronous loop in the end) but the example loop you were saying doesn’t work (in the other thread) would call it 4 times so it keeps up with game time.
Let me spell this out:
I want FixedUpdate and Update to occur at 60fps… both of them.
I want to manually simulate the physics at 240hz.
Is this possible?
And, yes, I realise that the Update is locked to 60Hz, that’s the dependency I was talking about before… you simply swapped the dependency/reliance (choose your fav word here) of the manual simulation from the FixedUpdate to Update, in your previous example.
I’m wanting manual simulation to be independent of both the Unity Updates, and to run at much faster than both of them.
There are only Update and FixedUpdate callbacks in Unity to perform periodic actions as described in the link I have you on execution orders and events. You are asking about manual simulation, for no apparent reason why you have to do it manually rather than let Unity do it at a fixed frequency you specify.
Sorry but you just keep asking the same question which I have answered and I cannot think of another way of providing it. I’ve already repeated myself several times.
Perhaps I missed it.
Are you saying it is NOT possible to run manual simulation updates at 240hz whilst fixedUpdate and Update run at 60hz?
There you go: https://discussions.unity.com/t/698428/11
And it’d be really good to know why you want manual simulation as you’ve still not said why.
I’d like manual simulation as I desire/need much faster simulation than I want/need FixedUpdate().
For one thing, I’d like OnCollisionEnter and OnTriggerEnter to be operating at 240hz, whilst FixedUpdate() and Update operate at 120Hz or 60Hz. I want to push and exploit the newer iPad Pros for a very fast ball based game.
Why are you so set on the frequency of FixedUpdate and Update to be the same? What purpose would that serve? As I’ve said several times now, FixedUpdate is for performing a periodic update decoupled from the frame-rate but you seem to be ignoring that and artifically limiting it to be the same as Update.
You do not need to perform manual simulation to control the update frequency of the physics.
Unity does not provide some asynchronous callback at an arbitrary frequency. I can easily set-up physics to run in steps of 1/240 whilst the frame-rate is some other arbitrary value and do so as I’ve described a few times and do so without performing manual simulation.
Maybe with a little experimentation of your own and following the info I’ve provided you can come to the same conclusion yourself. Beyond that, not sure what else I can provide to help you.
Because:
A. I’m doing a lot of stuff in FixedUpdate that’s not necessary at faster than 60Hz, but is a bit of a drain when done at 240Hz… so I’d hoped to be able to set Simulation to be the only thing happening faster… where and when and upon what I need/desire it…
and
B. I got excited about the prospect of four things
and…
4) Mobile devices running on batteries having great physics, efficiently
So if FixedUpdate is always running at 60Hz and for some reason you have to simulate physics at 240Hz, that doesn’t mean you have to physically call Simulate at 240Hz. In your FixedUpdate, simply call it four times with 1/240 as the delta-time.
I’ve yet to come across a situation where running 2D physics at such a high frequency has any benefit beyond what increasing the solver iteration count does and indeed, so called accuracy doesn’t increase much beyond a certain point. It’s much more expensive to do this and 240Hz sounds like some arbitrary high processing rate.
Also, you say you’re doing stuff in FixedUpdate at 60Hz and also the same rate in Update but that simply means you can do the same stuff in Update and leave FixedUpdate for physics. It really sounds like you’re putting some odd limitations on yourself here.
Anyway, the above is the answer so I’ll leave it there.
Running physics at 240Hz is an opposing force (no pun intended) to a mobile device running on batteries. You’re adding extra CPU load by doing this.