Unity Fixed timestep features coming to Entities / DOTS Physics packages

Hi. I implemented my own FixedSimulationGroup which is injected to FixedUpdate of PlayerLoop.

Is there any reason for that Unity not using just existing FixedUpdate loop? I think that it is more simple and can easily be integrated with existing PhysX based components (hybrid).

 

Sounds fantastic, thanks for update.

 

Seems like we will need to choose between:

1. Jerky motions to have proper frame-rate independent simulation
2. Frame-rate dependent simulation to not have jerky motions

Isn't it possible to have something that supports something like Rigidbody Interpolation at all?

 

I think that's a physics implementation detail and thus not subject of this fixed timestep system. The physics systems probably will, or already do that.

My question is, why the odd default? I mean the built-in PhysX system runs on 1/50. Is there any consideration behind it? Or do you expect to be the 60FPS the standard and don't expect that the physics would handle the interpolation? (Well, maybe the above question isn't that clean cut after all?)

Would it be possible to define our own fixed-step simulations (multiple) on different fixed time-step? Or it is not the plan at first?

 

It doesn't seem like as previously stated:

But I may have misunderstood the situation.

 

In other words, all components used in building physics world and being exported as result will be updated from "catch up" to "catch up" update?

Does this still apply if the one is using manual InputSystem update? If I remember correctly, somewhere on forum has been mentioned that update provides an access to a buffer of all the input that occurred since the last call, so having that in mind it sounds that there should not be an issue, unless someone desires to have "less precise" update relaying on frame-rate rather then real-time update.

 

In any case, rigidbody interpolation is a fairly simple feature to implement:

• remember current & previous pos/rot of the transform at every fixed update
• at every variable update:
  • float t = timeSinceLastFixedUpdate / fixedTimeStep;
  • pos = math.lerp(prevFixedUpdatePos, currentFixedUpdatePos, t)
  • rot = quaternion.slerp(prevFixedUpdateRot, currentFixedUpdateRot, t)

Or something like that. Someone could probably release a simple system that does that soon after the fixedUpdate feature lands

 

Another possible decision factor is that you can't have exactly 60 Hz. Timestep would be 0.01666667, which translates to 59.99999 Hz. Physics must be as deterministic as possible, and you can achieve exactly 50 Hz with timestep = 0.02.

Not surprisingly, many monitors with "60 Hz" refresh rates are actually 59.94 Hz and sometimes even plainly displayed as 59 Hz. I'd be against setting the physics default rate to 60 Hz because calculations won't be as precise as with 50 Hz, and in practice you'll never have a 1:1 correspondence with the monitor refresh rate. For example, think that just drifting one frame out of those 60 frame per second mean one visual stutter per second.

In my opinion a correct solution forcefully requires interpolation. Choose a timestep that doesn't involve periodic decimals for precise calculations, and let the interpolation provide the visually smooth results.

 

Interesting approach! Thanks for the update on this, and, despite what I am saying below, I like the approach and transparency.

I do admit that it seems a lot more complicated than before (pre-DOTS), though.

And of the options you list, I will basically have to pick the last one. Frame rate affecting simulation speed is an absolute no-go and feels like a throwback to old game design that's really, really bad (like old racing games that are so difficult to play at current framerates), while jerykness doesn't seem ideal either.

That said, having the option is good, because the option means entirely different use caes will work. Single player games that probably don't care for determinism (as there's no need to sync anything) will probably default to the third option, won't they? Or am I misunderstanding something here? I'd love to hear if my logic has a huge flaw!

I can't imagine a single scenario *in a single-player game* where I would even care for determinism, especially if the cost for it is "frame rate affects simulation speed".

 

• We have separated our server / client logic into a Server world and a Client world.
• A game client will be able to run both worlds simultaneously.
• Each world would preferrably be able to have individual fixed frame rates (server update rate can be much lower)

Would this be possible with the planned approach? The FixedStepSimulationSystemGroup would have be non-static for that to be supported, is that the case? Or is it a static field, used for all instances of FixedStepSimulationSystemGroup?

 

