Feedback DOTS Sentiment?

How about making DOTS part of Visual Scripting (if it isn't already)? Here's my DOTS vertex data output for that Fluid Simulation node, now if I just drag a noodle over to this here MeshFilter.. like 5 seconds of your day integrating multithreaded vertex processing and the mesh is splashing around right there in the Scene View, I will definitely be on board. Who wants to code things by hand with a more powerful alternative that's drag-and-drop? That would get me interested in both DOTS and Visual Scripting.

 

Unity's visual scripting is currently being developed for DOTS, and for the monobevaviour side they just acquired Bolt (different things)

Look for the sticky thread in DOTS forum

 

For me DOTS isn't just about performance, it helps me to think about the problem and figure it out in a more easy way . Like figuring out in monobehaviour what is an object and what data to use and where it should go was the majority of the work and I was stuck on a few problems because of it. I've probably got further than I ever have with the help of DOTS.

With DOTS and everything being data, and systems and data being separate(and technically both are data) it makes it much more straightforward. I just break down the problem to its raw data, figure out the exact data I need then how am I going to transform it. Also its quite easy to edit change things at a later date and debug things as all the data is separate and contained.

I really hope Unity does finish DOTS because if not I think I will give up game dev if they give up on DOTS.

 

Agreed. In general I would say that while DOTS makes the implementation of certain things sometimes more difficult than OOP, it makes the structuring of your code way easier and safer for scaling in the future. Overall, with all the pros and cons accounted for, it made coding much easier and less frustrating for me. And I really do believe it'll make game development shorter

I can definitely imagine DOTS making teamwork way easier too, because everything is so naturally independent and decoupled, and update orders are super explicit. Adding a feature becomes like just adding a step to an assembly line

The only bad side-effect is that now whenever I see a job offering saying they want "experience with OOP principles", I cringe a little . "OOP" has become synonymous with "abstract spaghetti code nightmare that becomes impossible to work with" in my mind, because it kinda tends to often end up that way on large team projects despite our best efforts. Now that I've tasted the comfort & clarity of DoD, I don't want to go back to the murky depths of OOP

 

Oh definitely it really can be difficult way more difficult than monobehaviour in implementing what you want currently. I have struggled a lot with it, especially with lack of docs but with help from people on these forums and Discord and some tutorials I've managed to learn quite a lot. I guess that's what you get for using something in active development though, I've even had to relearn things in it a few times. It should get easier when its finished and as more people start using it.

 

Unity dots animation development is going pretty solid should be usable in 2021 https://docs.unity3d.com/Packages/com.unity.animation@0.6/changelog/CHANGELOG.html

 

There's a lot of different sentiments here. It is time I give my two cents and maybe help calm some people down. If I am lucky, it will calm people down enough that Unity can focus on giving us more important details rather than addressing misconceptions. It is wishful thinking, but I've got nothing to lose.

Sentiments I agree with:
DOTS tech and especially ECS are not really beginner-friendly.
While I 100% believe that ECS and DOTS is a significantly better and cleaner way to write reusable game and engine code that scales, I also recognize that the knowledge bar to get started is a fair bit higher. Whether or not Unity wishes to address that problem is something I am looking forward to hearing. I have lots of thoughts on the matter, but I will spare them until I hear more.

We need more streamlined communication from the team rather than random forum posts.
I think every team in Unity needs to do this. That is by far the best way to check the overhyping marketing team while still maintaining trust by grounded developers. It will also allow the community to pick up slack that Unity might de-prioritize, allowing the community to jump-start around new products and features.

The package manager system got really messy.
Why are non-preview packages like Mathematics still being hidden?
How are we supposed to know the magic names of hidden preview packages? (Stop kicking this can!)

The Roadmap is due for an update because Unity did not deliver.
I didn't believe that roadmap for a second. It was way too ambitious and a bit of wishful thinking. Looking forward to a hopefully more realistic one!

Sentiments I disagree with:
The old DOTS Tiny Editor was good and the conversion workflow sucks.
Authoring in the tiny editor did NOT scale, nor was it intuitive to artists and designers outside of the basics. You were authoring runtime data, meaning you had to know how the code worked (or rely heavily on documentation) just to author things properly. It was fine for small projects. And what made the early community thrive was how many features it had and the platforms it supported.

One of the biggest necessities to make the performance benefits of ECS work while also being designer-friendly was to separate authoring from runtime data. This meant there was always going to be a conversion workflow. They could of chosen anything to be the authoring representation to convert from. They chose GameObjects because the code for that was already written. This all came about when they were building MegaCity probably because GameObjectEntity wasn't scaling.

You can use Jobs and Burst without DOTS.
Uhh, that is DOTS. Entities is just one package of DOTS that happens to be in preview and moves away from GameObjects and MonoBehaviours. But C# Jobs, Mathematics, and Burst are all production-ready for use with GameObjects right now.

I suspect Unity is using ECS as a way to highlight areas of the engine they can open up. The pieces they are opening up also benefit the GameObject world. Here's a few examples:

• TransformAccessArray
• RaycastCommand
• The low-level NavMesh API
• ParticleSystem jobs
• Animation jobs
• DSP Graph
• NativeArrays for Textures and ComputeBuffers
• Networking Transport Layer
• BatchRendererGroup API - While still in early development, this promises the ability to batch and instance objects without the need for custom shaders for each technique, as well as customizing culling.
• Acquisition of Bolt and NetCode for GameObjects - I suspect if Unity reveals their fabled new environment system in DOTS, that some environment Asset Store devs will receive acquisition offers shortly after.

For everyone who wants more performant GameObjects instead of ECS, you need to start trying these things and offering feedback in their respective forums. Those forums are really quiet right now.

Unity is allocating too many people in ECS and wasting their developers' time.
Even if it isn't adopted by the masses, ECS is still a powerful tool than some studios (especially larger ones) will wish to take advantage of. It brings value.

As for the topic of whether that value is worth it compared to what they could be doing instead, I don't think Unity even wants to answer that question. I think they have a different strategy. So I often search the corners of the internet for interest blog posts about people using DOTS and the job system to do crazy things. That underlined keyword leads search engines to give me not what I was looking for. But you know what I learned? Unity is hiring. A lot. This isn't a matter of Unity not allocating people to the right tasks. This is a matter of Unity not being able to find enough people to do everything they want to do.

Burst is useless when there is RyuJit.
Does Burst beat RyuJit for naively written code? No.
Does Burst beat RyuJit when you use the tooling to debug performance problems and insert metadata to allow it to make some crazy optimizations no other compiler is allowed to do? Absolutely!

Burst has a long-term value proposition, and it is very likely we will see Burst and RyuJit coexist peacefully in the future.

I am skeptical of Bursted systems though. That seems like a hack and not a solution, especially if it removes all our power to take control of system execution order.

The DOTS Team has been wasting their time within the last couple of months.
There are two things that have caused the slowdown.

The first is that 2020 happened. Unity emplloyees aren't immune to that. That's definitely impacted productivity.

The second is less obvious, and I mostly figured this out from looking at deltas in the code between Entities versions. Unity has been really struggling to stabilize builds, subscenes, and live link. They've spent a lot of time on it. Those two pieces address some of the weaknesses of the conversion workflow.

In another aspect, I think Unity recognized that releasing Entities 1.0 didn't really offer much value to anyone not already using it, because HybridRenderer and friends weren't there yet. If anything, I think they could have released Collections 1.0, but that saw a lot of development recently.

GameObjects will be phased out and DOTS will be the new default.
GameObjects are not going away until it becomes as under-utilized as Boo was. GameObjects are still their money-maker right now, and they are still adding new features for them.

Final Thoughts
I would like to see Unity not only discuss what they plan to do, but also give some insight into where the believe the community could pick up slack. That way, the community ecosystem has a more stable location to sprout its first roots.

I'd also like to see the community start articulating the specific problems they are having and the specific learning struggles rather than complain that everything sucks and is buggy. Not saying everyone here is doing that. Actually, the majority don't. But there's still room for improvement.

 

...This bit could probably be omitted from an otherwise great analysis.

 

I think a lot of this boils down to Unity's historically bad communication and aggressive, unrealistic timelines.

What's needed is consistent short term updates, things that they can actually answer with some degree of certainty. Like what is being worked on for the next package version. They need an approach that not only fits how software development actually works but also recognizes their own strengths and weaknesses. Unity is historically bad at predicting how long things take. So just accept that and use a process that fits the reality.

Long term roadmaps are mostly worthless, at least in the game industry. Studios live and die by their current game, and that game is generally a constantly shifting landscape. What Unity has planned a year or even 6 months out I can't do much with.

What I can use is what does the code look like now and what has it's history been. Like Unity.Physics sort of nailed it from the start I have pretty high confidence in that team. Hybrid Renderer opposite end of the spectrum, they just can't seem to get much right. ECS core in the middle but more towards physics, fairly high confidence.

So current state, history, and then if we had consistent updates on what is immediately next, I'd be happy. The rest I think it's unreasonable to expect any big changes. Companies and culture don't change on a whim or desire, sort of like people. You have to work with what you have.

 

It's actually really impressive how UnityPhysics kinda just popped into existence at some point and was fully usable and reasonably feature-rich right off the bat

 

This statement surprises me. Yes, the Hybrid Renderer had a rough start, but it is stable for me now with HDRP on desktop platforms.

On the other hand, my first impression of Physics was the exact opposite. It seemed to me that it was really only designed to work with authored colliders, and doing runtime collider generation opened you up to lots of undetectable memory leaks. It also seemed like if you wanted to have custom physics mechanics and interactions for different subsets of entities, that often involved filtering large event lists single-threaded for every event combination you cared about and hacking modifications into the right stages of an otherwise static pipeline.

Perhaps maybe this isn't a common use case for a lot of people, but it does make me wonder if I am missing something?

 

I'm using it for generating runtime mesh colliders and haven't had any undetectable memory leaks (it generates BlobAssets, so you need to dispose them). Mind you, I've only used them for raycasts/spherecats/etc, but it's awesome to be able to build a MeshCollider on background thread in 2ms instead of 15ms on the main thread like you would with a regular MeshCollider + sharedMesh.

 

Burst compatible systems would be nice. But there's still tons of code that isn't burstable (eg all the legacy code you've already written, or bought from the asset store, the scriptable render pipelines, conversion/editor code, etc, etc). Having a modern JIT and GC is a huge step forward, at least on PC and some consoles (PS4/Xbone). Anyway, that's largely tangential. We'll see what manifests with .NET 5.

 

I'm not against the idea of a conversion workflow in general, but I keep feeling like in its current form, it feels "hacky". And I'm not even sure I can clearly articulate why, but there is just something that bothers me about it. I guess my main source of confusion is because of the fact that it's based on GameObjects instead of a more specialized type of object/editor meant specifically for DOTS authoring and conversion, which wouldn't allow you to place anything on it unless it's DOTS/conversion-compatible.

 

I should have qualified HR V2. It's partitioning for culling and LOD is horrible, a better one that uses rendering appropriate partitioning will perform roughly an order of magnitude better. At one point I implemented culling and LOD using BatchRendererGroup directly which is what HR uses, which gave me more insight into specifically what HR was doing wrong. Indirect lighting still doesn't work correctly. Batch handling is screwed. Numerous rendering glitches. Some of this like the partitioning are pretty core and they gave no evidence they saw it as a problem. The rest I'm sure will get fixed eventually, but no comments on issues like indirect lighting that are serious enough to block us from doing demo's.

We moved away from HR for most stuff, only using it for animation now. Mostly because SRP batcher solves a sticky problem with customized characters that is not easily solved without it. Otherwise we would probably just render DOTS animation via DMI.

 

Might be able to offer a perspective on how this has been done differently outside of Unity:

I worked for a few years at a company with it's own ECS engine - we also had a differentiation between authoring data types and runtime data types. There was also a conversion process, but it wasn't done during runtime - we ran a manual build executable, to convert the authoring data to runtime data, and then save it to disc as json. This json was then loaded by the game at runtime, so we never paid a conversion cost during the game itself. The trade-off was that you had to run that build step every time any data was altered. It wasn't quick, so it couldn't be easily automated.

I can understand why it might be an attractive idea to Unity to use GameObjects as the method for authoring ecs data. I image the 'Pros' column might look something like:

• Our editor already supports them
• People already know how to write editor tools for them
• We don't have to create and support a 3rd, "first class" object type in the Unity ecosystem (GameObjects, Entities, and now "AuthoringEntities").

Sometimes I wish they had actually pulled the trigger and created a "DOTS-only" version of Unity which was completely separate from "classic" Unity. It would be easier to label it as an alpha, and DOTS packages could be incompatible with the "production ready" classic version. We could use some new custom, "editor-only" entities to author data before runtime, and they would only be allowed to hold ECS-ready components.

I wonder - if Unity could have known how long this was going to take, maybe they would have stuck with that decision after all. Keeping ECS in the standard Unity ecosystem feels like what you might do if you expect the whole transition to be over in 1-3 years.

 

to be fair, HRv2 is an experimental package within an experimental package... so I wouldn't be ready to make any judgements on it right now

 

I really think this would make it easier to learn DOTS, and potentially would even reduce the amount of work needed for Unity devs to ship DOTS in the long run (although I actually have no clue about that). The fact that entities, gameObjects and monobehaviours must all be able to coexist just makes things more complicated and confusing for everyone in my opinion. It's as though it gave you too much superfluous stuff to think about, and too many ways you could do things that you're not supposed to do. Sometimes it's better when there's one way of doing things

Besides, classic Unity would still have access to Burst and Jobs

 

Aren't subscenes pretty much the same workflow you used at your previous company?

Pretty certain unity already recommended against doing runtime conversion - it's extremely slow.

-edit- source https://forum.unity.com/threads/enter-play-mode-takes-20-30-seconds.908792/#post-5965349

 

I think it's fair to be harsh on core design flaws always. It's different then just some average bug and if I wasn't clear the partitioning was the deal breaker as far as the software design itself. The rest could likely have been solved via better communication. Worst case priorities just wouldn't align and that is what it is I can't fault Unity there.

 

The conversion is made at edit-time, converting at runtime is not the recommended approach. So the difference here is that Unity automates for us already the conversion stuff, instead of us needing to manually run a separated build for that.

On the other hand, I think that it could at least have some kind of warning when attaching a component in a GameObject inside a SubScene that doesn't have a related ConversionSystem (or have a proper way to debug ConversionSystem, at very least).

But it is still not version 1.0, so I am trusting Unity that those things will be fixed until 1.0 is released.

 

Runtime collider generation ya that is an issue but it's manageable. They made some intentional trade offs there. Filtering generally can get out of hand easily. We don't have a lot of use cases that need that. But there have been cases where it was the first obvious choice but we quickly decided ok we need to constrain this via other means or it will get out of hand.

 

I didn't even think to mention that use case. In GameObject world, you can actually encapsulate the lifetime of the BlobAsset, which makes this technique much more viable. I have worked on some projects in the past where that would be super helpful (in particular, dynamic painting of skinned meshes).

It is most likely use-case specific, because I am using V2 (0.7.0 is when the glitchiness was fixed for me) and I am getting proper motion blur and skybox reflections including some sky occlusion shadows despite not having any light sources in my scene (I actually have no idea what is doing that).

 

I'm with both @PublicEnumE and @PhilSA on this one.

I know people say hindsight is 20/20, but I really think Unity would have fared better if ECS had cut all ties to GameObject Land and had its own separate Engine, just as PhilSA and ol' Public suggested. It would have solved a lot of problems that are popping up now — especially the "ECS production is slowing down / overhype" problem.

Luckily,
it isn't too late for Unity to make Unity: ECS Edition, happen!
A large portion of Project Tiny is still intact, and the Tiny Team has already ditched Hybrid-Playmode (in-editor testing) in the most recent update (they are planning on adding in a Pure DOTS Playmode in the near-ish future).

Now seems like a pretty good time to create some newfangled Pure ECS Authoring Components and bring back the Pure DOTS Editor for Project Tiny!

Spoiler

Please?

 

my fingers are crossed for the upcoming DOTS blog post to announce something like that. Classic unity can distance itself from all that experimental stuff, and DOTS unity can be streamlined and focus on just the core DOTS workflow. It would make both sides of the Unity community happier

 

Here's my runtime collider generation code. To me this is pure awesome; not an issue at all. Can't get more straightforward than this:

Code (CSharp):

1. using Unity.Burst;
2. using Unity.Collections;
3. using Unity.Jobs;
4. using Unity.Mathematics;
5. using PMeshCollider = Unity.Physics.MeshCollider;
6. using PCollider = Unity.Entities.BlobAssetReference<Unity.Physics.Collider>;
7.  
8. namespace burningmime.unity.building.jobs
9. {
10.     [BurstCompile(FloatMode = FloatMode.Fast)]
11.     internal struct BuildColliderJob : IJob
12.     {
13.         [ReadOnly] public NativeArray<BuildingVertex> vertices;
14.         [ReadOnly] public NativeArray<int> indices;
15.         [WriteOnly] public NativeArray<PCollider> output;
16.      
17.         public void Execute()
18.         {
19.             NativeArray<float3> positions = new NativeArray<float3>(vertices.Length, Allocator.Temp,
20.                 NativeArrayOptions.UninitializedMemory);
21.             for(int i = 0; i < vertices.Length; ++i)
22.                 positions[i] = vertices[i].pos;
23.             NativeArray<int3> triangles = indices.Reinterpret<int3>(4);
24.             output[0] = PMeshCollider.Create(positions, triangles);
25.             positions.Dispose();
26.         }
27.     }
28. }

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

This makes a bit more sense. I'm surprised there's no clear way to attack disposables to associated entities.

Still, I don't see that as an unsolvable problem. You can keep a BlobAssetReference in a component, right? So when the entity is about to die, you could put the BlobAssetReference on a NativeQueue somewhere, and have a system at the end of the main thread to purge/dispose the queue at the end of each frame, or every several frames. I guess this could get ugly if you were destroying the entity from several different places, and perhaps difficult to scale to a larger team.

 

Yes! It’s a good comparison.

Those haven’t been at the front of my mind lately, because some bugs with subscenes have kept me from being able to use them in my projects.

in some cases, subscenes just never go through the conversion process - not immediately or delayed. Just never.

in other cases, they’ll go through conversion. But some conversion systems won’t run (although those same systems do run properly for runtime conversion).

Deadlines have kept me from being able to dig in and isolate these bugs, but hopefully one day soon.

 

I think most of those issues are due missing to use the ConverterVersion attribute, once I started to use those correctly I stopped having issues with SubScene not converting/updating converted stuff sometimes.

 

It also gets ugly if you are instantiating entities from multiple locations, destroying entities from an ECB the same frame they get instantiated (conditionally based on some authored value) and consequently missing the registration to a reactive system to catch it, or just copying and modifying the colliders without accidentally destroying the original prefab. I like to use colliders and spatial queries for a lot more than just physics where colliders have a transient nature to them, so this gets unintuitively complicated real fast.

With that said, I do understand how someone without those complex needs would have a different perspective of Unity.Physics.

 

Does a new dots only editor/brand new editor+engine really make the community at large happier? Bifurcation of graphics has led to a lot of confusion, fear & misunderstanding, and this is something where you cannot mix and match what you want(unlike how you can with dots & hybrid currently).

What happens when people want to use either classic unity parts with dots? Does that not work in a "core dots" workflow?
The time its taken to get this far while leveraging existing engine features has been a long one and we still don't have sound, navigation, animation, ui, input(I'd say rendering too given hybrid makes use of builtin, or the srps) - To replace it with a brand new engine and rebuild every bit that doesn't exist in dots currently, well game making in pure dots might become a legacy thing to be passed on to your children.

You'd still need to think of some sort of conversion because anyone with even a moderately complex project will have entities everywhere due to the flattened nature of things(see physics as a good example).
I cant really imagine how many entities a complex AAA character will comprise of. Not to mention there are some really, really ugly looking components at runtime, this is nowhere near what any designer would want to be manually setting up.
If conversion gives people pause, pure dots editing will send beginners running for the hills in gibbering madness(hell I wouldn't really want to touch my entities runtime data and I coded them).

If anything my sentiment on the Editor part is: I don't want a new editor to load up, I want to see more iteration. I think the dots editor team mentioned they were thinking long and hard as how best to approach the problems, but I want to see more experimental stuff that gets thrown in, dissected and either tossed for better stuff or refined for better stuff. I want to experience the change that so often gets brought up as a case against dots(but imo thats really not the case).
Remember when we had inject, and component data arrays? Those were good stuff, until they got replaced with even better stuff. Give me more preview stuff than I can handle

 

Managing lifetimes is a challenge, but I don't see that as a knock against Unity Physics. That's just part of working with low-level code. If it's too complex/finicky to do manually, the next step might be to use reference counting (for example, a SharedStatic NativeHashMap with atomic integer counts, or if you're feeling ambitious make a

std::shared_ptr

equivalent). Or you could somehow try to hook in with the existing garbage collector (for example, make a class with a destructor, and use GCHandles to pass it in and out of burst).

I remember you mentioned having your own physics stuff in your framework; how do you manage object lifetimes there?

 

So my Collider type is a 64 byte union struct (same size as LocalToWorld for reference) which can store any primitive type directly (Sphere, Capsule, Box, Plane, Cone, ect) or store a reference to more complex data either as a BlobAssetReference or an Entity reference to an entity with specialized components and dynamic buffers. Blobs can only be created via GameObjectConversion, so they get tracked by the conversion process and the subscenes (this is still buggy because Unity does some inconsistent nonsense in this regard). The entities can be automatically managed with LinkedEntityGroup.

The primitive types being self-contained in the Collider type covers most of my "transient and mutable" collider use cases.

 

That's true.

I think I've changed my mind like 5 times during the course of this convo on what would be the best course of action for DOTS, and I'm still unsure. It's like there's never a perfect solution. Always a balancing act between making things clear/streamlined, making things accessible, making things not take 5 years to finish, and making things intercompatible.

I think i'd say this regarding the conversion workflow: we don't necessarily need a completely new editor for it, but I do wish we had something a bit more clear and "controlled" than the current gameobjects approach where you could easily do things that don't make sense for conversion. I imagine something like a new "ConvertibleGameObject" that gets autoconverted, can switch between runtime/editing modes if not in a subscene, and can accept either "AuthoringComponents" (for adding pure ecs components) or "ManagedComponents" (for adding class-based components). No monobehaviours or regular Unity components like Rigidbody would be allowed on those; only component types made specifically for DOTS

But the thing is: if you were to ask me what exactly could go wrong with the current GameObject conversion workflow, I'm not even sure I could give you a good answer. I guess it just adds too much cognitive load for me because it isn't focused/specialized enough? I'd want something that enforces the "real" workflow and doesn't allow anything else. No monobehaviours that have their own Update() when you're actually supposed to get your Update() from systems, no authoring components that can also be monobehaviours that stay there and do their things, etc...

 

My sentiment is DOTS is great, data oriented programming is the future and we will get their eventually without the friction we are currently facing. But we have to be patient and vocal about what we want and expect. Just from a very programmer centric perspective this forum is great. There's not much that can not be answered here and when things fail and have errors we get an answer and a bugfix. As there's this race between the core Unity engine and Entities the release cycle is not as fast as some would wish but we will eventually settle on something more stable. Stable enough that bugs can be fixed entirely in the ECS package and not require a new Unity version too.

Having said that, of course there are still frustrations that I share with many of you. This can go pretty wide and I try not to focus too much on the details because my biggest gripe is a broad one to begin with:

Lack of hybrid approach
Currently there's no straight-forward way, at least not in the way what we usually expect from Unity, for hybrid modes which keep the MB world intact and have the ECS world take care of the major parts.

This builds a pretty big boundary between the Unity users who lack the coding experience and ECS veterans.
As my signature reads, I have a 3rd Person Camera asset and since ECS has arrived I'm thinking about porting it to ECS. Is there demand? No. Would it be cool? I guess. Would it be more support work for me? Absolutely.

I don't have a 100% proofed workflow for everyone who uses my asset in ECS but in contrast I do with the MB workflow.
So even though I want to support ECS, after 2 years it's still not time to pull the trigger.

So in my opinion Unity has neglected the hybrid approach. The conversion workflow IS great, it's just, that it has little to do with the hybrid problem. We have GameObjectEntity and the copy transform systems but why do WE have to do that?
Isn't it obvious to the engine what needs to be done? Maybe I'm oversimplifying and ignorant but I don't imagine adding a better and performant GameObjectEntity in C++ that handles just the transform calculations automatically is such a big deal.

I personally don't have much issues setting up hybrid mode because I just write what I need. It's still a pain and I'd rather like to avoid it. When ECS is a programmer only thing and others stay away we all have a problem.
Unity with their public image, asset store devs with their customers and the programmers because everything could be way simpler to begin with and time better spent elsewhere.

Solutions?
When samples are more like professional assets integrated in the package manager.
It's nice that Unity has a DOTS character controller in their samples but ever tried ripping it out? Scripts are all over the place and what should be a simple copy paste of a folder is a careful hunt where all the scripts are that are needed.
With the package manager I'd expect scrolling down a list, clicking on DOTS character controller and have an authoring component just like the MB character controller.
Or better yet, have the DOTS character controller already built in when Entities is loaded so feature parity is a given with built-in Unity components.
That way the transition would be seamless even for users who will never touch any code and still gain the benefits of ECS and the performance that goes with it.

I understand that getting there is slow but Unity has to start somewhere and nothing is happening even though the code already exists for a long time. It first dropped in the DOTSSample (I believe) on Dec 6th 2019.
As with most samples, they are neglected and never updated to new Entities versions which is a real shame. NetCode is currently a good example of sample maintainance, so special shout-out to the team. Others should strive what they do.

 

Here's what I think would be a streamlined approach that is clear about what it wants you to do and doesn't go in all directions just for the sake of supporting stuff from the past. I'm interested to see if we can brainstorm about the validity of this:

• Everything that lives on a DOTSGameObject must specifically be an "DOTSBehaviour" (TransformBehaviour, PhysicsBodyBehaviour, MeshRendererBehaviour, etc...)
• DOTSGameObjects are always autoconverted, but can be toggled between runtime mode and editing mode
• DOTSBehaviours are in charge of creating components on their Entity if they want to (similar to authoring components), but they're not obligated to do so
• DOTSBehaviours doesn't have an Update() by default like Monobehaviour, but can subscribe to an Update callback from a specific system. There would be a few default systems for DOTSBehaviour update callbacks (Update, LateUpdate, FixedUpdate, etc...)
  
• DOTS systems are in charge of processing ECS data and writing all the pertinent data to those DOTSBehaviours (the updated pos/rot in TransformBehaviour, the updated center of mass in PhysicsBodyBehaviour, etc...)
• DOTSBehaviours can now read/write that data in their subscribed Update() callback
• DOTS systems then write back the data from DOTSBehaviours to the ECS world

Anything that happens in a DOTSBehaviour Update() would be preceded by a completion of all jobs. That way, DOTSBehaviours could do all the reading and writing they want without worrying about anything, and that also means that user-made DOTSBehaviours would never have to know about ECS at all. They could do everything they want in non-ECS land, but ECS would do the heavylifting behind all of it. Users who want to stick to pure ECS would also be perfectly able to do so

I haven't thought about all this for long enough to be sure of it, but it would be my initial suggestion. I really do feel like we have no not be too attached to Monobehaviours and legacy components in order for this workflow to be crystal clear, though

 

I was actually thinking of something similar. A DOTSBehavior could have an API close to GameObjects just without all the deprecated cruft and embracing DOTS as much as possible.

 

@PhilSA your approach seems to be more designed towards being able to create new behaviours to work with ECS specifically, what about for existing non-DOTS stuff?

I think that the new HybridComponent stuff is close to be the solution for that, the issue right now is the need to explicit call AddHybridComponent for every single component we want to be converted (why not just a toggle box in the inspector? on by default, please). That, combined with an option to let the generated companion GameObject drive the ECS transform, would already make the majority of existing assets to "just work" with ECS.

I mean, it is ok (for me) if in an ECS-project I am expected to just use ECS-way for programming new stuff, but at least I want to be able to use existing stuff too inside the same project without much headache.

 

Regular GO/MBs could still be in a scene, but they wouldn't have the thing where they're allowed to write to data that the ECS handles. I can't think of a way to make that work because you necessarily need a point where ECS transfers all its data to the "behaviours", waits for modifications, and writes back that data to ECS

 

I believe if you put a GameObject with traditional components in a subscene or convert a prefab the entities automatically are created with a CompanionObject ICD referencing it. I think there's still plenty of other unexpected stuff (like MonoBehaviour code wouldn't run) and I'm not sure if this works with a complex hierarchy.

 

