Official DOTS development status and next milestones – June 2022

Thanks for this new update

The only thing I can think of is → please make early ECS 1.0 preview.xx package accessible as soon as possible so we can start bring feedback about it

 

I have some questions for dots 1.0 release
1) Since HybridComponent feature has been deprecated, will dots 1.0 release has any new hybrid solution that able to put game object into entity and able to instantiate the entity by dots addressables? So when instantiate the entity, the game object will auto instantiate together that associated with entity just like how HybridComponent does or similar.

2) Will dots addressables support putting subscene into dots addressables like game object land that put scene into adressables?

 

Sounds good. I am also down for 1.0 - even if radioactive!

 

Any chance the bugs around CopyAndReplaceEntities are on somebodies radar?

https://fogbugz.unity3d.com/default.asp?1425370_sl2paqrmfhihfo0s

(older one: https://fogbugz.unity3d.com/default.asp?1331165_hoa8tf4ctdlcj4ag)

 

If there's anything I can do to help. I would happily iterate on the test case if there's a better way to implement rollback. This is the test case I submitted. https://github.com/nykwil/EcsRollbackTest

 

My use case is to enable auto entity association with game object, game content update for both entity and game object, game object pooling by default. Currently I use addressables to achieve game content update for game object and then manually do entity association with game object. But it starts not working really well after I upgraded project to Unity 2021.3.4f1. It seems like there's bug at Unity 2021 that blocking addressesables WaitForCompletion() API that keep blocking the main thread. It's also another main reason why I need to have official support that I can make sure it will always working out of the box.

 

I see what but don't see when. Is there any broad deadline like before? i.e. 2022Q3/4

 

Is it possible to step in Entities 1.0 all the way directly from Entities 0.17? by skipping 0.50 and 0.51?

I might reconsider for an official update of 1.0 more cuz wait another 4~5 months is affordable since all the years of previews has lived through, spare me plenty of time for game creating instead of api updating.

I can tolerate any roadmap obsolete or deprecated as long as Entities 1.0 arrives as light of god in this year

 

I uploaded a implementation of the CopyAndReplaceEntities bug using 0.51. My implementation does not share any code with nykwil's implementation. CASE IN-8077.

 

Massive Thanks to you, guys, and your hard working years will definitely fructify.

 

Hi there, Gotta Love The Progress DOTS Has Made


I Have A Question though, I Can't Find Anything On The DFG Package(Data Flow Graph Package) And It Doesn't Seem To Be Compatible With The Latest Release OF Entities

I'm Using It To Create A Custom Animation Solution That's Based On The Animation Samples

So Any Kind Of Guidance Is Appreciated

 

Hi @elliotc-unity. Can u make sure these 2 issues about platform package will be fixed at dots 1.0 release? Case 1415919
1) https://issuetracker.unity3d.com/is...-minor-versions-in-0-dot-50-platforms-version
2) https://issuetracker.unity3d.com/is...tion-does-not-have-an-option-to-run-the-build

Btw I would also like to ask how much new code changes for platform 1.0 compares with platform 0.51? Is that just almost the same?

 

We were informed, there are many significant upcoming changes.
But there will be migration documentation provided.

Please checkout this vid, for more details

 

I'd also be interested in that. We're currently using an older version of Entities and it still seems to work okay'ish. We have started porting over to 0.50/0.51 - but that has been kind of nightmare'ish. If 1.0 is a significant diff from 0.50/0.51 we may actually want to wait for 1.0 (unless going via 0.50/0.51 is likely to be less painful).

 

Did you get info about animations in their project? What are they using? Is it custom or hybrid with GO? I wonder what was that as this is the biggest hole in DOTS now.

 