please don't do that ,in order to fixedupdate or separate simulation and presentation ,I just need to set world.quite update to true ,and update the three group :initialize,simulation,present my self。Actually,I have made a game use DOTS this way ,and it worked fine.

Code (CSharp):

1.     public void Update()
2.     {
3.         if (!LoadComplete)
4.             throw new Exception("BattleWorld has not been Initialized ,check value: BattleWorld." + nameof(LoadComplete));
5.  
6.         m_AccumulateTime += UnityEngine.Time.deltaTime;
7.         m_World.QuitUpdate = false;
8.  
9.  
10.         while (m_AccumulateTime > ConstantsOfWorld.FixedDeltaTime)
11.         {
12.             m_InitializationSystemGroup.Update();
13.             m_SimulationSystemGroup.Update();
14.             CheckEnd();
15.             m_AccumulateTime -= ConstantsOfWorld.FixedDeltaTime;
16.         }
17.  
18.  
19.         m_World.GetExistingSystem<TransformPresentationSystem>().DeltaTime = m_AccumulateTime;
20.         m_PresentationSystemGroup.Update();
21.         m_World.QuitUpdate = true;
22.     }

 

why your guys spend time do the meaningless thing,when do you fixed the world memory leak problem. until now,there is even not exist a simple way to convert array of prefabs to entity prefabs...

 

Except 0.2 isn't really a precise floating point number, either. The literal 0.2f will actually be 0.200000003 in single precision IEEE754, aka float.

 

What about 0.02f?

 

Ooops, good find, same problem, but the error is outside the Mantissa limit, so it doesn't really show up in float.

 

I testet in an online converter, it was: 0.0199999995529651641845703125

 

That looks like a double to me, not a float.

EDIT: Anyways you're right @Thygrrr, 0.02f doesn't mean anything different in precision. I've just tested this code:

Code (CSharp):

1. float f = 0.0f;
2. for (int i=0; i<50; i++) f += 0.02f;
3. Debug.Log(f);
4.  

And the result is 0.9999996, not 1.

If all, this enforces the need for visual interpolation. Without it, not even setting the default physics rate to ~60Hz could guarantee reasonably stutter free motion.

 

The floating point precision problem.
A good way to play around with it: https://www.h-schmidt.net/FloatConverter/IEEE754.html

Regarding the imprecision in time steps, it doesn't realy matter as long as you use a float value relatively. Where it starts to get problematic is when we apply human measurement logic and expect something to be 1. But for Physics, as long as the relative time steps are the same there shouldn't be a problem.

It's an interesting topic but for physics determinism, timestep is a non-issue, well, as long as the float fixedDeltaTime is the same on every architecture which IS a big factor and I'm only describing it as non-issue because Unity will handle this problem for us.
The biggest issue in physics determinism is using RNG for solvers like a contact solver. New Physics frameworks are now avoiding RNG for that specific reason. For offline calculations RNG would still be valid, it's just not usable for anything networked.

On topic:
I'm pretty happy with the new PlayerLoop logic, Time and UpdateCallback. Implementing any kind of time stepping is now possible on a global scale or even in ordered system groups and not as annoying and problematic with scaling than in MonoBehaviours.

I'd just like more full examples and tests on your docs website. Just look at this page: https://docs.unity3d.com/ScriptReference/LowLevel.PlayerLoop.html
or
https://docs.unity3d.com/ScriptReference/LowLevel.PlayerLoop.SetPlayerLoop.html
Pretty much zero info.

Gathering the info how to do things, I needed to go through the ECS package source code, which has a staggering amount of cool tests you can learn from by the way.
What I still don't understand is the purpose of PushTime and PopTime. They are used in the FixedRateUtils and TBH I still don't get what this actually does compared to just SetTime.

 