Neat. So the MeshCollider data (eg the BVH) is stored as a BufferElement on an entity? If so, don't you still need to manage the lifetime of that entity? LinkedEntityGroup might help you keep track of dependencies, but it doesn't destroy itself.

 

Only those components that have a GameObjectConversionSystem calling AddHybridComponent on them (like SpriteRenderer and some other stuff).

What I find quite unnecessary since it could be a simple toggle, not to mention that it still misses a way to use the companion's transform to things be fully functional.

Yeah, that makes sense when you want to code in MB way some stuff and integrate with ECS in a safe way, what I am saying is that for existing MB stuff (Asset Store, for example) what we need is a ready-to-go integration (without requiring to write conversion systems/workarounds for every single component).

I might write something along those lines myself when I find some proper time to do that, but for now I am hoping that Unity will take care of that for me.

 

Yes, but to a much lesser degree and it is significantly easier to track.
A) Entity data is mutable, which means I am not constantly creating new instances every frame where such a memory leak would be a major problem.
B) For such a collider that needs to be a unique instance for an owning entity, it just has to be part of that owning entity's LinkedEntityGroup, which means Instantiate and Destroy fully manage memory there (most common use case).
C) It shows up in the EntityDebugger, so it is easy to see if I have a leak.
D) If all else fails, my scene manager will wipe it out on scene change, or it will be destroyed when the World is destroyed.

