[Official] DOTS Roadmap Update - May 2024

[red heath]

Hi, all! I'm Ashley, product manager for Entities and Physics at Unity. 👋🏽

I know y'all have discussed this a bit on DOTS General Discussion, but I wanted to highlight the recent DOTS roadmap update we shared on the Unity Forums: https://forum.unity.com/threads/dots-development-status-and-next-milestones-may-2024.1591548/

Starting this thread to make sure we can catch your thoughts and questions in relation to this update. Your input is always super helpful for our teams, so keep us posted on your feedback and don't forget to vote/submit ideas on our official DOTS Roadmap Portal: https://unity.com/roadmap/unity-platform/dots

[delicate inlet]

I'm not sure I'm convinced of the unification with gameObjects. After so many years and we see Animation package on the horizon it feels like you are actually saying "We will not deliver a feature complete framework in the end", instead we will cut short and "if you need this feature - do it with game objects". It would also be nice with some statement that this unification will not be at cost on performance of current and future for DOTS packages.

I for one like that aspects are getting binned for what it was. I feel like more effort could be put into creating material on patterns of how we can do better data transformations with the help of e.g. native collections, intermediate components, change filters etc. instead, and improving the IJE and idiomatic foreach support for optional and read write dependency of buffers, generics etc. Although I haven't checked the latest versions of samples, maybe it has improved on that front now.

I'm excited to see how you will solve the parallel scheduling. Static dependencies, computed dependency trees/graphs or some other magic? 👀

[abstract fjord]

It's the most exciting roadmap announcement for some time—not only for the ECS ecosystem. It seems it's a great step to unifying most the engine's systems, for tooling to work across both paradigms without sacrificing performance.
ECS-based animation and worldbuilding sounds like a great backbone for updating other things, and should provide a springboard for asset developers to beat Unity to what's next 😛

For me the ECS-specific changes, like the removal of aspects... I feel like ECS is still in an API-churn phase, which is fine by me. IMO if something needs to go to get some velocity on the thing as a whole then I'm good for it. I just hope that there's still a lot of parallel development that's using it and responding to any pain from those things.

[rugged saddle]

it will not be at the cost of dots performance 🙂 and one of the key points of the scheme to improve parallel scheduling is to track dependencies by (archetype, componenttype) tuple instead of just by componenttype

[abstract fjord]

Someone's gotta move the Worldbuilding item to In Progress on the roadmap

I'm most interested to find out how the unification stuff leads to UX changes on the GameObject side. It's extremely interesting to think that built-in systems will start relying on Entities, and how that might start getting communicated to people who probably won't have the slightest clue about it all. I wonder whether it'll just be hidden to the average user unless they enable some switch, whether there'll be a push to educate people about it, or whether I'm just misunderstanding it entirely 😄

[rugged saddle]

the basic idea is that it will make it possible to move much more incrementally to taking advantage of entities, rather than having to rejigger your whole business around it; you can have a bunch of gameobjects, and write an entity system that does a bunch of bursted expensive processing that writes to those same gameobjects' transforms because they're actually entities under the hood, and the transforms are shared. similarly, you can add an icomponentdata to an entity, and it will just work, and you can talk about that icomponentdata from both bursted entity systems and from monobehaviours

so, i do imagine some people will just not worry about entities because they don't need the speed, but at least in some cases, when people do realize they need the speed, their next step will not be "oh no better write the next game in entities," it'll be "well i can just move this one slow bit to entities"

caveat: this barely works in master right now, and only in the editor 🙂 a long way to go before it's solid and usable

[rapid lichen]

What I don't get is where those go entities are going to live?

I have a complicated entities worlds setup for multiplayer, which allows me to test the whole cluster within editor

And since game objects are static

It makes me worried that same fate awaits entities

And any development with many unity instances running is just a death sentence to simplicity of workflow

[rugged saddle]

multi worlds <-> gameobject interaction is a topic of current research, but we're definitely clear that multiple worlds in the same process have to continue to work or nothing with netcode or entity scene streaming or some animation features will make any sense

also remember, not all entities have to be associated with a gameobject. so if you have pure entities worlds, none of this stuff will impact you at all

[rapid lichen]

I see. Well as long as I have a way to control the game object world where they end up I'll probably be happy

[rugged saddle]

yep, definitely will have that

[rapid lichen]

Makes client world for networking so much easier actually

Since no more hybrid setup is required

[mild obsidian]

One thing I'm quite curious. Is that game object transform will be rewrite to match with entity LocalToWorld? So when both entity and game object linked together, you can iterate them with burst compatible way together without require TransformAccessArray anymore

[rugged saddle]

@vocal olive can speak to that. you can definitely iterate over entity + go transforms in the same job, but i'm not sure about the status of transformaccessarray exactly

