Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Official Notice on DOTS compatibility with Unity 2021.1

Discussion in 'Entity Component System' started by MartinGram, Apr 12, 2021.

Thread Status:
Not open for further replies.
  1. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    128
    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.
     
    PublicEnumE likes this.
  2. Guedez

    Guedez

    Joined:
    Jun 1, 2012
    Posts:
    784
    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?
     
  3. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,792
    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.
     
  4. exiguous

    exiguous

    Joined:
    Nov 21, 2010
    Posts:
    1,741
    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.
     
    Baggers_ and Ramobo like this.
  5. PublicEnumE

    PublicEnumE

    Joined:
    Feb 3, 2019
    Posts:
    729
    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.
     
    Last edited: May 4, 2021
  6. AdamBebko

    AdamBebko

    Joined:
    Apr 8, 2016
    Posts:
    158
    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.
     
    Baggers_, Tony_Max, quabug and 2 others like this.
  7. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,792
    You mean like this?
     
    Orimay, Ghat-Smith, Anthiese and 6 others like this.
  8. colin_young

    colin_young

    Joined:
    Jun 1, 2017
    Posts:
    232
    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.
     
  9. oldhighscore

    oldhighscore

    Joined:
    Nov 28, 2020
    Posts:
    74
    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.
     
    yinyinh likes this.
  10. tonialatalo

    tonialatalo

    Joined:
    Apr 23, 2015
    Posts:
    60
    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.
     
  11. oldhighscore

    oldhighscore

    Joined:
    Nov 28, 2020
    Posts:
    74
    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 :cool:
     
  12. tonialatalo

    tonialatalo

    Joined:
    Apr 23, 2015
    Posts:
    60
    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.
     
  13. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    839
    It's been more than a month. Any updates?
     
  14. PublicEnumE

    PublicEnumE

    Joined:
    Feb 3, 2019
    Posts:
    729
    I would guess the soonest we’ll hear about significant DOTS news will be at GDC in July.
     
    Ruchir likes this.
  15. Krajca

    Krajca

    Joined:
    May 6, 2014
    Posts:
    347
    I think that means a 0.18 update is to be announced or even released at the GDC. (pure speculation)
     
    Ruchir and PublicEnumE like this.
  16. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    148
    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.
     
    phobos2077 likes this.
  17. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    839
    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?
     
  18. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    278
    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.
     
  19. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    839
    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.
     
  20. PublicEnumE

    PublicEnumE

    Joined:
    Feb 3, 2019
    Posts:
    729
    It seems likely that none of this was an intentional choice.
     
    Anthiese and Ruchir like this.
  21. Deleted User

    Deleted User

    Guest

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

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    148
    They will, but not until the end of this year at the earliest.
     
    Deleted User likes this.
  23. Nyanpas

    Nyanpas

    Joined:
    Dec 29, 2016
    Posts:
    406
    Sometimes I do wish that an upgrade to DOTS would be as simple as this: multibehaviour.gif
     
    SMHall, mannyhams, Lex4art and 6 others like this.
  24. tessiof

    tessiof

    Joined:
    Dec 6, 2017
    Posts:
    25
    Why not StereoBehaviour?
     
    abixbg likes this.
  25. djsell

    djsell

    Joined:
    Aug 29, 2013
    Posts:
    77
    Yeah. Sometimes I wonder why Mazda didn't put a button in my car to turn it into a sailboat, too.
     
    argibaltzi, V_i_T, mannyhams and 7 others like this.
  26. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,791
    Dude, you should have gotten a Nissan, they have had working sailboat buttons for 3-4 years now.
     
    Lex4art, Anthiese and djsell like this.
  27. Nyanpas

    Nyanpas

    Joined:
    Dec 29, 2016
    Posts:
    406
    Only allows a maximum of two threads to be used... :oops:
     
  28. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,792
    I want a Citroën, like Fantomas has. It converts to an airplane with a push of a button.

     
    Anthiese and djsell like this.
  29. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    199
    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.
     
    Ruchir likes this.
  30. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,792
    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...
     
    Last edited: Jun 9, 2021
  31. RistoPaasivirta

    RistoPaasivirta

    Joined:
    Aug 25, 2017
    Posts:
    14
    Converting code into the entities system is not the problem.
    Converting people into the entities system is the problem.
    ;)
     
    mannyhams, Anthiese, Nyanpas and 6 others like this.
  32. Orimay

    Orimay

    Joined:
    Nov 16, 2012
    Posts:
    304
    [GenerateAuthoringComponent] is as simple
     
    Ruchir likes this.
  33. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    199
    .... 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.
     
    ftejada likes this.
  34. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    461
    A new engine is fine with me.
     
  35. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,792
    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...
     
  36. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    199
    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.)
     
  37. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    461
    Unity needs less auto magic.
     
    Anthiese, Tony_Max, apkdev and 3 others like this.
  38. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,791
    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)
     
    Anthiese, Krajca and Ruchir like this.
  39. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    461
    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.
     
    Tony_Max and iamarugin like this.
  40. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,791
    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.
     
    NotaNaN likes this.
  41. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    808
    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!)
     
    Anthiese, djsell, abixbg and 3 others like this.
  42. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    199
    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 :p) with over 10 years of experience. Not to brag, just to make clear I'm not just a script kiddie.)
     
    ftejada and Ramobo like this.
  43. Guedez

    Guedez

    Joined:
    Jun 1, 2012
    Posts:
    784
    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.
     
  44. RoughSpaghetti3211

    RoughSpaghetti3211

    Joined:
    Aug 11, 2015
    Posts:
    1,688
    Thats kinda cool
     
  45. Thermos

    Thermos

    Joined:
    Feb 23, 2015
    Posts:
    145
    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.
     
  46. Tony_Max

    Tony_Max

    Joined:
    Feb 7, 2017
    Posts:
    278
    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.
     
    Opeth001 and Anthiese like this.
  47. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    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.
     
    Last edited: Jun 12, 2021
    Nyanpas likes this.
  48. Micz84

    Micz84

    Joined:
    Jul 21, 2012
    Posts:
    408
    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.
     
  49. iamarugin

    iamarugin

    Joined:
    Dec 17, 2014
    Posts:
    808
    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.
     
    mariandev and Anthiese like this.
  50. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    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.
     
    koirat likes this.
Thread Status:
Not open for further replies.