In contrast, I just recently discovered an issue where if you use runtime GameObject Conversion, none of the generated BlobAssets get tracked, whereas they do with subscenes. If you are writing a GameObjectConversionSystem, you have no way of knowing this, so it is not like you can work around it by trying to track a dispose the blob assets yourself, because attempting to dispose a blob belonging to a subscene will fish you an exception. The worst part is if you use runtime GameObject Conversion and don't track the blobs yourself, you will never see the memory leak error.

The Blob story in Entities is really ugly and poorly documented right now. That's a new sentiment for this thread.

 

I've been using DOTS only to work on a Company of Heroes type game, so I don't have a very diverse opinion. Unity's DOTS ecosystem has been adequate, but not comprehensive, for the following reasons:

Abstractions:
ECS's abstractions make your code both change-proof and easy to work with. Regarding change-proofability, by hiding groups of closely related but still subject to change components under an authoring that represents a behaviour, you make it easy to swap out which data the authoring represents without ruining your Scene. Regarding ease of work, the abstractions behind the job scheduling system are a godsend. Multithreading is extremely hard, but the scheduling system hides it all behind an easy interface - just specify your read-write dependencies with your logic, and the scheduler takes care of the rest.

Ease of testing:
In ECS, testing is as simple as creating entities holding data, activating a select subset of systems (for unit testing) or all of them at once (for integration testing), and asserting on the resulting entities. You can be as granular as you want about which logic and data you are testing. No longer do you have to wire up dozens of modules just to test 1 feature. This speeds up development - provided you've created some support code to do things like choose which systems to run, spawn up input entities and data, or make reusable assertions.