They use a hybrid solution. (They did not mention it on stream but I used to work there, so we've talked about it)

 

Is this likely to mean Entities builds will just work like any other build in the classic pipeline, or are you folk looking at some other mechanism? It would be brilliant if Cloud Build supported building Entities projects by just going through the “normal” Unity build process.

 

I see. If I understand correctly, do u mean the way to build dots player runtime build will become exactly the same as oop land player runtime build i.e. File - Build Settings - Build / Build And Run at dots 1.0 release? Then it comes to another question is how dots addressables work with Entities to get a working dots player runtime build? Is that the way to setup, build and then load dots addressables entity/game object/asset is just almost the same as addressables but in ECS form?

From what I know Entities.ForEach lambda at system will be simplified to another format and also some Entities API changes that I believe all can be done by auto script upgrader? Or ISystem at 0.5x release will have some new format changes that I need to fix manually? Then the only thing left I see will have big breaking change is authoring that it evolves to something called Baker. Or it will still have current MonoBehaviour Authoring backward compatibility at 0.5x release so I still can compile my dots project properly and slowly do the migration later? And also can I still using GameObjectConversionSystem to do authoring at 1.0 release?

 

Is there any post or comment on why build configs "are slated to die"?
For now I see them as really useful thing

 

Oh this is very sad news, because build configs were very amazing and allow us to automate builds for multiple platforms with a single click. And now we need to open build window, select a platform, wait for reimport, then select a folder and then click a build button? Sounds like a thousand steps back.

 

You can make a script to do that for you:

https://docs.unity3d.com/Manual/BuildPlayerPipeline.html

 

Seems like Unity should hire some people for DOTS and HDRP. Oh wait, need a few million pay rise, sorry guys.

Joking aside if this means delivering a solid product rather than a maybe-supported one then it's absolutely the right move to pull build pipeline. A shame but understandable, otherwise we'd be investing code and time into something that only has a maybe-updated tag attached to it.

 

I think we'd all like a solid product but it seemed quite forward thinking to have the build configurations. I hope they can be revisited in the future as it seemed like a faster way of working than the current non dots workflow.

 

What does all this mean for Project Tiny? Is that going ahead?

 

From the authoring workflow preview video it was clearly stated that the project is currently on hold.

They will first focus on Dots 1.0 and maybe once that is polished and production ready they will redefine what project tiny will be.

 

And raytracing and pathtracing? Will dots be compatible with that?

 

After building my prototype with ECS 0.16 and dealing with all the difficulties with different renderers (2D and Hybrid) and so, I just would like to know if I can do with ECS 1.0:

- create (thousands) lightweight entities, give them a (sprite) render component to render a 2D image/sprite way faster than with the old

GameObject

instantiation (I don't need to see the lightweight components in the Hierarchy view, but it would be nice)
- use the "new" 2D lighting system (and if necessary the 2D renderer)
- enable/disable component system easily on demand
- have easy interaction between

MonoBehaviour

components and ECS components (e.g. my Player component is a

MonoBehaviour

, the visual representation is a ECS

ComponentData

)
- easy way to create and instantiate prefabs
- use VFX and Shader Graph

If these things could be done, I'd consider to give it a try for our prototype. I tried to update it to ECS 0.51 but I got too many problems and cancelled it after 2 days then, updating the APIs and trying to figure out how things were done in the new way.

 

I see. Then I think improve Entities compatibility with Addressables first while waiting for dots addressables is better. Currently after await Addressables.InstantiateAsync("foo").Task then using Entities add component API (EntityManager.AddComponentData() / EntityManager.AddComponentObject()/
EntityCommandBuffer.AddComponent<T>() / etc) is not working properly. I will throw u error and crash at runtime player build. Currently I'm using Addressables.InstantiateAsync("foo").WaitForCompletion() is working nicely at Unity 2020.3.x LTS but not anymore at Unity 2021.3.x LTS. It's still kind of working but it stuck at loading for quite long time and then will throw u a couple of error like load dependency error at Unity 2021.3.x LTS at Android runtime player build.


Another thing I would like dots team to really consider about new process per world feature request since I believe no matter how hard to do optimization at 1.0 release it's still hardly can get the enough editor performance. I found that there's really a need at editor for Entities to make each World as independent process instead of like currently all Worlds is put inside editor process. I think it's the main reason why it's slow at editor but it's fast at actual runtime player build. I also believe that that's why burst is also move as a independent process that no longer integrate into editor process. Currently for my dots netcode production project, it's just running at 30+ fps at i7-7700HQ laptop at editor but the same project can get 60 fps at powerful desktop pc. Since dots netcode project it needs to have very demanding client world and server world, it's better to have each new individual process per world to guarantee editor performance. But still the project is mobile dots netcode project that it's not very graphics demanding that it should get 60 fps at i7-7700HQ laptop.

 

Quick search didn't show anything on if there is an entities package that works with 2022.2 beta? It looks like there won't be until 1.0 is integrated at some point?

 

No support for 2022 until 1.0.
(They mentioned the very unlikely possibility of releasing more granular versions but I think that was only meant for after 1.0)

 

You can use burst and jobs with 2022. But no entities atm.

 

Is there any ETA on when 1.0 might drop? At least the preview package?

 

Whenever happens. Maybe next quarter, or maybe next year.
I suggest do not wait specifically for 1.0. Start doing something in DOTS now, and by the time it will land, you may be up to speed with the DOTS aspects.

 

ALbeit I respect this opinion I would suggest Fabraz to wait. I started a new DOTS-Project few days ago. I just followed a tutorial and had Unity hard crash on me and later a message indicated a burst-compiler bug. So I could not proceed and gave up. I expected ECS to be a bit more "mature", stable and usable after 4+ years of development. So if you dive into it now you may be "up to speed" when 1.0 lands. But it will potentially also cause additional frustration and "useless" work to work around the current issues. Also there will be significant changes to the API and I don't know how good or bad the "upgrade" process went for people the last times a new version arrived.

So some people are doing great stuff with ECS already (Latios Framework, Games). So it is doable. But if you are just an "average" user don't expect a smooth sailing. It has a reason UT is making it so hard to install ECS at all. So if you want to try ECS for research, learning or experimenting: go for it. If you want to build an actual game/work even UT advises against this at ECS is not sufficient for production right now. And with all the stuff still missing even 1.0 will probably leave much to be desired. So choose wisely and consider what you want to achieve and what you expect.

 

I got your points.

Yet this don't make sense to get with latest Unity feature version, as there is little of resources online.
For new starters, it would be easier to get grasp about basics in "older" entities 0.17, or 0.51, where there is quite a bunch of materials online, forum posts, docs, users articles and vids.

Unless user is able to understand DOTS source code. But then, none version of DOTS would be an issue for such user.

Either way, Unity resources are up to date, to allow learn anytime (some official examples)
https://github.com/Unity-Technologies/EntityComponentSystemSamples

The question is, is person ok to wait indefinitely, before starting to learn DOTS, until entities 1.0 is released?
In the end, it is up to the user when want to start learning new feature (released / or preview), in this case DOTS.
Unity discussed, they will present upgrade docs to entities 1.0, as they did for 0.50 / 0.51. So that gives user an opportunity to auto upgrade they project later, if they start today.

 

Are there any plans to add names to Archetype?
Would be nice to see names of archetypes in DOTS/Archetype menu.



Screenshot as of Entities 0.51

 

I'm curious how you think this would work?

 

It is an interesting question.
However, since we can set names to entities, we could have similar mechanics, to name archetypes.

I suppose, as I think more about it, problem and complexity become more trouble some, when adding and removing components at the runtime.

Perhaps we could have some definitions of archetypes with a name, which editor will use that name, when existing archetype is matching.

Just brainstorming aloud.

 

I think a more practical solution might be to be able to select an archetype from the DOTS hierarchy or the inspector.

 

both ideas sound good to me

 

Here's a thought. Instead of naming very specific archetypes where an archetype fully describes the entities that would be lumped together in a chunk, have archetypes as "named queries" in systems. Once a system registers a query for an archetype, it could describe that archetype with a name. That then opens up the possibility of selecting an archetype from the DOTS hierarchy or having multiple systems register the archetype they operate on by name instead of redefining it. It opens up a door for abuse and confusion, but I can see how it could be useful from a debugging point of view.

Further flavour could then be to list the archetype names next to an entity, similar to how an entity might be "tagged" with various tags, but ultimately giving a developer the ability to quickly reason about the different archetypes an entity might conform to.

 

Yeah, this was my very primary thought, how it could work.