Looking forward to DOTS roadmap information in 2020

Interestingly, I discussed with one of them, asking for DOTS vs own in house solutions. They response was, that they are still few years behind, with own R&D, before they get to a point, what DOTS offer. So no surprise, they take DOTS seriously

 

Entity component design as it's widely used is mostly about compositional design and that's what I was thinking of when talking about being a standard in the industry.

Unity's ECS is more interesting to me in what they have done with concurrency. Simplifying that problem for a domain isn't easy and doesn't happen that often. Like once a decade or so you see the bar raise significantly. Akka doing that in the server space is the last time I remember. They had a simpler domain to solve for but the key end result was the same. Race conditions were just designed out, you couldn't create them on accident. All while being very easy to use.

 

id Tech 7.

 

It's pretty amazing that I would say this ... but it totally does feel that way!

 

@Joachim_Ante is the next Entity version ( 0.16) next week will have enable/disable component feature ?

 

Where did you get information about either the version number of the next Entities package, or its release window?

 

@Sylmerria
Release versions probably can be viewed in Package Manager.
Or here
https://docs.unity3d.com/Manual/com.unity.entities.html
However, latest is 0.11, so where is 0.16 coming from?

I wouldn't rely on any future / predicted release dates. But yeah, where is that "next week" window comes from, makes me curious too.

 

@PublicEnumE I guess likely from either https://forum.unity.com/threads/psa...-updateingroup-attribute.988992/#post-6423715 or https://forum.unity.com/threads/lat...-dots-animation-packages.956031/#post-6425732

 

In fact I looked again into docs and I see Entity 0.14
https://docs.unity3d.com/Packages/com.unity.entities@0.14/manual/ecs_core.html
From earlier information

 

indeed from there

 

0.11 is the last one compatible with 2019.4, in 2020.1 we are at 0.14 currently and all future versions will target 2020.1+

 

I hope you haven’t been caught in the confusion that happened when they changed how packages are displayed in the Package Manager, but this may be helpful:

The Package Manager will only list packages which are compatible with your current version of Unity. Even if later packages have been released, you won’t see any indication of that in the PM, unless you happen to update your project’s Unity version.

IMO: Unity does a very poor job of informing people when he packages are available. I think these changes would make it much better from a user perspective:

• List all package versions inside the Package Manager, regardless of whether or not you have a compatible Unity version installed. Visually call out the ones that your version of Unity can’t support.
• Don’t let the Package Manager download the packages which aren’t compatible with your current Unity version. Instead, inform the user of which Unity version they’d need to install be be compatible.
• Visibly alert users (In the Package Manager GUI) when one of their installed packages is out of date (even if the new package isn’t compatible with their current version of Unity).
• Make a new forum post for each new DOTS package release, similar to the NetCode or Visual Scripting package release posts.

<— This last point would make such a big difference. I do not understand why it’s not just common practice as part of every Burst, Jobs, Entities (or related package) release. I once went 3 months after Entities 0.11 was released without any idea that great new features I had been eagerly waiting for had been released months earlier. If someone on the forums hadn’t happened to mention a later package number one day, I probably would have obliviously waited for longer.

That SUCKED. ​

 

Hmm, this is very interesting observation. And I am on the 2020.1.
Is the other way to force PM to update list of available packages, without actually updating the project?

 

Not happening, programming in dots is like programing a database, everything feels backwards, it's way too different from OOP. Once you get used to it's not a big deal at all, but it takes a while. The whole thinking data part is also pretty strange if you programed OOP for too long.
Maybe it's not a big deal if you never programed before? Right now I feel comfortable writing for DOTS, but that took me about a year? I mean, my first DOTS code is abysmal, but it's working and I don't have the time to rewrite it all yet.
And I still haven't started with the whole messing with internals, which is where the real magic is. Like reading writing data from type index.

My tip is to toss out this whole idea and make dots as powerful as possible, stop trying to make dots a minimum common denominator tool. It's not for everyone, shouldn't be, focus on making it better rather than 'better to market'

