Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Official DOTS Development Status And Next Milestones - December 2021

Discussion in 'Entity Component System' started by LaurentGibert, Dec 9, 2021.

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

    LucasRun

    Joined:
    Jul 2, 2019
    Posts:
    1
    I really do hope using DOTS will become much simpler. Early versions were not too intuitive in my opinion when it came to coding.
     
    chadfranklin47 likes this.
  2. mischa2k

    mischa2k

    Joined:
    Sep 4, 2015
    Posts:
    4,347
    There's one thing I meant to ask for a while.

    With DOTS' NativeArrays that point to native C++ memory, being limited to HPC# etc.
    In the end, is there really a huge advantage over using a system language like C++/Rust to begin with?

    I can't be the only one to notice the friction happening due to that HPC# <-> C++/Burst interop.
    Where as with say C++/Rust, all the language features would be native compiled all the time.
    Without being limited to a subset, compiling only parts of the code with a different compiler etc.
     
    Last edited: Dec 10, 2021
  3. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    333
    I understand why hybrid support makes sense in the short to medium term and needs to be there, but as a longer term thing I would like to see it slowly become standard or at least common to take an Everything DOTS approach to new projects. Is the long term plan to facilitate this, or will engine features continue to be fragmented between the two, forcing hybrid use?

    What's the rendering situation? Will we have complete feature parity with GO rendering? Will we have BIRP support, or are we stuck on the new pipelines?
     
    Nubnubbud, kvfreedom and Krajca like this.
  4. Singtaa

    Singtaa

    Joined:
    Dec 14, 2010
    Posts:
    492
    Any specifics on what the new conversion workflow will be like?
     
  5. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    470
    VFX Graph are using compute shaders not CPU sim...
     
    unity_8p6oRXXqiWbRTQ likes this.
  6. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    4,223
    I think at least some of that impatience came from the fact we never really got a good explanation as to why the packages stopped. The only answer we ever really got was along the lines of "there's an issue with how we release packages" which could be interpreted as corporate drama or broken dev ops. And while some of us had a hunch that you were closing things off to focus on improving quality which perhaps required some risky changes and experimentation to get right, it wasn't until this thread was created that we learned that was more or less the real reason. I'm only saying this in case you weren't aware of this perspective. Regardless, thank you for finally providing us real insight into what is going on! You made the right choice in telling us about this now rather than waiting any longer (even if you totally miss your target timeframe, communication is more valuable than none).

    For those of us early adopters who have built custom solutions for our problems, are there any workflow, paradigm, or API changes we should be mentally prepared for with the next release?

    I'm asking less about new features and more about changes to existing features.

    What kind of backward compatibility should we expect with code targeting the currently available packages?
     
    deus0, DrBoum, colin_young and 10 others like this.
  7. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,631
    I understand.

    I will concede that the amount and placement of light probes in the FPS demo doesn't really work as an example of "bad practice", because short of creating a whole new set of tools and features specifically for the demo (and I do think demo scenes should try and stick as close to vanilla Unity as possible, we don't want another "Occlusion Probes" situation), there isn't anything clearly better that could be done here.

    So, instead, I think it works as an example of a gap in Unity's feature and tool set. I think this is off topic in this thread, so I won't expand further, plus it has been discussed 3+ years ago and not much has changed since then.
     
    deus0 likes this.
  8. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    At the moment our focus is simply on shipping a great baseline integration in the editor. We'll see what the future holds beyond that, but we have clearly heard from users that they want us to focus and ship a robust baseline they can use to ship ambitious games.

    Our current plan is to have fully MeshRenderer parity with HybridRenderer. From lightmaps, lightprobes, motion vector etc. Both URP & HDRP. We are not planning to support BIRP.
     
  9. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    That's very much our focus.
     
  10. RoughSpaghetti3211

    RoughSpaghetti3211

    Joined:
    Aug 11, 2015
    Posts:
    1,697
    How does Tiny fit in with all this?

    EDIT : I just wanted to add that project tiny examples are fantastic are should be looked at as a template for ECS.
     
  11. Rocky_Unity

    Rocky_Unity

    Joined:
    Oct 13, 2017
    Posts:
    96
    This is fair, I can appreciate that.

    I too, hope that it can be deterministic. If only from a Multiplayer perspective :)
     
    deus0 likes this.
  12. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    333
    I appreciate the answer, thank you.

    That robust baseline makes a lot of sense as a first/immediate priority.

    I have to say, the lack of BiRP support is disappointing. The stuff in the Focusing on Shaders post sounds promising for making the SRPs a reasonable choice in the future, but that's still years out. That post is clear about supporting BiRP, because they understand that people will be using it for a while to come. With the lack of basics like surface shader equivalents and the fragmentation problems, the SRPs just aren't a good choice for many people at the moment. If you're forcing people to choose between BiRP and DOTS, that's an unfortunate place to be. I would strongly urge you to consider allowing BiRP to be used with DOTS.

    Out of interest, are there some technical reasons why this is Hard, or is it simply not considered a priority?
     
  13. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    333
    Will it be possible to take an Everything Systems approach? If I'm using classic components, will it be reasonable to write all of the logic for them in systems? Does the hybrid approach still expect us to be putting some bits of logic in MBs? Will the APIs around that integration be tidied up?
     
  14. Deleted User

    Deleted User

    Guest

    What about gameobjects like "Camera", can they eventually be converted to entity? Can everything eventually be converted to entities?

    I want an approach that's fully DOTS-based and separate from monobehaviour completely.. can we expect that by 1.0?

    Please answer Unity!
     
  15. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    not for 1.0
     
    chadfranklin47 and Antypodish like this.
  16. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    doesn't VFX run on GPU? if so there's no gain from making it an entity.

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

    I'm amazed by the amount of people that think a DoD is the perfect solution to all and every problem and think combining tools (gameobjects, ecs, etc are all tools) is some kind of deadly sin :shrug:
     
  17. FrancoRet

    FrancoRet

    Joined:
    Feb 4, 2020
    Posts:
    3
    Exactly the same here! It's like the most important feature that we're waiting for, because it would allow us to implement a beautiful online synchronization in our app. So I guess I have a similar question! Is float determinism part of the plans of the release of ECS 0.5 or 1.0?
     
    Last edited: Dec 10, 2021
    Menion-Leah likes this.
  18. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    714
    So in short: No pure DOTS ways of handling button clicks and Ui events?
    • DOTS Cinemachine?
    • Inputs?
    • Animation graphs / blend trees ?
    • Audio sources?
    • Terrain and tree rendering?
    Can we get a clear list of what modules are going to be DOTS-friendly?

    At the moment, does it look like late Q1 2022 for 0.5? What's happening to Unity Tiny? What are the odds that it drifts to Q2? Can you share a bit of info of anticipated breaking changes for that version? Will consoles be supported?
     
  19. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    I wouldn't be expecting any of these before entities 1.0 is released.
    Such features requires solid functional DOTS core.
     
  20. EliseoPixowl

    EliseoPixowl

    Joined:
    Oct 28, 2019
    Posts:
    5
    I'm incredibly happy about this! Thank you Unity Team.
    That said I'm also a little bit concerned about netcode or tools being named so little.

    Netcode is in a very raw shape right now that with a ton of limitations and very few examples on how to do things, constantly pushing you to do workarounds in complex scenarios.
    For example, in case you need a synced entity that needs to change behaviour by removing or adding components during its lifetime.

    And the tools, while useful for most common scenarios fall a little short sometimes. For example, the entity debugger would be wonderful if I could extend it by writing custom tools, or simple things like clicking in an entity and if it has a translation/renderer then highlight it in the scene view, or if it has parents show them in a tree. Etc.

    If I remember correctly there was the Project Tiny that has some of the things I'm talking about here, its Project Tiny part of this roadmap as well?
     
  21. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,114
    @Joachim_Ante Ya. I'm refer to dots runtime UI package for UI Elements that I expect I can use burstable system to wire this runtime UI to replace game object based UGUI. Will this package available at dots 0.5?
     
  22. eterlan

    eterlan

    Joined:
    Sep 29, 2018
    Posts:
    177
    Why so hurry? It already said it's not production-ready at the very beginning. Just regard these package as something interesting to know. I admit I never thought it would take this long to release a 1.0 version, but that's totally fine for me.To build sth like this is hard and taking lots of time, and it wouldn't hurt any existing engine workflow anyway.
     
  23. sheredom

    sheredom

    Unity Technologies

    Joined:
    Jul 15, 2019
    Posts:
    300
    In the Burst team we definitely haven't canned the feature, but nor have we worked out all the issues with determinism (testing to ensure what we promise is as deterministic as required being a big issue!).

    We've been focusing for quite a few releases now on iteration speed with Burst, since so much of our user content is now required to go through Burst for performance reasons, and that has been a priority for the team. But I'll take a note of your request and share it more broadly within the team!
     
    kreso, Menion-Leah, jmcusack and 13 others like this.
  24. s_schoener

    s_schoener

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    81
    Netcode is part of the releases and still a focus. There is new tooling as well that is intended to replace the Entity debugger. I'm not going to speak for these teams, but there is a lot of active development in both of these areas :)
     
    phobos2077, jmcusack, MehO and 9 others like this.
  25. s_schoener

    s_schoener

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    81
    We're of course always trying to minimize breakage, but we're still deprecating things that clearly shouldn't be used anymore and have good replacements (JobComponentSystem, anyone?). I still think it's in everyone's interest that we do the breakage before going to a fully supported release. From the top of my head, there's nothing in 0.5 that would absolutely wreck current API uses, and in the cases where we did deprecate something there should be a clear update path.

    Edit: One exception that I remembered now is that hybrid components are now called companion components and their public usage is deprecated. Right now the plan is that it will be a purely internal feature in the future.
     
  26. ElliotB

    ElliotB

    Joined:
    Aug 11, 2013
    Posts:
    268
    I am very much enjoying hearing news, thank you for sharing these updates and it's good to hear things are in motion.

    Regarding tiny, which a few above also asked about (sorry if I missed a reply, I couldn't see one) - if tiny is no longer happening is there a plan to introduce a webgl build target for dots? There was a _very brief_ window where HR+2020 would work for webGL builds but I think the most recent version is again not working.

    (I realise webGL was never officially supported, it was more a fluke that it worked, but it is a really great platform for devs who rely on platforms like itch for exposure)
     
    Ferb and gwelkind like this.
  27. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,114
    @s_schoener I dun think it's really good idea to deperecate public usage until u can make companion components support game object based components properly. Is the below issue already been solved at dots 0.5?

     
    Lipoly likes this.
  28. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,084
    This is the exact level of communication I was hoping for when talking in the other thread. Completely sincerely: thank you.
     
    NotaNaN, Ronsu900, DrBoum and 5 others like this.
  29. Deleted User

    Deleted User

    Guest

    Can we be fully dependent on DOTS without using monobehaviour completely by 1.0?
     
    deus0 and bb8_1 like this.
  30. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    no
     
  31. Deleted User

    Deleted User

    Guest

    I'm sorry, but I wasn't directing my message to you, it's to Unity!
     
  32. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    they answered it already.
    which is an aswer to
     
  33. Deleted User

    Deleted User

    Guest

    Still, it doesn't answer my question. They were talking about the pipelines(urp/hdrp), and I'm talking about monobehaviour; Two completely separate things!

    I want an answer from them directly so I can confirm that.
     
  34. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    Sure. However DOTS team already has pointed out few posts above, which features wont be ready, or available. Meaning, you will be depending on either custom solution, or MB.
    Even now, you can make most of the game made of DOTS. Depending what you need. As already mentioned earlier, it is nothing bad, to mix GOs with DOTS.
     
  35. Deleted User

    Deleted User

    Guest

    Well, I prefer a complete approach to something, DOTS in this case.
     
    deus0 likes this.
  36. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    they are not solely talking about pipelines.

    'At the moment our focus is simply on shipping a great baseline integration in the editor. We'll see what the future holds beyond that,[...]'
    is actively talking about
    'I understand why hybrid support makes sense in the short to medium term and needs to be there, but as a longer term thing I would like to see it slowly become standard or at least common to take an Everything DOTS approach[...]'
     
  37. Deleted User

    Deleted User

    Guest

    That's my whole point! Thanks for answering yourself!
     
  38. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    '[...]shipping a great baseline[...]' is referring to 1.0
     
    SergeyVolik and charleshendry like this.
  39. Deleted User

    Deleted User

    Guest

    Ok, I'm gonna spend my time to a useless conversation. I will wait for their definite answer!
     
  40. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    Many of us would prefer too. Yet unfortunately, we may need to wait few years, to get to that point. Myself I would love to have audio solution using DOTS.
    But instead waiting, I have implemented convenient DOTS/Go solution within few days. It is a good trade off. Sure, other features may require more work.

    For example, most devs need rather simple UI, with not huge amount of data to be displayed. Current Unity native UI solutions are fully capable of. But interestingly, we had some examples of DOTS based UIs.
     
    Orimay and Deleted User like this.
  41. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    i also want a pure dots workflow. audio solution for dots is DSPGraph btw
     
    Deleted User likes this.
  42. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    The answer is no. Even Unity said no, in this thread (UI for instance). Also please refrain from cross-talk or arguing with other members.

    (off topic may be deleted)
     
  43. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,631
    Not supporting birp is a bit of a bummer, but on the other hand, if HDRP can get a pretty decent performance boost (especially on CPU) without requiring a completely new workflow, I think it will suddenly fall into “appealing” range for me. So all in all these are good news and more than I expected.
     
    MadeFromPolygons likes this.
  44. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    333
    I'm curious what this means. Will we not be able to access the companion components from systems?
     
  45. thelebaron

    thelebaron

    Joined:
    Jun 2, 2013
    Posts:
    851
    Animation graphs and blend trees are already in the animation package. We don’t yet have state machines or events or a working visual editor for it though and graph node changes are somewhat tied to the main thread.
     
  46. desertGhost_

    desertGhost_

    Joined:
    Apr 12, 2018
    Posts:
    259
    Will there be releases like 0.6 or will patches just be 0.5-preview.01, 5.0-preview.02, etc?
     
  47. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    It's not so much about making everything DoD; but more about making more things unmanaged so they can be easy to work with from jobs. I think some things can easily stay hybrid/managed without any real negative consequences (UI, for example), but other things would get a good ease-of-use benefit from going pure DOTS

    Anything included in a prefab that you might want to instantiate a lot of at runtime would be a good candidate for going pure DOTS in my opinion. So for instance, if you need to spawn lots of projectiles and your projectiles need audio:
    • Going with a pure DOTS audio solution means you can just call "Instantiate(projectilePrefab)" as much as you want in a job & set its data directly without worrying about anything
    • Going with a hybrid (gameObject) audio solution means that all of a sudden you need to take time to create a whole pooling solution that knows how to deal with entity prefabs that are instantiated from jobs via ECB. Not only that, but you might also need a way to set params on the managed audio component after instantiation, and you have to be able to set those from jobs; it's another extra bunch of code you need to write
    "Not having to worry about GC or pooling anymore" and "being able to do everything from jobs without coding any extra steps" is one of DOTS's ease-of-use superpowers, but that superpower is lost as soon as you need to go hybrid for a specific thing. I think this is a valid reason for hoping for more pure DOTS support in future releases eventually. Performance and ease-of-use can sometimes be two sides of the same coin

    The fact that VFXGraph is currently a managed component means that you'd end up with the issues described above if you were to have projectiles that have a VFXGraph component. A pure DOTS VFXGraph component wouldn't make any difference for particle counts & would still do most of its work on GPU, but it would make a difference when it comes to how much work is required in order to spawn lots of VFX instances efficiently

    ________________

    With that being said, I'm really happy about this news, and I think the decision of going hybrid at least for the near future makes perfect sense because it does sound like the most realistic objective to have right now. I don't know exactly which systems will need to stay hybrid for 1.0, but even if it's things like the audio scenario described above, I'm sure we'll still see big performance gains in the overall project either way
     
    Last edited: Dec 11, 2021
  48. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    333
    Yeah this. I haven't touched DOTS in more than a year now, but when I was trying it for a project I ran into this a lot. I found that almost every type of entity that I wanted to dynamically spawn needed some type of hybrid component, and this negated a lot of the benefits of going with DOTS in the first place. For example, I had a bullet hell style test, but each bullet had a little light on it, and there's no pure DOTS light component. If I really cared, I could have custom rendered them into the GBuffer, but at that point why am I using DOTS in the first place?

    Unless something has changed in the workflow and performance here, I do feel like we need DOTS equivalents of all common components like lights and audio sources.
     
    chadfranklin47 likes this.
  49. Krajca

    Krajca

    Joined:
    May 6, 2014
    Posts:
    347
    This and moving data to the ECS world. Still need some stupid conversion components while on MB there was only a reference in the script.
    I need to make a conversion component, singleton component (probably IComponentData), and even then If my data is managed I need to come up with something else. All that for some asset to be accessible in the one system that uses that data. Of course, I can set up value in that system directly, but as far as I understand that is not a preferred way to do it.
    Additionally, singletons come with the cost of a full chunk even if it's only an int value.
    The idea of singleton components isn't bad, but the execution seems lacking.

    Does v0.5 have any changes to address the issue? Or are there any plans for it in 1.0?
     
    SamOld likes this.
  50. slims

    slims

    Joined:
    Dec 31, 2013
    Posts:
    86
    This is truly fantastic news.

    I've been developing a game since early 2019 using DOTS. We've been successfully testing and expanding the game using 2021.2.3 with Entities 0.17.0-preview.42.

    My question is: for Entities 1.0, will there be significant architectural or otherwise breaking changes for teams that are already using Entities 0.17? Our code base has many dozens of systems and is pretty much full DOTS to the extent architecturally possibly, so I'm concerned about upgrade efforts, but also eager to get my hands on the new version.
     
    deus0, gwelkind and Jawsarn like this.
Thread Status:
Not open for further replies.