Official Experimental Entities 0.50 is Available

Hi @elliotc-unity. Can u take a look at Case 1424453? Is the issue needs to fix by dots team or burst team?

 

Excited, can't wait. I'm so big into DOTS and ECS now it's not even funny.

 

I didn't expect, you will become such big addict, in such short time

 

I think it becomes obvious extremely quickly on trying out 0.50 and the corresponding samples

Heck of a lot of work involved there though. Hats off to all who has worked on this.

 

@hippocoder what is your thoughts on current usability of ECS in conjunction with (some) regular monobehaviours in places. Not for anything coming out soon, but for stuff that might be released in 3-4 years time?

Currently have a few things in our game that could probably benefit from entities, but not everything will and I am trying to evaluate if its time to get stuck in yet or not, so yeah interested to hear your thoughts if you have been getting into it already

 

Well, I got my project converted from entities .17 to .50, and other than the terrain being super dark for no reason from having to switch from built-in to URP, it appears to work properly in the editor.
The main issue I'm having is once built for Android using this mess:
https://docs.unity3d.com/Packages/com.unity.entities@0.50/manual/ecs_building_projects.html
My game launches and it's just the UI and the terrain and seemingly all entities are missing. (They have URP shaders and show up fine in play mode)
Maybe I'm missing some component on the new "Build Configuration Asset" thing?
Anyone have any ideas?

 

I have a case study for that right now. Currently I am running the regular navmesh package to calculate path corners. I pass this information to a system that provides components path .corner positions.

Do this maybe once a frame, so it doesn't end up blocking main thread in any meaningful way, and my framerates are great. I don't think it is worth doing what they did in various NavMeshQuery implementations because the code for that API is a white hot mess that would cause me pain and suffering further down the line.

Sometimes the problem isn't really DOTS but the fact existing GO/Mono land is. DOTS is the solution to that, but there are missing things.

Also there is a LOT of code out there that comes from pre 0.5x release, which is mostly stuff people are trying to figure out, and I would say the majority is over-engineered. So learning Entities or DOTS in general will give you a lot of examples that are just people's own interpretation on what to do, from a time when the info was even more scarce.

If, like me you are interested in keeping to the most modern API then your life will be as easy as monobehaviour to put together game functions that are highly accelerated.

The interop between GameObjects and DOTS is trivial, easy. So you can use DOTS as a spot-fix for anything in any GameObject based game. I actually recommend taking a look it as there is no way DOTS can function on it's own right now.

Again though due to all the code out there from pre 0.50, you may find learning it harder than it should be (it's really not that hard, but the baggage built up in the last 4 years has made it worth keeping in mind there are newer, fresher, easier ways to do things).

IMO ready now for adventurers like me (I came after the pioneers on this area of the forum who bravely cut themselves first - they know who they are and have my admiration).

It's ready now for solving problems now because Job System was launched 4 years ago, and DOTS as we know it is more than just Jobs, it's ECS and also it's all those missing systems like streaming, occlusion, physics, hybrid renderer - all these things are usable today and frankly I'm bloody impressed.

Anyway, it does require a programmer used to quickly sifting through a LOT of old / stale information, bloated codebases (no fault of the authors, just a reflection of DOTS at the time they wrote the code). So if you're touching it with a light touch - say you want to just have some streaming, occlusion and fast rendering, then you could do this with almost no code if you know where to poke. If you want thousands of bullets and env collisions, that's OK too, but means you can't talk to Physx side or Physx colliders without extra code. I don't know what use-cases you have but the idea of DOTS being separate from GameObject/classic Unity is over. Expect the two to be in most games from here on out. It's just wickedly fast and absolutely perfect for fixing Unity's older codebase.

Don't go in thinking all or nothing, just a portion of classic Unity, a portion of DOTS, that's a great way to start.

 

Please consider adding color coded icons for Systems / Queries window similar to how R/W/Excluded is displayed in Entities Debugger. Its super handy.

 

Amazing, thanks for the in depth analysis this has been super useful. I think based on what you have said, it certainly is perfect for my use case (which is basically as you said, using DOTS to improve efficiency in some key areas where Monobehaviours are a bit of a poor fit / wasteful, whilst retaining MB for everything else that makes sense for it).

Im taking a look through the 0.5 entities api now and my god its improved a ton since the last time I took a deep dive into DOTS land. Things seem to be much more usable, everything was just sheer pain to use before and that was really offputting.

I certainly will bare in mind that its a changing API and that many examples etc floating around are using old code and therefore lack relevance or are completely irrelevant now.

Thanks mate!

 

As someone who has been focused on building true ECS solutions for a lot of the missing features (for personal reasons), I'm very curious what approach for interop you gravitated towards so quickly. Also, are you are using subscenes?

 

I am simply setting the components for primary pathing Entities. Those that have a flag set for it (a path request). Then the system for navigation will lazily get some corners from main Unity, and set those components. This in itself would be slow usually but it's only one path a frame. I am certain this is the most simplest approach (I'm trying to keep all my stuff really simple, but moving forward because as you know - I am learning). These lead a bunch of boid-like Entities which have richer parallel AI that don't depend on paths but do much more raycasting and so on.