[river vapor]

Broadly speaking, when you get/set/iterate over transform components in an ECS job, if the target entity is actually the one automatically created for a GameObject, then you will read/write directly to the GameObject's transform data, even from a Burst-compatible context.

We are hoping this mostly eliminates the need for TransformAccessArray for jobs that need to access GameObject transform data.

[odd thorn]

What about other API’s in terms of the go/entities unification? For example when we do DOD with Monos one of the biggest bottlenecks is Destroy. Im also curious how this unification will affect general work being done in Update

[worn iron]

will unification allow for things like calling native vfxgraph code inside of jobs(given the roadmap entry for translating vfxgraph to ecs vanished)?

[rapid lichen]

from what I understood - what that unification means is they are practically moving everything to ECS, but leaving synchronous API available through monobehaviours

so while the API may still be mono only, the underlying data is potentially going to be exposed as entities components

[rugged saddle]

it depends on the particular system, whether the team in question has time and interest in converting, cost of converting vs benefit, etc. don't know about vfxgraph in particular.

no particular idea that Destroy of gameobjects will get cheaper; it might, but i don't know that this stuff would specifically cause it to

[worn iron]

its up to the team to decide? 🥲

[sick relic]

Vfxgraph always seemed liked one of the easier things to make unmanaged as from memory, the script is entirely native engine calls and the only thing it accesses is the transform

Doing it from a job is a bit of a different problem though

[rugged saddle]

well, not necessarily the team, but there's a tree and everybody in the tree has different people with different ideas about what's important. i would say it's less insanely cat-herdy than it was in say 2019, and there's more general agreement about what's important, but it's still mostly not a top down "everybody do X right this second" either.

also, in some cases the team doesn't exist anymore, either because of quitting or layoffs or reorgs, and then it can be hard to get it to happen

[mild obsidian]

Any new update for improvements to ECS Content Management? It's essential for game that needs to update content regularly specially mobile game. I just expect official can ship something like Addressables but without configure string address for each asset added since ECS content management is bake asset into subscene as reference

[rugged saddle]

yes, a bunch of content rejiggering is generally in progress, and it will play better with entities, but the exact shape is a topic of current research

[rugged saddle]

p.s. reminder that all this go<->entity unification, coreclr, content stuff are all very far away from production ready / public release / usable / etc. coreclr stuff barely works in master, a lot of the stuff we're talking about isn't even in master, and some of it is barely a twinkle in somebody's eye

[odd thorn]

I’m sorry but why was it announced on the roadmap then? I was under the impression that Unity no longer wanted to announce things that are far away, vague, uncertain etc etc… this is starting to sound exactly like this kind of announcement.

[rapid lichen]

look at this thread: so many questions and concerns that can actually give unity a bunch of ideas of what's important in any big reworks or features

[river vapor]

That ☝️ for sure, and also because if we say nothing for months at a time, people start asking "is DOTS dead?"

[abstract fjord]

Also you can't leak things that are now actually announced

[fleet rain]

So good to finally be able to talk about ||spoiler alert||

[mild obsidian]

Hi. I would like to ask the the current state of dots bug report status. Any new update to bug report IN-42757 and IN-61082? For N-42757, the issue tracker mentions it's fixed but I just try at latest Entities 1.2.1 but I still able to reproduce the bug.

[mild obsidian]

Curious is that go <-> entity unification planned at unity 6.x or 7.0?

[rugged saddle]

not 6.x. for bureaucratic reasons i'm not officially allowed to say more than that

[gloomy belfry]

I caught up on the changes coming and noticed Aspects are going away in the future. While this is not so much of a problem in general, they do solve a current neiche problem of how to use Generic component types in a IJobEntity struct. Is there anything that is addressing generic component types that will be able to replace the need of an component aspects?

Right now I could write something along the lines of

public readonly partial struct GenericSolutionAspect : IAspect {
    private readonly RefRO<BlobComponent<SomeType>> _RO;
    public ref SomeType Info => ref _RO.ValueRO.Value;
}

and pass that as a parameter into the IJobEntity struct and the compiler and runtime are perfectly happy. Not so much with the BlobComponent<SomeType> as a type parameter.
(Understandably this is likely to not change for 1.x, but wanted to be sure we don't have a regression that could potentially hard break projects built on generics )

[sick relic]

#1203971214725357568 message
it is known, hopefully sometime in the future

[gloomy belfry]

I've been hearing that tune in regards to it for over a year since I brought it up to Unity on slack. I just want to be sure there is a replacement before they wipe aspects, since I was told to make a forum post regarding it (back in Nov) https://forum.unity.com/threads/using-generic-components-in-ijobentity.1511882/

[sick relic]

Well that's why I pinged dani directly 😄

[gloomy belfry]

Noted