Performance:
In late 2018 I gave up on my game project because upon getting my Monobehaviour raycasting-heavy pathfinding code to work, I found out to my horror that it took 200ms to calculate ONE path. 200ms for one path, where a few dozen need to be calculated within one frame. However, then I learned about DOTS in early 2019, and by summer, by gluing together the async navmesh api, Unity.Jobs, Unity.Physics, and PandaBehaviour, I was able to produce a pathfinding module that calculates those same raycasting-intensive paths in less than 1ms. It was a life saver. Performance gains such as this make computationally-intensive game ideas a real possibility. This democratizes game development by unlocking entire genres of games (RTS games especially) accessible for inexperienced developers. The limiting factor is the extensive knowledge needed to squeeze out every bit of efficiency from ECS. You gotta learn about chunks, chunk occupancy, read-write dependencies, Burst best practices. It's a huge time investment but definitely worth it if you're building a game with lots of agents.

Overall, the core features are working as intended and advertised. It's just that entire features are missing. Animation, navigation, AI - those alone were the features I found lacking in my limited experience. Other developers have complained about the poor rendering and networking support. Again, if you narrow your expectations to what Unity has worked on most intensively (Entities, Physics), and write code or use Assets to fill in gaps, you won't be disappointed.

I've already reconciled with the fact that animation, navigation, and behavior trees won't be available in DOTS for a while, and wrote glue code to interface between their Monobehaviour APIs and the rest of the codebase in DOTS. It was an alright experience - honestly all my game project needed were ECS, Jobs, and Burst for the gamebreaking computations, and Monobehaviour for the rest. The same may not be true for others, though.

 