It's not a lot of traffic between classic and ECS worlds (once a frame if that!). However, there is a lot of additional AI logic I plan for local seeking / sensing / cover and so on that I want to keep as stateless and parallel as possible, so while paths solve dead ends, most of the AI will not be needing pathfinding calculated per frame or even often.

I can't see myself always wanting this, but I'm pretty cautious around experimental API.

This is only for my learning project, and I would absolutely love a proper 0.50+ stable navigation solution, but it is outside of my expertise in ECS / DOTS. I think there's a whole bunch of problems I can stumble into with my ignorance at the moment. I also noticed Unity said quite clearly it's on hold with no plan at all for it (on the roadmap).

I am using subscenes as much as possible. I haven't done much testing on them but so far, so good. Can't bake navigation without the subscene open of course. Why did you ask?

 

I was more asking ECS/MonoBehaviour interop in general, not so much nav meshes. A lot of people find it difficult to reference scene GameObjects that don't have a good ECS implementation (like Mecanim) from within subscenes. There are a few different solutions, but they all tend to involve some indirect route. So I was curious if you settled on a particular approach to this yet?

 

I guess I'm going to answer my own question further up about entities being invisible when built for Android to help out anyone who has the same issue...
There are a ton of restrictions on what is actually supported by Hybrid Renderer V2, and that is why entities weren't rendering for me.