Last time (it's been a while) I checked FixedRateUtils, there wasn't any failsafe for CPU starvation if you used the fixed timesteps with it. If this is still the case, I do hope Unity will address it in some way. I do get it does bring up issues with determinism but then again, so does your client freezing when not being able to keep up..

 

This is something I've been meaning to look into a little in the Physics package, but Glenn Fiedler wrote a really insightful article titled Fix Your Timestep! where he explains how to get rid of the stutter that's caused by a framerate < fixed update. This could be included as a fix on the physics package itself where it correctly interpolates the transform components based on the physics state that's maintained. This does mean that the physics package will be maintaining its own copy of the transform data and there has been some concern expressed over this data duplication in other threads as well.

I'll be honest and say I quite like this approach, but it comes with the added complexity that might not be suited to everybody's needs. I think one thing that DOTS is unearthing is just how complex an engine can be because people are now able to access more in-depth data which is leading to some level of confusion for those who treated everything more like a black box.

 

I feel like this new DOTS physics setup is pretty much the same as the old monobehaviour physics setup.

In monobehaviour physics, if you move a transform.position and then try to access the rigidbody.position later in the same frame, the rigidbody.position will not have moved like the transform.position. It'll stay different until either the next frame or a manual sync of transforms. If I'm not mistaken, interpolation also only affects the transform.position and not the rigidbody.position. So the monobehaviour physics does keep two separate transform datas too. It just tries to conceal it more, which was the source of many headaches for me when I wasn't aware of how things really worked

In the end they both do the same thing, and the out-of-the-box fixed timestep DOTS physics would be a direct equivalent of monobehaviour physics with interpolation turned off on rigidbodies. All that is needed is the addition of an interpolation system like this, and you'll end up with the same functionality as old physics

 

I appreciate this direction. There's no one-true way to avoid stutter -- each game has to make the choice for itself.

Interpolation is attractive, but requires an extra frame of input latency, which is not great for many certain games (ie. VR or competitive shooters). Extrapolation solves that, but can create jutter via mispredictions.

Additionally, whether or not VSync is enabled is critical -- if VSync is on, even variable time steps will create jutter if the monitor's frame rate is not matched with the simulation rate. The monitor will always present 60Hz, but if the game is calculating time steps at any other rate (as the frame time fluctuates), you're going to see jutter.

 

Why rebuild the update loop?
Couldn't the new 'FixedStepSimulationSystemGroup' just be updated from Unity's FixedUpdate PlayerLoop?
https://docs.unity3d.com/ScriptReference/LowLevel.PlayerLoop.html

 

I think it's because that's coupled with the UnityEngine runtime. They're making everything work with a new DOTS runtime (currently used by project tiny)

 

newbie here, how to use FixedStepSimulationSystemGroup ? small code example would be much appreciated

 

@tommox86

FixedStepSimulationSystemGroup

is part of the Entities 0.12.0-preview release that isn't yet available from what I can see. As soon as it's available you should be able to play around with it, but it will essentially entail something like the following:

Code (CSharp):

1. [UpdateInGroup(typeof(FixedStepSimulationSystemGroup))]
2. class YourSystem: SystemBase
3. {
4.     //system code here
5. }

 

Hey @cort_of_unity, thanks for the in depth insight on that. Our current setup is that we have a server running a fixed simulation at around 10 fps (fixed timestep with catchup). The client is running the same for his client side prediction, but it is synchronized and will slow down / tick faster (without changing the fixed timestep) in case it needs to resync with the server.

Right now I've got my own FixedSimulationGroup that does all of the above, and which is built around the new ComponentSystemGroup.UpdateCallback.

I'm in the middle of adding physics and I'd like to make it tick on my custom FixedSimulationGroup (which may behave slighly differently of the one that will be builtin).

- can this be done with the current release?
- what about the next release? what would be easier / more robust?

- why such code in StepPhysicsWorld.cs?

Code (CSharp):

1. #if !UNITY_DOTSPLAYER
2.             float timeStep = UnityEngine.Time.fixedDeltaTime;
3. #else
4.             float timeStep = Time.DeltaTime;
5. #endif

- somewhat unrelated, or maybe not... the StepPhysicsWorld System is taking a whole 3ms on my machine as soon as I add one single rigidbody. Is that expected behaviour? Does it scale well?

- is there an ETA for 0.12 + updated physics (I might have missed that from the thread)

Thank you for your help, that's very much appreciated!
Best,

 

Will the physics systems be refactored to optimize for iterating multiple times in a frame? Right now physics step/build flow all together is pretty expensive in terms of main thread usage. If this requires running the whole step/build flow multiple times and isn't refactored in some areas it's going to be a pretty big hit.

I'm also curious why not an option for an actual variable timestep with physics always ticking once per frame? I would ask at least make it possible without source level modifications.

 

Or is that what option 3 is? Maybe I was just reading it wrong. I was thinking specifically the variable timestep is some multiple of the fixed timestep. So you accumulate time to sort that out. Which is a different thing then just going by real elapsed time only.

 

So how would you configure variable timestep in Entities 0.13?

 

Where can I find the sample referenced in the entities 12 changelog?
It's called FixedTimestepSystemUpdate sample scene there.

 

Just for the record, regarding DOTS and interpolation, here's an experiment made by a Unity developer:

More comments on this:
https://twitter.com/melvmay/status/1227675981122592768

 

Interpolation as it's normally handled makes velocity a write only construct which really sucks.

I think what is better is some notion of real and effective motion data. For position, rotation, and velocity. I like the idea of that being very explicit and it's always what it is. You never have to ask has this been interpolated. Real never is and effective always is, at all times everywhere.

I also don't see a reason to involve the transform system for dynamic and kinematic bodies. They don't have hierarchy. I can't think of any reason why not to just update LocalToWorld in export physics. With that and real/effective values I think you can always have a consistent view of the data. No gap between physics and the transform group where it's not consistent.

- Build the physics world
- Game logic changes to physics bodies
- step/export physics world.
- remaining game logic. Physics data and transforms are synced at this point
- end frame physics system

This gets a bit beyond the topic of this thread but the transform and rendering sytsems have forced sync points, so there is good reason to not include them if you don't have to. Why we don't stack rendering components on physics bodies. If you remove the transform system from the picture for dynamic/kinematic bodies it's one more DOTS forced sync point removed.

 

Seems this is still the case in 0.4.1
The bottom one refers to World.Time so that is correct, but afaik UNITY_DOTSPLAYER isn't usually enabled (only meant for project Tiny?), so by default it is still incorrect if your fixedDeltaTime doesn't match the update rate. Shouldn't this be using World.Time regardless?

Maybe this is an oversight since it's being moved to a fixedrate group (and thus should be in sync with fixedDeltaTime?), but it'll be incorrect if you are manually stepping physics at a different rate, for example in custom worlds.

 

Hey @cort_of_unity, could you update us on the current status of the feature?
Best

 

What if I want to have an update that happens before FixedStepSimulationSystemGroup but at a fixed time step? Would that be possible?

Would the code below update after FixedStepSimulationSystemGroup using a fixed rate?

[ExecuteAlways]
[UpdateInGroup(typeof(SimulationSystemGroup), OrderLast= true)]
[UpdateAfter(typeof(BeginSimulationEntityCommandBufferSystem))]
public class lateFixedUpdate: ComponentSystemGroup

 

I hit this problem today in my network code. Having a networktick rate 1 / 30 and that system doing 1 /60 gives troubles of stuff not syncing correctly. In other words i want to move all the physics systems into my new fixedtimestep group.

 

I'm sifting through this thread and older info online. I was excited to learn that I can access the fixed time in the simulation group. I just wanted to make sure I'm doing this correctly. I'm just checking these values in different systems:

Code (CSharp):

1. Debug.Log("fixed time: " + UnityEngine.Time.fixedTime.ToString());
2. Debug.Log("fixed delta time: " + UnityEngine.Time.fixedDeltaTime.ToString());
3. Debug.Log("in fixed time step? " + UnityEngine.Time.inFixedTimeStep.ToString());

The output looks roughly like this:

fixed time: 6.6

fixed delta time: 0.02

in fixed time step? false

This even seems to work in the initialization group. Should the `inFixedTimeStep` bool being false be concerning at all? Also, I've noticed in the log that sometimes the value doesn't actually update, as in, there can be 3-4 log messages saying `fixed time: 6.6`. Is that normal? Do I need to manually detect times when the loop executes again but the time hasn't advanced?