Since there seems to be some chatter on the subject, I write a framework for doing simulation with DOTS and using GameObjects for presentation: https://github.com/tbg10101/DOTS-Hybrid-Simulation-Worlds

I have no idea if it is any good but I’m using it for one of my games.

 

Clearly there are some issues, but I find them quite useful for managing complex/nested structures. For example, say I have a structure like this (psuedocode):

Code (csharp):

1. PropSet:
2.     List<Prop> listOfProps
3.  
4. Prop:
5.     List<PropMesh> meshes
6.     PropNavigation navData
7.  
8. PropMesh:
9.     List<float3> vertices
10.     List<int> triangles
11.     int materialId
12.  
13. ...

(basically, lists within lists or lists with different types/lengths). You could attach them via a spaghetti of buffer elements and/or flattened NativeArrays, I guess, but that gets increasingly complex and hard to manage. With blobs, you can design the structure naturally. They also allow variable-sized types (eg "classes"/object-oriented code), since you just have a pointer to the header. (also, don't tell anyone this, but I once modified a blob asset using a pointer and got away with it)

Maybe the solution is to give some way to bridge the gap between entities and BlobAssets. There seems to be something there with BlobAssetOwner, but as you pointed out, it's all very undocumented.

 

I don't know why so much talk is here. Has it been slower than what we wanted yes but Mostly what I see is people wishing things have been easier or more integrated to GameObjects.

DOTS in its current form and even a year from now was usable for certain things, not for say asset store publishers or ... but you could use it with GameObject if you wrote the interoperability layer yourself which wasn't hard.

Better messaging is good and faster results is even better but I don't feel most of the confusion here. In unite they said they are making the multiplayer open world shooter and making animation and terrain and other packages with it and also talked about the roadmap. If it is too early for you then you can wait until it is more ready.

I don't get those who say it should be stopped or it is something nobody wants, we are doing a pre-production with it and we know animations which is the last part we need will be ready until we are out of pre-production based on its updates. We are not having most of the issues here. We did not try to customized physics package yet for example but that is understandable to be hard right?

 

I'm not sure about that. In our project, I'm replacing the MB-approach for one system that has to deal with lots of objects/entities and is performance-critical with the ECS-approach. Almost everything else in the project doesn't seem like it could benefit from DOTS/ECS at all, so if I started with that project from scratch, I would probably use a very similar separation. Building the whole thing in ECS wouldn't work, so a DOTS-only Unity wouldn't be useful in our case.

But ... I'm in the middle of that replacement ... might have to revisit that thread when I'm done, or, in case I gave up on the journey (that would suck, but doesn't look like it will be happening at the moment).

 

A bit late on discussion but want Unity to hear the feedback too.

Since DOTS have totally difference fundamental than the classic Unity.
I totally agree that trying to duck-tape DOTS together with MonoBehaviour and old GameObject world is the odd move Unity can made.
It's make ECS guys life harder to build game on top of GameObject based editor.
And also make entry barrier so high for Unity Classic guys to shift to DOTS.
Which means Unity lost in both user segments.


Second part is DOTS design itself,
I loved ECS, Always use Entitas to build games.

While I need to know the inside out of how tech stack work in order to get start with DOTS properly. It's mean DOTS seems to have either not good or not really care about the API usability at all.

The only things attracted me to DOTS is performance. But if DOTS going to succeed only performance pillar without anythings else then it's mean Unity have completely destroy it's own success factor "Everyone can build a game".

 

We at least know that Unity is fully aware of this and that they are actively working towards the goal of making DOTS easy

https://forum.unity.com/threads/state-of-ecs-dots.1044877/#post-6761749

When I re-read this post, I think the delays we're seeing right now make sense (maybe not the silence; but the delays yes). Making DOTS easy to use and fully integrated with the editor sounds like a very large task that would no doubt take months or years to pull off

 

A concern I have had recently is does it matter all the performant implementations I do in my own code, if Unity's otherwise overhead outweights or offsets it? Won't it just be marginal gains on something I might have spent months on improving?