1: URP or HDRP only. Built-in is dead. (I wish built-in support was kept honestly, since URP still can't match built-in mobile shaders for performance, and like, isn't performance the name of the game here? For me no matter how much of an improvement there is upgrading from 0.17 to 0.5, since I have to use URP instead of built-in mobile shaders it still results in a net loss in performance. Granted it's not significantly worse performance.)
2: Vulkan ONLY on Android! This is kind of huge. Pretty much only newer phone support till Entities 1.0. (You have to actually go in and turn off "Auto Graphics API" and disable "OpenGLES2" and "OpenGLES3" in Graphics APIs.)
3: Linear Color Space ONLY. No Gamma. (Another thing where now the higher performance version isn't supported. Ugh.)
4: On the URP Render Pipeline asset "SRP Batcher" has to be enabled.
5: Make sure you build with the new "Platforms" Package and create a "Build Configuration" and use the "Build and Run" button on the Build Configuration asset and not in the usual spot in the menu.

Unfortunately, for someone like me trying to make something for Android, the things listed above are big enough drawbacks that the best course is to stay on 0.17 at least until the Entities 1.0 release with at least OpenGLES3 support.
Even then, 0.17 running built-in mobile shaders and Gamma lighting mode will probably still have higher performance for mobile than the final 1.0 release. With OpenGLES3 support, it'll probably be worth the performance loss to not have 0.17's random project-breaking bugs though.

 

Can someone in this thread tell me what the latest status of entities + Unity 2021 LTS is? Does it work yet, or not? I saw that 0.51 is meant to handle that, but I also have heard some conflicting stuff from some other developers so any clarity would be great

 

0.51 is not yet released. (latest is 0.50.1 for 2020.3)

 

Thanks!

 

Is there a shortcut to see generated sources?

Also, I've encountered a memory leak in one of the systems' ForEach, but not sure what is causing it.

Edit:
Nvm, it turns out to be somehow related to the custom bootstrap and disabling automatic world boostrap. Probably related to some new feature that has been added and is my fault.

Haven't found a way to open generated sources unless errors pop up.
So it seems sources aren't actually preserved after being compiled into dll.

 

Decided to take a better look at what approaches there are out there, including porting an older sample (zulfajuniadi). I can see why you asked, there's a few different ways to handle this. Mine is not optimal it seems. Wonder if Unity plans anything more for interop?

 

hippocoder posting DOTS feedback on code and DreamingImLatios providing it is an incredible learning opportUNITY for us learners.

 

Ok, so I figured out what's causing native leaks with custom bootstrap.

No InitializationSystemGroup means no WorldUpdateAllocatorResetSystem which resets some kind of internal allocator (?).

If anyone else encounters ~1mb leak/sec behaviour, make sure you've got logic identical to WorldUpdateAllocatorResetSystem (state.m_WorldUnmanaged.ResetUpdateAllocator()).
Adding it as first in begin frame phase does the trick, but unfortunately requires package modification.


To UT:
Having a mechanism to override system update group attributes in custom bootstrap would be really handy.

 

in DOTS authoring and debugging workflows in the Unity Editor | Unity at GDC 2022 they use Unity 2022.2 to demonstrate DOTS autoring workflow.

 

I want to thank Unity for their efforts in DOTS new features and optimizations.
Unfortunately, we only see the tip of the iceberg, and we don't realize the amount of hard work behind it.
usually people come here to ask questions about issues they are facing and don't take the time to say thank you.
so thanks again Unity <3 <3 <3
I'm really super excited with DOTS again

 

Sorry for the negativity but I find it hard to be exited when the presenter has a hard time dealing with the workflow himself :S

 

DOTS is recent in UNITY and it is quite normal to be difficult at the beginning.
even simple things like speaking while building words and sentences were so difficult at some point we just dont remember it .
to be honest, looking at the GDC once has already given me everything I need to know about these tools.
even though I can't 100% remember how they work, I know exactly what to do, so if I feel the need to use one of them, It just requires me 10 minutes to review that part.

 

There is still some legacy stuff lurking around and missing animation and navigation are fairly big pain points so a project relying on those will encounter non trivial hurdles.

 

I've recently been getting "Exception: This method should have been replaced by codegen" error messages whenever I try and install entities 0.50. I've filed a bug report. Has anyone else seen this error and know how to correct it?

 

Are you using Unity 2021 by any chance? This happened to me, currently Entities is only supported in Unity 2020. It will be updated for 2021 between May and June in theory. You can downgrade your project if you can and know how to.

 

No. I tried 2020.3.32 and 2020.3.34. I also tried entities 0.50.0-preview.24 and 0.50.1-preview.2. This is only a very recent issue. So perhaps since the latest package (0.50.1-preview.2) was released as I was using 0.50.0-preview.24 the other week without issues but now unable to.

I just installed 0.17.0-preview.42 and it worked fine. I upgraded the package to 0.50.1-preview.2 and after restarting the editor it works fine. However if I install 0.50 as a fresh install I get the error. So it seems the only workaround for me is to first install 0.17 then upgrade to 0.50 when starting a new project.

EDIT: I'll add that I uninstalled all editors, Unity Hub as well as removed all Unity folders/files and reinstalled everything and the issue remains. So I don't think there is anything wrong on my end. Perhaps a recent change made by Unity?

 

Can you clear out your Entities source gen cache and try again? It seems to me that something tripped over and didn't get updated (perhaps a related package)?

Ideally you only grab Entities from the Package Manager and the rest will be fetched with their corresponding versions. Also I'm using VS 2022 for the source generator stuff, but I am not sure how all that works (apparently it is merely slower if it is absent).

 

I just tested it, I installed 2020.3.34 and I have the same issue as inSIght01.

 

Updating in the package manager Newtonsoft Json to version 3.0.2 (Newest one) fixed the issue.

 

Is there any chance that the entities authoring tools team (forgot the exact name) considers reusing the "prefab overrides" approach instead of this new 2/3 inspector modes we will have to keep changing for editing/testing stuff on runtime??

I mean, the presentation above demonstrates how easy it is to forget in which mode u are and change things u didn't want. Specially when coming from years and years of the "play mode changes don't stick" workflow.
Yeah, editing an asset during play mode sticks, but that's because u are not editing an scene you are editing an inherently "offline"/non-play-mode element and that's actually consistent.
So my point is, when changing things in a scene/sub-scene in play mode, changes are added to the classic "overrides" menu "a la prefab". If we really want to keep some change, use the menu to save it. Pretty much how all software has worked from the beginning of times "edit then save".
I think it would not only be more intuitive and less error prone but also more consistent with existing unity and non-unity workflows.

Heck, I'd love to have that for regular gameobjects too, idk why we could never have what is basically a "save" button, specially when u consider that the tech/code required for implementing it is already there.

 

What would be the package version to use? (it doesn't say in the docs and the link to the package in the docks goes to a broken page

 

@adammpolak 0.50.0-preview.4
Entities already references said package, so you shouldn't need to do anything special.

 

Did you edit link by hand?
It displays 0.60, no such version yet.
Just use the link that you quoted.

 

It used one of the

@latest

URLs which mysteriously points to 0.60 instead of the published 0.50.

https://docs.unity3d.com/Packages/com.unity.entities@0.50/manual/ecs_building_projects.html
https://docs.unity3d.com/Packages/com.unity.platforms@latest
Try it yourself!

 

Interesting

 

I've upgraded to 0.50.1-preview.2 and followed relevant upgrade steps, but still find myself with these errors at the end of the process.

I'm using Unity 2021.2.7f1 (which has been working fine with ECS) and was hoping to upgrade to 2021.3 soon.

Is the error being caused by me using an unsupported Unity version (I saw one user mention that 2020 is intended above)? Is support for 2021 LTS expected to arrive "soon"? Or any other ideas re how this error can be resolved?

EDIT: I see here that 2021 LTS support is planned for 0.51, all good! https://forum.unity.com/threads/experimental-entities-0-50-is-available.1253394/#post-7970166

 

I really wanted to start playing with ECS, but I'm not finding any good examples of how to get started with it.

Is there any documentation on where to start, or more recent examples of how I can use it? (0.50)
Or would it be better to wait until the 1.0 release to start using it in production

 

Entities manual is pretty good to start with.
https://docs.unity3d.com/Packages/com.unity.entities@0.50/manual/index.html

There's general concepts on how things work with fresh code examples included.

 

https://github.com/Unity-Technologies/EntityComponentSystemSamples
(loads here - check out hello cube for the initial how-to's). Check out physics examples for cars! And so on.

You may find it helpful to buy Rival off asset store. This was a great way to quickly orient, and I don't see any reason to remove it now!

When initially starting, I kept the package docs for entities etc close by, this forum closer (very helpful crowd in the DOTS forum) and the samples on github. A combination of all those and a couple of weeks was all I needed to really get started.

Ultimately, most of the ECS code you will do is exactly like regular C#. The only real differences are the architecture and pattern (non OOP), how to gather the data you want to change. Once that's done then the code is all the stuff you know.

Most of my work with this is actually regular C# logic! Nothing funny. It's just getting to that point can seem initially confusing. If it is, just ask on DOTS forum.

 

https://dots-tutorial.moetsi.com/ is for v.17 but it is being rewritten

 

There is a reason why many people expect 0.51.
It's a Unity issue, not an ECS issue.
There are too many features available from Unity 2021.2.
In my case, two things in particular are a problem.

GI (Fake or not) and Mesh shader.

In particular, the ability to edit vertex datas and index data using the compute shader available from 2021.2 is essential for character creation.
In the meantime, you can recalculate the stupid normal calculation of skinning with the Compute shader. without heavy cpu load.

When 0.51 comes out, it seems like a lot of people will re-create their own works. 2022 is still like a dream.

 

And Unity needs to understand why people have such a hard time accepting ECS.
If DOTS animation had come out first, people wouldn't have been so confused.
Putting aside the visual part of the game, in the end, the progress of the game consists of motion and physics.
Like it or not, we have no choice but to build an ECS hybrid environment because of animation.

 

1.0 is required because the architecture is so much better. Personally I need 2022.2 for HDRP 14+ with Entities. That would be an extremely next-gen kind of Unity.

 

Out of curiosity, what do you need in HDRP 14 and Entities 1.0 in 2022.2? Looking at the roadmaps for both (HDRP, DOTS), there are not a lot of improvements between 2021 and 2022 in comparision to 2020 to 2021... Post processing shader graph? Water system? Better ui for Entities? These things seem minor compared to the sheer amount of features HDRP 12 has versus version 10, while Entities hasn't changed that much in two years..

Unity lists a lot of stuff in DOTS 1.0 to make it look like a big upgrade, but almost everything is already in 0.17 and 0.50. Our team has more issues in HDRP 10 than DOTS 0.17 and we're using both in production on Gen8 and Gen9 hardware. In fact, we have no major issue with 0.17, but some big ones with HDRP like its gigantic memory consumption.

 

Our world building requires features in HDRP 14. We are using the water, and pretty much everything else including the upgrades to DX12 performance in 2022.2.

This was the reason I had to expect 1.0 if I am using 2022.2.

 

Keep up good work. At least for me dots 1.0 release is quantum leap improvement. Btw I have some feedback and question.
1) I would like to get almost the same performance at editor compares with real build. Since those safety check also bursted I expect it will improve editor performance significantly. Another issue I discovered why the editor is slow is caused by editor only use CPU up to 50% like that and not able use more than that.
2) When can I expect when dots AI related packages like dots behavior tree, dots utility ai and dots navigation will be available? I believe public roadmap haven't mention about this yet.