DOTS development status and milestones + ECS for all (September 2024)

Another question in a ECS telegram chat
It means we can bake entities in a mono scene? Sub Scenes will be just for a bundles?

Another question in a ECS telegram chat
It means we can bake entities in a mono scene? Sub Scenes will be just for a bundles?

As it currently is, Baking will still be limited to SubScenes. But you will be able to create Entities directly in normal Unity scenes, just no Baking process on them.

1 Like

This might explain a picture I saw. Does it work by in normal scenes you can just directly add icomponentdata to a gameobject? but not authoring scripts?

You can add IComponentData directly to a GameObject, yes. Authoring scripts won’t do anything special (they’d just be a useless MonoBehaviour).

But we also intend to have pure Entities in the scenes as well. So you could create an Entity directly and add the Components directly. No GameObject would exist in that case.

I should also say this is not the final place we want this authoring experience to be in, but it is a stepping stone for the future.

5 Likes

2D has been noticeably absent from anything ECS/DOTS related, be it the URP 2D renderer or the 2D Animation package, which has some burst/jobs related optimizations but is not entities compatible as far as I know.

Do “ECS for all” include any plans for the 2D tooling of Unity or is this 3D only?

6 Likes

I’ve mostly resigned to the thought that they will never have any plan for 2D. However seeing you raising this again I just want to say thank you.

When you create an IComponentData directly on a gameobject, is the transformusageflag set inferred? Is there a way to specify it?

In this case, you will always have the full Transform of a GameObject, as it is a GameObject and required. Transform usage flags will be limited to Baking (therefore SubScenes), at least initially.

Well, if we end up having entities in the hierarchy and we don’t include a transform component, then will this let us avoid having a transform?

Could there be a way to reduce the boilerplate code for IComponentData? such as with an attribute? e.g. [QuickBake(options)]?

Same as I posted above, you will be able to create pure Entities directly in a normal scene and add whatever IComponentData you want to it, and in this case it won’t be a GameObject. So, yes! You should be able to do exactly that

4 Likes

Will BakingSystems pick up those entities and components?

Do gameobects exist in subscenes now or just in regular scenes? Is the current awkward companion object stuff sticking around, being improved or just being removed now that your gameobjects can exist in normal scenes?

As far as I understand.
SubScenes stay the same. MonoBeh only for authoring in SubScenes.
In Normal Scenes MonoBeh will have EntityId under the hood which allow them to get IComponentData and be part of ecs systems. Also transforms reworked for the sake of ecs thats why you can have cross parent/child hierarchy between GO and Entity.
There is no baking in Normal scenes.

1 Like

Do you mean staging worlds? You can look into the recent versions of the manual and scripting API. I just can’t find this same paragraphs in there.

Not really, my use case is deterministic lockstep multiplayer, where one world is deterministic, updates slowly (think ~20 updates per second) and is replicated exactly across all players. The main world does the rendering/presentation, updates at the screen frequency, and interpolates in-between the steps of the simulation world (at the end of each simulation step, it would copy all relevant data from the simulation world to the presentation world).

No, Baking as a mechanism won’t run out of SubScenes for now

Great question.

The new serialisation in the next-gen that allows us to serialise Entity data side-by-side with GameObject data in normal scenes will also be available to us when we serialise SubScenes. We’re still early days on the impact this has on SubScenes, but I can imagine a scenario where we make it so you can select GameObjects to keep in SubScenes/Baking and we get rid of Companions. The big difference here is Companions try to emulate the lifetime behaviour of an Entity- so if you clone an Entity, it also clones the Companion attached to it. But I’m not convinced the oddity of the feature Companion is worth that.

So instead, you could just elect to bring in certain GameObjects by choice, and manipulate them as you see fit at runtime. They could be a child of an Entity, but you will also be able to manipulate the Transform of a GameObject directly via ECS APIs, fully Burst-able. You would simply be limited to main thread non-burst when you wanted to deal with, for example, the Light component on the GameObject.

My feeling is this would suitably cover the use-case for Companions in SubScenes to the point where we wouldn’t need them at all. But would love to hear some thoughts, as this part is still being discussed internally.

7 Likes

The AI like LLM is rapidly improving, but why on earth our progress to get the final DOTS looked so slow compare to the explosive news coming from the AI breaking-through,

DOTS will be very a very powerful but I’m not sure with its “slow” progress it can win the battle with AI in near future? maybe AI could magically done the performance improving in his way? like generate “next frame” within 8ms on mobile? or the good ending: AI helps the merging of current GameObject workflow to DOTS internally?

2 Likes

Thanks for the confirmation. I kinda expected this but it brings up some major concerns.

Baking serves the purpose to create runtime data that’s fast and easy to load.
But that’s not the only benefit!

Bakers forced us to split authoring and runtime data and this is one of the greatest things in entities!

Bakers give us the opportunity to create really nice frontends (even with custom UI) for designers and a lot of complexity can be hidden in the baker itself. One baker authoring component can attach multiple component or buffers, create additional entities with even more components and BakingSystems can gather and postprocess all this data to create even more necessary runtime data. All that work to setup runtime data with just one baker component that’s easy to digest and configure from anyone using it. Also, it’s not error prone when you forgot to add some IComp.

My concern is, that this design and philosophy behind it will go away with the approach you are currently outlining and IMO it’ll end up worse. Meaning, if you have this very rigid approach it’ll end up in the same problem (from a design perspective) as MonoBehaviour or the previously deleted generated IComps where it’s just not clear how an entity or components should be built, what components are optional or required.

Furthermore, subscenes served as grouping mechanism for entities with clear data to find such a subscene and entities that live in it. How should that work then with scenes? Do you plan to still use SceneSection? I just hope it’s not ending in a side-path where we suddenly have to distinguish if the entity is in a scene or a subscene.

TL;DR: I think you should keep the design around baking and be more clear about the split of authoring/runtime data. Either don’t support attaching runtime IComps or Buffers to a GameObject or Entity or have Baker components still run because I don’t want to have to write 2 components for “baking” in a subscene or a scene.

3 Likes

Baking isn’t going away for SubScenes. The reason we won’t have Baking in normal scenes for next-gen is just time limits. So let me be really clear, this is exactly where we want to go with all scenes ultimately. A clean authoring and runtime split, with an optional operation in between available to us and users.

4 Likes