Official Notice on DOTS compatibility with Unity 2021.1

Yeah, that is a totally reasonably explanation. And I understand that they are still figuring out the best way to proceed. I just wanted to share my frustrations and experience with this because the original post made it sound like none of us were on unity 2021 yet, nor should have been. Maybe that is the intended path for working with the entities package, but my experience with other preview packages led me to believe otherwise.

I understand there is a preview label on the entities packages and things like this happen. I look forward to hearing more about their plans for future versions.

I decided to downgrade now because I thought that an issue I was experiencing was possibly one of the incompatibilities with 0.17 and unity 2021. Turns out it wasn't, but now I'm hopefully in a better place to upgrade to future versions of the entities package which I have been looking forward to.

 

Heck, the most frustrating part is not know what they know about the incompatibility. As far as I care it could be either something banal as "This part will show a bit bugged in the editor" to something serious as "These whole lot of methods will not work on 2021.0.9f12 because they use a Mono internal memory function that is not available in dotNet and there are no alternatives to it without rewriting the whole thing", or maybe it's even something that only breaks on Ouya builds.

The fact that people are managing to get it working on 2021 spells that it is either something banal as the first example, or the current version of 2021 does not yet have said incompatibility but it will be soon introduced in some update. Hopefully the Unity team share more information before I was planning to update, so I can make a more informed decision, as it stands I will just update and hope for the best while keeping a branch on the old version in worst case scenario.

Do those that have it working through workarounds have tested building it? Does it still works in standalone?

 

Just to be precise, because it is important: there is an 'experimental' label on the Entities. If it were 'preview', it shouldn't happen.

Dude, Unity never shied away from some level of bugginess if in exchange they could push out something which helped a sizeable portion of their userbase. Just look at SRPs, InputSystem, etc. They have some quirks here and there, but they pushed them out so people, who doesn't need those parts could use them, because they are awesome otherwise.

Nope. Look at the roll out of Burst. It wasn't working on many things and we got it regardless. They will roll out the rest later. I really think if they found that Entities doesn't work on 2021 on XBox One or PS5 or whatever, they still would go ahead with it because of the rest.

Or it does have, we just don't know about it, because it didn't surface it properly on our test projects. But yeah, it is possible they didn't want to stuck in a minor version of 2021.1 and a later update to it (which isn't out for us yet) will totally break Entities.

Anyway, it's pure guessing game.

 

Thats the whole point. If they just told what happened a lot of people would understand that because most of us do mistakes from time to time. And personally I see no reason to keep the information until they found a solution/fix. People can only make good decisions on things they know. If UT is "hiding" important information they prevent people from making good decisions.
It's not bad that crap happens in SW development. It happens everywhere. But it's bad for many people not to know what causes their "inconvenience".
So IMO it is the information (or lack of) strategy from UT most people are concerned about.

Knowing what the problem is would allow people to investigate and analyse properly. Maybe find workarounds. Maybe change plans. Maybe do something else. Not knowing what is happening just keeps everyone in limbo.

 

No argument here - knowing more info would usually help developers.

But in this case, they’ve messaged pretty hard to us that there’s a reason they haven’t said more. It seems likely that the incompatibility has to do with some unannounced feature or software direction. They might not be able to even comment on what the incompatibility is without giving up too much information about what the unannounced thing is. And since Unity is a business, they can’t always share everything they are doing. They have competitors, and they’re also an IPO.

More important than that, they also have customers, who make planning decisions based on what they believe Unity might be working on. Sometimes internal development doesn’t work out, and they might be working on something that they aren’t 100% sure what final form it will take, or when.

I’m expecting this would be a new Unity engine feature - not something DOTS specific. Seems plausible that a non-DOTS team, working on some upcoming engine feature, changed the engine code in some way that they didn’t realize would break Entities. Then the DOTS team found out about it after the change had already gone in. Probably a bad day for some folks.

In a case like that, it’s understandable why they might have thought it was best not to be too specific until they could give more reliable information.