Letting me edit entity data from the Entity Editor would help a whole lot on it's own. Isn't it easy to do through reflection? I mean, who cares if it takes 0.25ms extra when you change data through the Entity Editor window

 

There is no way to do that, as far as I know.

The only way to know might be to keep an empty project that’s always on the latest Unity version, just to check the Package Manager.

or, to check the Package Manager website every day for new package versions - though those can sometimes lag behind the releases by a few days.

...This situation could certainly be much better.

 

One missing core feature I currently really need it is AI Behavior Tree DOTS package. From what I know this package is in development for quite long time but until now I still didn't get the preview yet. Hopefully you can include this into DOTS roadmap.

 

i disagree with that , as someone who programmed oop for around 9-10 years in unity and saw it getting improve by the time , making dots friendly doesn't mean it will become weak , at least from what unity shows from 2019 video and how they change the code in dots and make it easier but in the same time powerful & stable, it is about how is done. don't forget they have over 60 engineers working on dots , so for stability and being powerful i bet they following that road already & heading towards it. and like u said is take you a year , why would u need someone else to spent a year figuring out dots? because if you don't agree with @Joachim_Ante plan then that what would happen , also i would like to see assetstore tools to be integrated with dots. and anyway the engine it self going towards being fully integrated dots system. so i don't see any reason to disagree with @Joachim_Ante and i also disagree with "not for everyone" and "shouldnt be" part , remember this is unity , most of us here are indie developers , most of developers use tools and that tools need to be created by a community that use dots. so i dont see a reason for what you said "shouldn't be for everyone", it should be for everyone , we need a community that love dots , and build things through it. just like the powerful OOP Community that make Assetstore to what it look like today. when you offer a friendly code & tools expect much from the community. and that what we need.

i agree with u with editing part , something like inspector.

 

Let me introduce you to something known as The Mythical Man Month: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Throwing engineers at this problem will not make it go faster. In fact, it has been proven that it will go slower the more you throw at it.

That's not to say that getting DOTS to be as easy as MonoBehaviour is a bad thing, just that it is going to take a very long time to get there, like decades long.

That being said, programming in current DOTS ideology is actually *not* *that* *hard*. It requires you to think in data, instead of objects, yes, but that is a *good thing*. That is how computers work. That is how programmers should be trained in school, instead of these pie in the sky ideas of theoretical computer science. Learn how the hardware works and build from there. Otherwise you are treating it as a black box, which almost always produces poor results.

I applaud Unity for going down this road. When it comes to games, performance uber alles. If your game doesn't perform well, it won't sell well, it's as simple as that. Just don't hold your breath for DOTS == MonoBehaviour. If you are planning to ship within the next few years, learning current DOTS and all the benefits that knowledge brings will be well rewarding.

 

I hope the roadmap could confirm about DOTS + GPU jobs.

 

oh yea for sure i didnt say it will be fast to finish dots and i totally agree with you i also know that putting more engineers could make it slower . Which is what joach and other mentioned anyway. But i would rather wait for something great while contains same Dots features but even better, than just telling the engineers "stop thinking about doing that". Don't forget what unity shows at 2019 video about the changes of the code to be much shorter and easier than befor while still hold performance and features

i would like to see more of that, like i said befor and will say it again is all about how is done. Don't Judge book from it Cover. I also agree with u about the mono == dots part i never mentioned that i said it can be something like it from the ease of use and this question been posted befor and Joch already answered it. Explaning what he mean by saying easy as writing Monobehivor.

Thanks for Mentioning This Points. Cheers!.

 

Would Love to Hear more About Dots Terrain Engine , & Where it is Right now and when we Expect it to be Released

 

I've pressured for a roadmap for over a year now and they've never been on time. Plus they do things like force everyone to upgrade to new editor versions even if it's outside of the LTS meanwhile being previously told that wouldn't be a problem. Even to this day, you can find a lot of conflicting info when you ask Unity for more info.

