Why is Simulation the default system group?

In regular Unity you use Update for the game logic while FixedUpdate is recommended for physics-related things. Is this different in ECS? Why?

 

I'm guessing the ECS team feels that (at least for now) most ECS systems will involve pure calculations rather than rendering stuff. And in general, we should use fixed timestamp for pure calc and use Update for input and rendering-related stuff. Again just a guess.

 

ECS has no physics API yet.

ECS is pretty good at rendering stuff. Specially thousands of objects. That significant advantage over Classic OOP.

 

I wasn't saying ECS is good or bad at rendering, just that the amount of math code may be prioritized over rendering code. Hence the preference of SimulationSystemGroup as the default over PresentationSystemGroup.

 

That is not necessary true. At least not for every case.
Yes you can use ECS, for math heavy applications, which is fine and you will be right.
But you can use ECS as well, just to render 100s Thousands of entities, with little to none math. Something which isn't feasible in Classic OOP otherwise.
That is why I said

 

I think by using opinionated naming like that it encourage you to think about simulation and rendering separately rather than simulation THEN render. Previously I don't want to touch fixed update since it was known for physics stuff. Now I am tempted to calculate in that phase since putting everything in presentation now sounds wrong.

 

I didn't understand the context of this. I just realized it now that I'm upgrading.

 

Thanks for the detailed explanation, I really like the direction in which this is going. I'd like to say 3 things:

1. I don't feel like we'd need an automagical solution for interpolating things in the presentation world between simulation world updates (not sure if this is what you were suggesting). This sort of thing is arguably better done manually by users (aside maybe from default components that would provide basic transform interpolation for users who want it), and besides we already need to deal with this kind of stuff with rigidbodies and interpolation in legacy Unity
2. In my experiments with making an ECS Physics engine and an ECS Online game framework, I've very often found the need to be able to easily call MyUpdateGroup.Update() manually. I think this would be a good feature to have built-into the ECS. Right now it's possible to store systems in a list somewhere and iterate on it and call Update() for each, but having a function that Updates all in a specific group would be much better from a UX perspective. It would save programmers from having to manually register systems in lists instead of simuply using the [UpdateInGroup] method. This sort of thing is pertinent for when we need to call a bunch of systems potentially multiple times per frame.
3. Another issue I've run into is that there are times where you want multiple different FixedUpdates running simultaneously but at different timesteps. It would help a lot if users had the possibility to declare multiple FixedUpdates easily in the PlayerLoop, and then subscribe their systems to those new FixedUpdates. For example in an online game, you may want non-networked physics rigidbodies to be simulated at 50fps like they are by default in Unity, but you'd also want a different FixedUpdate running at 30fps that simulates your networked gameplay code (aka the "tickrate"). In this case, the non-networked rigidbodies would be purely aesthetic and would not affect player movement/projectiles/etc... Player ragdolls in Halo Reach are an example of this.

These are just a few things that I feel would make the ECS more useable in a wider range of scenarios

 

Thanks for the insights. Splitting logic from interpolated rendering was something I used to do from 20 years ago up until Unity came around so it's not a new concept, but I really appreciate splitting logic (simulation) from rendering.

Keeping things in sync however for rendering and logic is tricky with things like the the animator, because often animation will be used to position a collider (on a sword for example), so we would probably want to animate things in sim as well, before somehow interpolating it, or doing the work sort of twice...

 

@cort_unity Hi, is this correct that I can't use FixedUpdate loop for my ComponentSystems until the future version of Entities be ready?

 

So what would [UpdateInGroup(typeof(UnityEngine.Experimental.PlayerLoop.FixedUpdate))] do to a system's scheduling?

 

Same question as @johnabruce In context of preview27, what's the recommended way to have a system update with fixed timestamp?

[UpdateInGroup(typeof(UnityEngine.Experimental.PlayerLoop.FixedUpdate))] ? Or, manual initialization like @cort_unity just said?

 

Thanks for the fast answer. you may want to throw an update to the docs here then to avoid confusion:
https://github.com/Unity-Technologi.../master/Documentation~/system_update_order.md

 

Thanks : https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/system_update_order.html

 

Here is my temporary solution for fixed time step update.

Code (CSharp):

1. public class MyFixedStepSystem : JobComponentSystem
2. {
3.     static readonly float TimeStep = 1.0f / 30.0f;
4.     float processedTime = 0.0f;
5.  
6.     protected override JobHandle OnUpdate(JobHandle inputDeps)
7.     {
8.         float deltaTime = Time.deltaTime;
9.  
10.         if ((deltaTime - this.processedTime) < TimeStep)
11.         {
12.             this.processedTime -= deltaTime;
13.             return inputDeps;
14.         }
15.  
16.         while ((deltaTime - this.processedTime) >= TimeStep)
17.         {
18.             this.processedTime += TimeStep;
19.  
20.             // Do my own update for fixed time step
21.             ...
22.         }
23.  
24.  
25.         this.processedTime -= deltaTime;
26.        
27.         return inputDeps;
28.     }
29. }

 

Thanks for describing how to do this! It's probably already known, but when I do this, even though my system is running, that new ComponentSystemGroup and its systems just don't show up in the entity debugger, is there something I can do to convince them to show up?

 

Hi @cort_unity, when systems auto creation will replace to non-reflection solution? Currently using reflection to auto create systems are too slow.

 

Estimates, regardless of how "great", are always welcome. Helps devs make decisions. So thank you!

 

@cort_unity Is there any sample code of what this might look like with JobComponentSystem? See my sample code here.

 

Hey there.

Do you plan to make FixedUpdate ahead of time ? So rendering can lerp between last and next simulation step ?

This is not the case in Unity FixedUpdate, and we have to do a lot of tricks to have this.

 

Hi. I would like to know how much has been improved.

 

Is there any information as to how "temporary" this is?
Will this last another year or so? or is there some kind of roadmap for this?