Would that mean that Unity messed up? Yeah, as a company. It’s a flub. But that doesn’t mean the DOTS team did. I would rather they have given us a warning as soon as they could, rather than let us run into surprise problems without any warning. Even if they can’t give more information.

 

I think could have avoided this whole thread by just adding a paragraph saying, "we're really sorry we can't release more information at this time, we understand this is inconvenient, but please only use 2020 for now until more info comes out. We're working hard on it!". I think that single line would have saved a huge headache.

 

You mean like this?

 

Unity is now a publicly traded company. It's possible they can't say more at this point for obscure legal reasons having nothing at all to do with technology and making no sense at all when viewed from a technical perspective. This is of course wildly unsubstantiated speculation based on no actual evidence.

My experience in working for publicly traded companies is that they can be very cautious about what information they let out, especially when it concerns future products.

 

I was thinking along these lines when they seemed to "shy away" from the PR on the new tech stack after going public. Definitely a big no no to offer up forecasted solutions probably because this can inflate the stock and cause misdirection either benignly or just by missing the mark on what they "promised" to deliver. Not a market expert, but I have also worked for said corporations.

 

Yes, I can confirm this - Unity folks said it directly in a call a few months ago, they can't give such promises due to stock market rules.

 

Well I see this leaning towards everything is fine side. It would be crazy to think that they would drop 3'yish years worth of investments into a new tech stack in addition to probably making a copious amount of money from going public. With their own investment and now public investors, I would hope that if anything whatever shifts they needed to make mid last year pan out by now a year later and things get into full swing by end of the year and into 2022. I'm betting DOTS will be at a minimum in beta by 2022, it's really their only big club against Unreal 5. And then after all that maybe Microsoft buys them up, ya never know I just want things to wrap up before I need to release my game so I'm along this experimental roller coaster for now

 

Yes. Also, haven't people used DOTS for long in production already, some optimizations for array operations or so? At least there has been some serious seeming work done with it in companies outside Unity for a year or two, no? Haven't needed it myself yet, have tested Tiny though.

 

It's been more than a month. Any updates?

 

I would guess the soonest we’ll hear about significant DOTS news will be at GDC in July.

 

I think that means a 0.18 update is to be announced or even released at the GDC. (pure speculation)

 

Well we now know since a couple of days what is actually breaking. The whole assemblies of ECS are appearantly just broken and will not be loaded and throw many errors in the latest 2021.2 beta release.

 

Interesting, did you or anyone else find out at which version this is starting to happen and what's the reason? Is it a17?

2021.2.0a12 is working fine. a15 has a lot of burst related changes. Is it even burst related?

 

It could be that its just replacing the old implementation, meaning that they won't be changing the ecs interfaces a lot anymore. So, like changing a graphics card.

I would be more alarmed, if they could not do that.

 

I don't think they will change their stance but I still want to voice my opinion that being stuck on 2020.3 is really discouraging.
2020 wasn't a good release cycle to begin with and 2020.3 is especially slow in so many regards. Just the startup of a non-dots project with like 150mb of data is taking 1 minute. In 2021.1 it loads in like 8 seconds. The editor is more responsive and there's all the other new features and stability fixes.

A bad time to be working in DOTS. Why don't you make the split in 2021.1? I just don't understand really.

 

It seems likely that none of this was an intentional choice.

 

Please support DOTS in 2021 versions because I require deferred rendering for URP

 

They will, but not until the end of this year at the earliest.

 

Sometimes I do wish that an upgrade to DOTS would be as simple as this:

 

Why not StereoBehaviour?

 

Yeah. Sometimes I wonder why Mazda didn't put a button in my car to turn it into a sailboat, too.

 

Dude, you should have gotten a Nissan, they have had working sailboat buttons for 3-4 years now.

 

Only allows a maximum of two threads to be used...

 

I want a Citroën, like Fantomas has. It converts to an airplane with a push of a button.

 