Nothing about this whole DOTS release is reliable unfortunately. It's been a nightmare and a huge frustration.

 

When I saw DOTS investment in Unity, I excited about the coming performance solution in C# and in Renderer. Despite to job system which is working great, there is no clear goals of DOTS improvement reflections. Also the changes in every update make it hard to use it in a product, also create a need of relearn every step of it and it make developers stay away frow DOTS features of unity, and that make many developers stay at old entity component pattern. So this situation create a vicious circle, sadly.

I would like to see clear goals for DOTS at side of Unity and invest time on the pattern by creating codebases and practice. Because it could really change what we can do with this engine.

 

Funny enough, I’m a game developer student and *mostly* agree with this, we learn a lot about design but code architecture has been degraded to “make it work = get good grade”. I have no doubt the competitive nature won’t change, but the inherent design of DOTS might at least lead us away from Singletons and string references (being applauded).

Learn how the hardware works however will never happen. That’s a different school, we just want to make games. In a safe scripting environment this will never come up.

And this is just a fun fact, but I did a project in ECS 0.3 and failed (not surprisingly) on what was the single greatest learning experience I enjoyed there.

 

You should also give some thought to:
4. How do we provide an upgrade path for developers with existing MonoBehaviour based projects and code bases.
I doubt that a script converter, like you offered when phasing out javascript, is possible, but there needs to at least be something like a Rosetta stone, with practical examples of common tasks using both the old and new systems. If DOTS is the future, and will significantly improve performance, I want in. But I have a lot of existing scripts, written over the course of many years, that will need to be rewritten - again - so a little guidance would be appreciated. You can't just build a better mouse trap. You need to educate users on why it's better, and how to use it most effectively, or they'll just keep using the one they know.

 

Without any disrespect, I'd like to offer a differing opinion, that dedicating time to a MB -> DOTS converter wouldn't be a great use of Unity's DOTS schedule.

I'm not saying it wouldn't be great to have, or that it wouldn't save MB devs a ton of time. But I do question if it's practical to make. The way code needs to be organized in order to use any of the three parts of DOTS (Jobs, Burst, or ECS) is so different from the MonoBehaviour way, that a low-level re-write might just be inescapable.

There are so many ways one can organize code using MonoBehaviours which won't work with DOTS.

For one, the concepts don't really match up. A GameObject doesn't fill the same role as an Entity. And a MonoBehaviour Component isn't meant to handle the same responsibilities as an ECS Component. One can imagine a converter that tries to create one ECS Component and one ECS System for each MonoBehaviour in an existing project, but data and logic can be so entwined in a MonoBehavior that it would be incredibly difficult to do. And even when it was successful, the resulting Components and Systems likely wouldn't be very performant by DOTS standards: In ECS, it's often best to split the data found in a single MB Component into multiple ECS Components.

Other challenging examples include:

• Figuring out what to do about non-blittable data in MonoBehaviours
• Figuring how how to convert collection types in MonoBehaviours.
• Figuring out how to handle inheritance in MonoBehaviours (which can be as complex and the user wants it to be)
• Trying to determine which Job types would be best for the work a user was previously doing in their MonoBehaviours
• Figuring out an order for ECS Systems (especially if the user was using delegates in their MonoBehaviour project)
• Figuring out how to convert mutable static data

and many more.

I feel like some of these might just not be surmountable. And some that are possible could take a very long time to find. I don't think it's impossible to write some kind of converter, but it's likely it would create very unoptimized DOTS code. In some ways the challenge might be similar to a visual scripting editor with a 'generate code from graph' feature. In Unreal, code generated from Blueprints is often 10x slower than non-blueprint equivalents.

I don't know what changes the DOTS teams is cooking up for 2021, but I do think they've done a good job of explaining why writing new projects in DOTS will be beneficial. The reasoning behind DOTS is as true today as ever:

1. Moore's Law has largely flattened out. Single-thread CPU performance isn't getting much better, but multi-core performance is seeing a lot of growth, year over year.
   
2. Game logic has traditionally been single threaded, and there's a ton of performance to be gained by multi-threading our gameplay code. 10 - 100x in real-world cases.
   
3. OOP code often introduces cache misses. A DOD approach can significantly reduce cache-misses, making for better CPU-optimized code.
   
4. An engine like Unity offers an opportunity to write a custom compiler (Burst) with a lot of hand-written optimizations, specific to the engine. These wouldn't be available to a general-purpose compiler, so we can see speed-ups that aren't otherwise possible.

It's a great marriage of different optimizations. But, DOTS is different enough that it might be best to think of it as a different game engine, with a similar editor & features.

You're 100% right. When 1.0 is out, and the DOTS workflow is more finalized, I hope Unity does a lot of this.

 

I don't expect DOTS team to even try write MB to DOTS converter, of existing code.
Is just completely different paradigm. If someone wrote code in a way, which doesn't follow Data Oriented Design, and there is tons of way to write same thing with MB, how would it be even possible to write automation for such.

The only feasible way I see is, if there is specific scheme, which should be followed, 5o be able to convert. Meaning, you would need rewrite your code anyway, it wanting using DOTS at its full capacity.

Regarding performance, even code written by hand can behave very badly. So visual graphs can be good starting point, as long it allows to include custom nodes.

And like with shader graph, if someone want to get every bit of performance, will most likely write them by hand. Or most of it.

MB Game Objects already can act nicely like entities, with components attached to them.
After conversion to entities, either using them as is, initialize and modify, or use them as prefab.
There is very little to difference. Maybe with shader and transform, component attached, when someone don't need it. But can write simple system, to clean up entities prefabs, to required format.

Using Go as entities is nice alternative and functional option, to build game levels and be able utilising DOTS at its best.

 

ECS dont have any rules that prevent you to use it in wrong (non DOD) way so you can keep all code logic in components.
For compatibility ECS also have Class Components

As I wrote earlier in another tread I think it is more sense to change backed of GO/MBs so they actually will be build on ECS. MB inherit from ClassComponent, GO make wrapper on Entity and create few systems that will mimic magic methods in MBs (Start, Update, etc). Mostly all methods of GO and MB is internal calls to C++ side so making it part of ECS systems will be easy.

After migration just get rid of old internal GO/MB objects, code paths and invest into DOTS ecosystem 100% of time.

But I think even if this happens, it will be around DOTS v2.0

 

A converter is indeed fools gold, however I can promise you that you can upgrade Mono code, today, without so much as opening your existing scripts. I've done it myself.

I think an example is the best way to demonstrate:

Code (CSharp):

1. public class Spin : MonoBehaviour
2. {
3.     public Vector3 speed;
4.  
5.     private void Update()
6.     {
7.         transform.Rotate(speed * Time.deltaTime);
8.     }
9. }
10.  
11. namespace MyNamespace
12. {
13.     public struct Spin : IComponentData
14.     {
15.         public float3 speed;
16.     }
17.  
18.     public class SpinConversionSystem : GameObjectConversionSystem
19.     {
20.         protected override void OnUpdate()
21.         {
22.             Entities.ForEach<global::Spin>(spinComponent =>
23.             {
24.                 var entity = GetPrimaryEntity(spinComponent);
25.                 var spin = new Spin
26.                 {
27.                     speed = math.radians(spinComponent.speed) // Ecs works best with radians.
28.                 };
29.                 DstEntityManager.AddComponentData(entity, spin);
30.             });
31.         }
32.     }
33.  
34.     // Your SpinJob and SpinSystem (added as a spoiler for those interested.)
35. }

That Spin MonoBehaviour as you see could be a perfectly normal script, converted with an external GameObjectConversionSystem. However, writing DOD code is completely different from OOP (as the spoiler shows), so I'd suggest you pick your battles. If you only have 10 spinning cubes, leave it.