Jokes aside, the "classic", monobehavior way is already a component based approach.
Turning them into structs where possible and introducing struct variations when needed would have been a more natural integration. The "turn GO into entities" pipeline is already there anyway.
This would probably be less flexible in some corner cases but a hell lot easier and more natural for the rest than the "scratch the entire thing and learn a completely new engine" way that we have now.

 

1; you don't know that. You know that Unity propagates an approach like that. Users do whatever they want.
2; MonoBehaviour components != DOTS Component, not even close, not even the same universe
3; even if they were, you can automatically "convert" a couple of components, hurray, you have done the 1% of the work which can be done by any random monkey, including this one, who is randomly writing this comment on a typewriter. The real, hard work isn't converting the components, converting the data structures and algorithms...

 

Converting code into the entities system is not the problem.
Converting people into the entities system is the problem.

 

[GenerateAuthoringComponent] is as simple

 

.... what?

"Component" is a rather abstract concept that has existed since the beginning of software development. Regular unity has a component based architecture, always had.
Ofc MonoBehavior != DOTS structure, who said otherwise?

We final users don't have to care about what happens behind the scenes in an engine (unless the engines forces u to cuz it's badly designed). There are infinite approaches to how to expose the functionality DOTS provide to the final users (us).

Unity chose the one that allowed the DOTS team to be as independent and crazy as posible without any regard at all for current/established styles, naming, workflows, etc. That gives them a lot of flexibility but on the other hand means not friendly at all for us, since we are forced to learn a new sub-engine, a new API style, new naming conventions (once they finally decide on one), new workflows, etc.
I'm not taking about having to think differently, that's inevitable. But u don't necessarily need a new and completely different API style and workflow to code/think in different ways.

If an analogy helps, over the past decade a lot of "functional" languages were created and/or became popular. But u don't really need a "functional language" to think and code in a "functional" way. Most OOP centered languages can be used to program in a functional way albeit having more or less syntactic sugar.

 

A new engine is fine with me.

 

Let me know when you finally decided what you're talking about: converting existing complex, user-authored code bases into algorithms fit into ECS/DOD or helping people to write complex code and algorithms fit into DOD/ECS... I answered to the first, you're trying to argue with me on the second which I didn't even touch, so...

 

I was talking about keeping most of the "classic" workflow even for DOTS stuff. Be it by converting standard components when possible, having us use new but almost identical "struct components" when needed and even "converting" user defined components to an extent when possible (have unity extract variables into structs, and turn Awake, Start, Update methods into "systems" automatically.) Pretty much what u can do now with some GO->Entity conversion but better, as a defined and important workflow instead of "just a plus" like it is now.

If u though I was talking about having a more or less complex project and automagically turning it into DOTS, well, no xD

(Although it would be nice having Burst automatically trying to convert non-burstable code into burstable code by generating structs out of classes when possible, etc. super super hard to achieve and very fragile but would be cool.)

 

Unity needs less auto magic.

 

Auto magic is fine as long as it is not a black box and we can tinker if it is needed.

(although I guess if it's not a black box it's not "magic", in which case I agree with you)

 

Even if you have source code minimizing code churn and stylistic commits is recommended. It is extremely easy to introduce side effects into complex systems which you do not fully understand. I have a hard enough time understanding the issues in my own code base.

 

I wasn't talking about source access.

And maybe I'm a little off topic, I'll explain myself better here, but I'm a bit too tired today and maybe some things have gone over my head, so in case I'm going on wild tangents... please ignore!

But:

I think the reason why people (me included!) hate Unity's auto magic, is because Unity doesn't really allow us to understand what is happening and / or change how the feature works.

On the other hand, there are other features that are completely manual and there is no easy way to make them work without extensive scripting, which is often annoying when you just want to get a part of your code to work and you don't care about making it work right, at least right now.

So in my mind the perfect solution is an auto magic feature, that "just works", that is extensively explained in the docs about what exactly is happening, and that it has an example script that overrides it ("here is how you can override the default bevahiour, replicate it with a script so you can remove and add according to your needs"). This seems like the kind of auto magic feature, one that let's me get to other, potentially more important stuff faster, but isn't a black box that I don't understand and can't interfere with <- and I don't think that part requires source access, just well designed APIs.

 

As a programmer with a 10 years experience I can't see how it can be implemented except for most trivial cases. Even if this was in theory possible it would require thousands of man hours spent on something that will give us questionable result.

I would prefer this time spend on improving DOTS editor workflows (select entity in a Scene Window or creating entites in a hierarchy without subscene workarounds), developing missing systems and adding double quaternion into Unity.Mathematics or at least math.mul(quaternion, double3) (for the God sake, space simulators is a thing!)

 

Well, u are asking for things we could have had from day 1 if unity followed a different approach. If by definition the workflow to create an entity was something like:
right click in scene view -> entities: -> new entity
and an item appears in the scene view almost identical to a regular gameobject but with an "entity" icon.
Then u can add entity components from the editor the same way we do for gameobjects (said components wouldn't be the exact same under the hood obviously, but almost identical in surface), etc..

Same with prefabs, etc.

Maybe unity will get there in 2/3 more years xD
But they prioritized a 100% code approach breaking all existing unity naming, style and workflows.
Idk what's better for unity as a company but for me as final user, it was a poor choice.

(To be clear, I use DOTS for hybrid render, and I'm a programmer (engineer with a phd ) with over 10 years of experience. Not to brag, just to make clear I'm not just a script kiddie.)

 

Supposedly the GameObject => Entity workflow was meant to be the workaround that gives you the closest thing to adding a Entity to a scene. But I never liked it and prefer always adding Entities and Components programatically.
I went as far as making systems that match Entities with ComponentA but not ComponentB, ComponenetC, ComponentD, and thus ComponentA becomes some sort of "prefab tag" and the system automatically adds ComponentB, ComponenetC, ComponentD to anything with ComponentA.

 

Thats kinda cool

 

I have another idea that could ease the upgrade process.

Engine uses entities under the hood, GameObject(Which is just a reference to an entity) and everything belongs to monobehavior become hybrid components. Old code still works, but performance will get a significant gain because of Hybrid Renderer V2, and every other built-in components translated to DOTS. Most of the time the code won't touch static Monobehaviors like Mesh Renderers, if they do need that, they toggle on [Preserve] on the Monobehavior inspector title bar or they will have null reference exception.

By default, old projects will have [Preserve] toggled on, while new project is toggled off.

If some day user want some part of their code to be performant, they rewrite that part using Entities.ForEach.

 

DOTS is not monolithic and consists of burst, jobs and unity ECS implementation. And the first two is already integrated to some built-in code and to some non dots packages. ECS first of all is a way you write your code and only secondly "performance" because of linear data access. So when you say "i want my project converts to DOTS automatically" you ask for some black magic like codegen under the hood. Or i'm not clearly understand what you mean.

 

I think that was the original plan: Rewrite built-in

MonoBehaviour

s with DOTS while keeping the same public API. Hopefully that's still planned.

 

I have never heard any one saying this. Auto converting user created MonoBehaviours to ECS is impossible to do right. One thing I can see be done is some things in background using jobs and burst. But it will not beat something build form ground up using full DOTS.

 

It's like automatically rewriting procedural code into OOP while keeping the same language constructions and not adding the new one.

Again, DOTS is not about just API, it's way you thinking, writing your code and organizing your data.

I had a real-scale quadtree planet generation system in the Mono world. Then I spent a week and rewrote it entirely on DOTS.
These two systems so different in every way, so any conversation wouldn't be possible. If you will make something more complicated on DOTS you will know it.

On the other hand I see that it is possible to keep the whole Editor workflow that we have now. Like attaching components and creating entities in the hierarchy. It is a lot of work but I don't think UT will release entities without it.

But rewriting the code will be our job.

 

What part of "built-in

MonoBehaviour

s" do you guys not understand? Unity rewrites the backends of their components with DOTS; end-users are left to do the same to their own components or go pure DOTS if they want to — both manual conversions. I'm asking for transparent backend changes that benefit everyone if possible, not a "Convert my project to DOTS" button.