Spoiler: SpinJob

Code (CSharp):

1. namespace MyNamespace
2. {
3.     // Fastest Job type for this task.
4.     public struct SpinJobChunk : IJobChunk
5.     {
6.         public float deltaTime;
7.         public ComponentTypeHandle<Rotation> rotationTypeHandle;
8.         [ReadOnly] public ComponentTypeHandle<Spin> spinTypeHandle;
9.  
10.         public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex)
11.         {
12.             var chunkRotations = chunk.GetNativeArray(rotationTypeHandle);
13.             var chunkSpins = chunk.GetNativeArray(spinTypeHandle);
14.  
15.             for (int i = 0; i < chunk.Count; i++)
16.             {
17.                 var rotation = chunkRotations[i];
18.                 var spin = chunkSpins[i];
19.  
20.                 chunkRotations[i] = new Rotation
21.                 {
22.                     Value = math.mul(rotation.Value, quaternion.AxisAngle(spin.speed, deltaTime))
23.                 };
24.             }
25.         }
26.     }
27.  
28.     public class SpinSystem : SystemBase
29.     {
30.         EntityQuery spinQuery;
31.  
32.         protected override void OnCreate()
33.         {
34.             spinQuery = GetEntityQuery(typeof(Rotation), ComponentType.ReadOnly<Spin>());
35.         }
36.  
37.         protected override void OnUpdate()
38.         {
39.             float deltaTime = Time.DeltaTime;
40.  
41.             var rotationTypeHandle = GetComponentTypeHandle<Rotation>();
42.             var spinTypeHandle = GetComponentTypeHandle<Spin>(true);
43.  
44.             var spinJobChunk = new SpinJobChunk
45.             {
46.                 deltaTime = deltaTime,
47.                 rotationTypeHandle = rotationTypeHandle,
48.                 spinTypeHandle = spinTypeHandle,
49.             };
50.             Dependency = spinJobChunk.ScheduleParallel(spinQuery, Dependency);
51.         }
52. }

You can EVEN use Jobs that you have written outside of Ecs to work inside Ecs. This is quite slow compared to rewriting it with Ecs in mind (relatively, it was like 2ms slower for 10000 cubes on 16 threads), but still faster than running the job in a MonoBehaviour.

Code (CSharp):

1. // This job can be written without any external Unity packages.
2. public struct SpinJobParallelFor : IJobParallelFor
3. {
4.     public float deltaTime;
5.     public NativeArray<Quaternion> rotations;
6.     [ReadOnly] public NativeArray<Vector3> spins;
7.  
8.     public void Execute(int index)
9.     {
10.         rotations[index] *= Quaternion.AngleAxis(deltaTime * Mathf.Rad2Deg, spins[index]);
11.     }
12. }
13.  
14. namespace MyNamespace
15. {
16.     public class SpinSystem : SystemBase
17.     {
18.         protected override void OnUpdate()
19.         {
20.             var rotations = spinQuery.ToComponentDataArray<Rotation>(Allocator.TempJob);
21.             var spins = spinQuery.ToComponentDataArray<Spin>(Allocator.TempJob);
22.  
23.             var spinJob = new SpinJobParallelFor
24.             {
25.                 deltaTime = Time.DeltaTime,
26.                 rotations = rotations.Reinterpret<Quaternion>(), // The rotations array will still update correctly.
27.                 spins = spins.Reinterpret<Vector3>(),
28.             };
29.             Dependency = spinJob.Schedule(spins.Length, 64, Dependency);
30.  
31.             Dependency = Entities.ForEach((int entityInQueryIndex, ref Rotation rotation, in Spin spin) =>
32.             {
33.                 rotation = rotations[entityInQueryIndex]; // Assign the values back to their entities.
34.             }).ScheduleParallel(Dependency);
35.  
36.             Dependency = rotations.Dispose(Dependency);
37.             Dependency = spins.Dispose(Dependency);
38.         }
39.     }
40. }

 

Since none of my existing scripts contain words like "Entities", "chunk", or "Job", I think your example demonstrates the exact opposite. The only way to not open them, if I want to make changes like these, is toss them out and write new ones from scratch. Either way, it would be nice to have some clear examples showing how to accomplish specific things, especially things DOTS might really help with, using legacy code and DOTS. Since this is more a change in our approach to coding, it needs to be presented as "When you want to accomplish goal A, instead of doing X, like you've always done in the past, you should now do Y." Instead of trying to translate each API call from MonoBehavior to DOTS, it would be better to go from goal -> solution via the two different routes.

There are other tasks we may have never attempted before, due to the high overhead, like animating huge schools of fish, or individual rocks in a planetary ring system. Examples of scenarios like these, stressing the potential performance gains from using DOTS, would help us, as you suggested, better pick our battles. Here's what I mean:

https://www.raywenderlich.com/7880445-unity-job-system-and-burst-compiler-getting-started

As I understand it, DOTS shines best when dealing with large numbers of similar calculations or actions, and is probably less useful for door triggers for instance - unless you have an insane number of doors.

 

I also share this sentiment. The Input System docs are a good example. We could use something like this for ECS - a handy reference that one can quickly consult while coding.

https://docs.unity3d.com/Packages/com.unity.inputsystem@1.1/manual/HowDoI.html

https://docs.unity3d.com/Packages/com.unity.inputsystem@1.1/manual/Migration.html

 

There is no way to automatically and efficiently migrate monobehaviour code to DOTS. It's like asking to migrate procedural code where everything is in global scope to object-oriented. If we are talking about any real and complex game it is impossible.

 

It’s like imagining an Unreal-to-Unity project converter. Could parts of it work? Maybe. Would you really want to use it? Probably not.

 

Damn. That's not even a bad analogy.

 

Exactly! It is Data Oriented Design, and it's different.

What I was trying to demonstrate is that you can migrate MonoBehaviour code to ECS without touching the MonoBehaviour code. You can have a perfectly valid MonoBehaviour script like "Spin", and you don't have to add words like "Entities", "chunk" or "Job" into them, that's my whole point: the MonoBehaviour stays untouched. That is the best result you could wish for when you are going through the laborious process of migrating your code to a completely different paradigm, especially if you use that MonoBehaviour code in different games which might not use ECS.

That would be the JobSystem, in which case I suggest this blog post.

You're right about documentation and examples being rather sparse in that area, in which case I understand your point more clearly. A converter is, as anyone may have gathered, unfortunately impossible, but examples we can definitely use and I hope the first out-of-preview packages won't be left without them.

 

Then I guess I just didn't understand your example. I still don't - most likely because it flew way over my head - other than "Keep your old scripts, but write new ones to do all the fun new ECS stuff when needed - because they won't write themselves." The most useful documentation might be examples of which types of mono scripts we can and should leave alone, and which would really benefit from ECS/DOTS rewrites.

 

@CaseyHofland I think there was a misunderstanding. He wasn't asking for a way to use both MonoBehaviors and ECS code in the same project. He was talking about a script - or a whole project - converter, which would take MonoBehavior code and change it to ECS/DOTS code.

Your comments confused the hell out of me too. But I think eventually I realized you were just saying it's possible to add ECS code to a MonoBehavior-based project to add speed in some cases.

 

That's a question only your profiler can answer. I know that answer sucks, but it is the answer.

Yes, exactly! Sorry it got out of hand X) I got a bit excited. I was mainly interested in answering "How do we provide an upgrade path for developers with existing MonoBehaviour based projects and code bases." and, well: that is it. A rewrite is absolutely necessary. MonoBehaviour and ECS is apples and oranges. The sooner one realizes, the sooner ECS will start to make sense.

 

If you want some examples of how GO code can be converted to DOTS this repository is a good source of knowlege.
https://github.com/Unity-Technologies/DOTS-training-samples
Note that if you want to see ported examples you have to switch to specific branch

 

While I think this is a really cool repo, not sure if this is going to help, its even more advanced than casey's example.

@FargleBargle If you have some specific examples of things you're wondering how to port to dots, it would be great if you made a new thread with them. There are lots of people here who would be happy to help out and discuss how the current state of dots relates to the current unity workflow everyone knows. Hopefully these issues can also help unity also see out how to address the current shortcomings when they see what specific problems users are facing.

 

At this point, no. I'm still trying to get my head around which parts of my project DOTS will have a significant impact on. The fish schooling example I provided above was the first that came to mind. I also use 3rd party assets like Vegetation Studio, which uses it to improve performance in large scenes. Other than that, most of the performance issues in my project are from large numbers of unique assets, that would benefit more from individual optimization than batching. That's why I'm looking for practical examples: to show me uses I might not have thought of yet, and help me better understand what it can do for me. If DOTS could take hundreds of high poly models, with dozens of textures each, and generate LODs, colliders, and atlases for them on the fly, so I don't have to optimize them individually, then we'd have something worth starting a new thread for - but I'm not holding my breath.

 

I think these things wouldn't necessarily be the responsibility Monobehaviour/DOTS/etc... at their core, but rather the responsibility of the tools & art pipelines on your project. Sounds like monobehaviour is a better fit for your project right now, but only by coincidence; because you have better chances of finding already-available third-party tools that do these things for monobehaviour projects than for DOTS projects. Like this for example

Right off the bat, if you profile your game and CPU isn't your bottleneck, then that would be a decent sign that DOTS won't solve your problems. Although, it depends... DOTS renderer could do a better batching/instancing job than the regular renderer, but I would expect something like Vegetation Studio to solve that problem.

-----------------

Examples of things DOTS would help with, if we're talking about a game where there's not a ton of stuff going on:

• fast, efficient level streaming
  
• better performance of physics queries (raycasts, OverlapSphere, etc...) and of rigidbody physics in general
• multithreaded everything
• better CPU rendering performance (aside from GPU-instanced stuff like Vegetation Studio)

And then there are other advantages that aren't performance-related:

• DOTS APIs in general tend to be better-designed and more powerful/versatile than their monobehaviour counterparts, and the source code is available and modifiable if you need to. Unity.Physics and Unity.Netcode are good examples of this
• DOTS generally makes it much easier to come up with a robust, scalable, non-spaghetti-code architecture that won't turn your project into development hell

And finally, there are things that are more complicated in DOTS than in monobehaviour:

• Dealing with transform hierarchies
• Dealing with cases where you'd want polymorphism (ex: an "ability system" or a state machine)
• "Reactive" behaviours (ex: raising my strength stat modifies my attack damage stat)

 

I am all for this and I am sure Unity will provide more documentation around this when they are ready. They had a demo (link below) about 2 years ago showcasing how to take existing MonoBehaviour code (that was causing a performance bottleneck) and converting it to DOTS. Granted, the API has changed since then. But I am sure Unity will provide similar (and more in-depth) examples like that when they are ready to roll out DOTS.

But honestly, if you spend some time just learning the basics of DOTS, the migration path from MonoBehaviour to DOTS becomes pretty obvious. And Unity's ECS works really well with the existing MonoBehaviour code. So you can very easily mix and match ECS code with Monobehaviour code. You can even write a system that queries existing Monobehaviour scripts.

Old outdated Demo for migrating existing Monobehaviour to DOTS:

 

I'm writing a repository that helps a lot for migrating your project to DOTS in an easy way
it streamlines the hybridization process between ECS and MonoBehaviour
I will let the link in here in case someone is interested (it can be installed also through the package manager)

I hope it can help someone!

https://github.com/Extrys/Hybrid-EZS

 

Any update on enable/disable component?