Official DOTS Development Status And Next Milestones - March 2022

Does that work with the subscene workflow? I have the opposite situation. I have GameObject vehicle physics, and want to use subscenes to load only "tiles" around the player, but want to have colliders on those loaded subscenes. My understanding is that the subscenes are pure entities, and that's why they are so fast. And does the GO attached to your vehicle automatically track with the entity updates, or is that something that has to be coded?

 

Just in case, let me say that gameobject physics and entity physics (dots physics package) are independent engines and will not interact with each other.


Folks, was anyone able to attend to unity roadmap session at GDC? Anything interesting to share?

 

It's usually safe to assume that I don't know what I'm talking about, but in this case I do understand the separation between GO and entity physics. What I would like to do, which may turn out to be a terrible idea, is divide my scene into hex cells, and save each of those into a sub scene. I only load the player cell + the ring around the player (maybe by direction so only 3) and the rest are represented by billboards/impostors. For my vehicles that are outside the player's view or at LOD1+, I use an entity system that moves them along my road lanes (which have already been converted to entities -- I have this system up and running already) by direct manipulation of the position and rotation, no physics. When they move into the players view, I want to transition to full-fidelity vehicle physics, but my engine is based on GameObjects, so when I load the subscenes, I need the colliders that the GameObjects physics can work with.

If my vehicle physics was using DOTS, I'd be all set. I don't know if it's reasonable to expect a full vehicle physics to be performant enough to handle 100s of vehicles even under DOTS, so it may not be a reasonable expectation that the authors of those systems would eventually port them. But I'd love to be proven wrong.

Apologies for hijacking the thread. I had put my entities work aside to make some progress on vegetation over the last few months (hobby project, limited time), so I was very excited to see this announcement about 0.50 and the forthcoming 0.51 with 2021 support.

 

Correct.

I have to say in defense of the other guy that if people have been talking about 0.5.1 all the time and someone writes suddenly 0.51 I'm going to guess its a typo.

Next case where confusion is possible is if you saw 0.5.1 long time a go and come back after several months of doing other stuff related to some other project you might not realize they are different. Because was there a dot or not.

Of course you might say that in that case you should go see a doctor about memory issues, but I'll then have to remind you that not all of us have a photographic memory.

Its unreasonable to demand people to remember things like machines. A lot of the people seem to forget everything that happened in the meeting the very next day.

 

It's really concerning what Unity has done so far by halting DOTS Visual Scripting & DOTS Audio(DSPGraph) & DOTS Animation until after 1.0, then they will think what they are gonna do with them right after 1.0 is released. Considering that they are still in experimental stage, I'm starting to have panic attacks and imagining the worst scenario possible; Death (deprecation).

This is a chart that shows how Unity deals with experimental packages:



Source: Unity Docs​

Please, Unity, share more information with us.. at least, tell us: Are they confirmed? Or are they gonna end up being E?


- I can't imagine the halo & hype that were created when DOTS Audio was first introduced at Unite Copenhagen 2019 being assassinated:

 

I like how that graph doesn’t have a post release improvements state, it’s direct from release -> deprecated.

In a way it’s nice they admit it.

So let’s hope DOTS 1.0 gets everything 100% right with the first release.

 

I'm pretty sure the "D" path is the incremental improvements to released packages. There is nothing unusual or alarming on that flowchart. All software follows some form of that flow.

Even the poor choice of extremely low-contrast colors for the arrows is, sadly, not unusual in the software industry.

 

And I quote.

Trivial changes sounds about right (and doc updates, omg!). Every time Unity releases a 1.0 feature, the typical reaction is "Well, this is promising, but still needs a lot of work", and then all it gets is "trivial changes", for years.

1.0 for Unity is not a solid base to build and improve upon, it's a "we're done with this now, cya!".

In any case, regardless of that flowchart (because we could keep arguing about it and derail the thread to completely off topic), I do maintain that I hope that DOTS 1.0 is as close to complete as possible, because their track record with post 1.0 features is horrible.

 

So the more major changes follow paths C or B. It's nothing different than any other group that manages published software does, and is following the Semantic Versioning principles.

Whether or not they are guaranteeing to do any upgrades is another matter. The diagram is simply documenting the process that will be followed if they do.

 

There's a thing I've brought up in other places that might not have reached you.

Unity spent a whole lot of efforts a few years back developing a new animation system - Playables. It's low-level, and you had (from the outside looking in) every opportunity to make it great and fast. Since it's mostly a thin wrapper to c++ code, you could do all the data oriented stuff you ever wanted to.

The end result is that it is completely unable to match the speed of the over a decade old Animation component.


So my question is, are you as a company still able to write a fast animation stack? Do you know what went wrong with Playables, and what are you doing different this time so you're actually delivering something performant?

 

Thanks for the update!
It is great that finally @Joachim_Ante shared a simple but complete update in regard to animation. It is not required that everytime he personally does it but imagine how much easier it was if the product managers just said the same thing in the conference clearly and for example said that we are doing this for Animaiton, terrain and audio but we don't want to hold DOTS core/entities back so we are releasing them separately and considering the fact that separate teams work on them, the others should have experimental versions after 1.0 available for feedback when they are ready. Hope this goes forward better and more like this rather than the other way around.

 

That's great news regarding DOTS Animation. Thanks for that. But, please tell us: Are DOTS Visual Scripting & DOTS Audio also being developed in parallel? Or are they abandoned? You need to clarify that for us, sir.

 

0.11 support 2021 and 0.50 support 2020? Are you kidding?

 

Is there cause for frustration here? Sure.
Could things have gone better up to now? Maybe. Maybe not.
Do we need any more of this kind of outburst fresh after an update? All signs point to no.
Don't crack whips.

 

0.17 was for 2020.3 too. Unity already explained and had a thread about why. They already explained why 0.50 is for 2020.3. Read the forum.

 

Just for anyone interested, if you don't need mesh deformation aka bone weights / armatures, you can already animate things in ECS:

You have to write everything on your own and every moving piece has to be a seperate mesh .. like for a robot for example, or like in my video, seperated body parts.

If anyone is interrested, we (you who is reading and me) could launch an open source project, providing a temporary solution for animations, based on my procedural walking code and some conversion tools (writing keyframes, maybe even automatically splitting meshes based on bone weights).

PS: Performance is great. In the video above, I am GPU bound, CPU pretty much sleeps doing a few thousand transform matrix calculations per frame (0.02ms for the animation job). If the hybrid renderer has improved, I could support way, way more units.

 

Impressive ! do you plan to make a tutorial or maybe share the scripts?

 

@mfuad anything about DOTS terrain??? Is it also being developed in parallel with DOTS 1.0??

 

In exchange for some contribution on the second part of the animation system (upper body animations, which are baked into Vector3s and Quaternions), I would open source the whole thing, free for everyone, including the sample and my custom inverse kinematics + procedural motion code.

If it would be smaller, I'd just copy paste the scripts here but there are quite a few classes, I think about 1500 lines of code or more. Not feasable for copy&paste, but feasable for an open source git repo. But then it should be finished - and I have quite limited time right now, so some help would be cool.

 

@Joachim_Ante @mfuad I would like to ask will all EntityCommandBufferSystem related systems migrate to unmanaged system in next Entities package release? I really need ecb systems to be unmanaged system and ecb fully burstable.

Spoiler

C:\Project\Library\PackageCache\com.unity.entities@8e13422a93\Unity.Entities\EntityCommandBuffer.cs(1366,13): Burst error BC1040: Loading from a non-readonly static field `Unity.Entities.EntityCommandBuffer.ms_CommandBufferIDAllocator` is not supported
at Unity.Entities.EntityCommandBuffer..ctor(Unity.Entities.EntityCommandBuffer* this, Unity.Collections.Allocator label, int disposeSentinelStackDepth, Unity.Entities.PlaybackPolicy playbackPolicy) (at C:\Project\Library\PackageCache\com.unity.entities@8e13422a93\Unity.Entities\EntityCommandBuffer.cs:1366)
at Unity.Entities.EntityCommandBuffer..ctor(Unity.Entities.EntityCommandBuffer* this, Unity.Collections.Allocator label) (at C:\Project\Library\PackageCache\com.unity.entities@8e13422a93\Unity.Entities\EntityCommandBuffer.cs:1330)
......

 

I'm interested!

I currently have the ability to apply an entity hierarchy to SkinnedMeshes. It is a completely custom skinning codepath up to but not including the shader graph shaders (so really good compatibility).

Actually, I have the skinning code path running so fast, I'm actually CPU bottlenecked on the transforms. I'm currently working on the mechanisms for converting and playing animation clips, and I haven't really had time to explore much in procedural motion, IK, physics bones, or high-level state machines and graphs.

This is something I'm also interested in, but more to mimic the pattern. I store NativeContainers in managed collections, and it would be awesome to do transactions with these from Burst systems, even if that means temporarily leaving Burst into managed via some interop mechanism. The tricky part I imagine is passing the NativeContainer across that boundary with safety features intact.

 

Sent you a PM. ^^

 

I'm curious, does this involve a new leak detection system that moves away from DisposeSentinel and allows nested native containers?

 

I see. I have 2 more questions.

1) Looks like System window at Entities 0.50 release not able to show unmanaged system. Will it fixed at next Entities release?

2) It seems like when the unmanaged system is wrapped by class/struct I will get this warning. Will it affect anything? I do that just to make Systems windows to display class name then follow by system.

Spoiler

Compilation was requested for method `xxx+xxx, xxx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null::__codegen__OnCreate(System.IntPtr, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089|System.IntPtr, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)` but it is not a known Burst entry point. This may be because the [BurstCompile] method is defined in a generic class, and the generic class is not instantiated with concrete types anywhere in your code.

 

I see. Btw is that possible to convert to ISystem first but without put any BurstCompile tag? Do I need to change struct to class type for ISystem if it's still need to be managed instead of umanaged?

 

With the removal of DisposeSentinel and direct leak detection against allocations, will there still be any options to do "leak detection" outside of the allocators? For instance I have this use case here where I use a DisposeSentinel to ensure that the user has unpinned a GC array: https://github.com/Per-Morten/UnityUtilities/blob/main/ViewAsNativeArrayExtensions.cs#L54

Edit:
I guess it's more correct to ask, will the leak detection become totally opaque to us, or will there still be API's to interact with it outside of having to create our own allocators?

 

I guess you could (ab)use the internal leak detection by actually doing small persistent allocations that would warn you if you forget to dispose

 

I remember in the early versions there was a mention of the intention to make 2 versions of the chunk. But as far as I understand in 1.0 this will not happen. Why was the decision made to drop the 2 different chunk size scenario? Very often the archetype is quite heavy and in the course of the game it swells with an increase in the number of entities. A character with pathfinding and AI can weigh quite a lot, and when there are 1000+ such entities, quite a lot of chunks are required. Therefore, it seemed to me an interesting idea to give the opportunity to create 128kb or 512kb chunks. Also, on the contrary, I had many entities whose archetype weighed very little, and an 8kb chunk would be enough for them.

 

When will Entities 0.51 be released?

 

No one give you exact date.
Best to expect minimum at the end of next quarter. But even then, it is not guaranteed and it may be even later.

 

Best is to have the expectation that it will be released when we see a post that says "Entities 0.51 is now released". No sooner, no later.

 

Does anyone know if something was said about 0.51 supporting 2022.1 too?

 

1.0 is for 2022
0.51 is to support 2021.

 

is it possible to make development possible on Unity 2021.x using Entities 0.50 while waiting for the next release ?
I'm pretty sure our project won't ship until version 0.51, but we need a lot of features from Unity 2021 and we've encountered some technical walls in Unity 2020.
Thanks

 

No.

As far as I can tell, there's a change in some job scheduling stuff in 2022 that was back ported to 2020.3 for the entities package. This has not been back ported to 2021.3 yet so the actual engine is missing features. You can actually make entities (not hybrid renderer due to massive rendering changes) work on 2022 if you want to be silly (https://github.com/Extrys/UNITY-DOTS-0.50-2022-beta-compatibility) but not 2021.

 

Same boat, we are waiting
It was supposed to be a minor update (cf. here), seems to be more of a development hell.

If I were you, I wouldn't tempt the devil with custom compatibility package. If you encounter a problem in your upgrade, you run the risk of being stuck in a particular case and will inevitably be told that there is no support for the 2021~2022.

 

No one ever said it is minor update.
Internal changes between 2020 and 2021 are significant on many levels.
That alone was an indication, it will take many months after 0.50, before 0.51 will be released for 2021.
I suggest to sit tide and wait.

I myself waiting for the update, as I am using 2021. But I am not in a position that would stop project from continuing the development.
Rather treating an update as nice bonus, with great stuff to come, once it arrives.

 

It was said to be a minor update:

(https://forum.unity.com/threads/dots-development-status-and-next-milestones-march-2022.1253355/)

 

Well it is fair point, if considering catching words. However 0.51 is just a number. And looks like minor update, if interpreting words literally. These are often take months between updates. Some packages in past had more love, to get updates more often than others.

However Q2 end is not even yet. And I wouldn't be surprised, if things get pushed back. If we get 0.51 by end of the Q2 that would be amazing. But not end of the world if didn't.

 

I never tried to upgrade our project to Unity 2021 as it is officially recognized as not working.
2020 is blocking for us, because we need many features like URP decals, Visual Scripting… in our development phase.
obviously we're using alternatives while we wait for officially supported stuff, but coming back later to replace them is a pure waste of time.

Are you using these packages Hybrid Renderer, Physics.
If so, have you encountered any issues while using them in Unity 2021?

Thanks

 

I'm using Havok and so Hybrid Renderer V2.

I stay on Unity version 2021.3.0f1 because, as far as I remember, going with 2021.3.1f1 failed due to a package update with com.unity.collections relying on a more recent and unavailable version of Mathematics or something.

As far as you stick with these packages versions and avoid using specific DOTS ui tools (for example the entities tool will crash at runtime), it seems to work great in 2021.3.0f1 LTS :

• Entities 0.17.0-preview.42
• jobs 0.8.0-preview.23
• mathematics 1.2.5
• collections 0.15.0-preview.21
• Unity Physics 0.6.0-preview.3
• Havok 0.6.0-preview.3
• Hybrid Renderer 0.11.0-preview.44
• platforms 0.10.0-preview.10
• burst 1.6.5

Don't know about 2022 but since it's not LTS it is less interesting in my case.
But I repeat, there is no DOTS support for these versions of Unity and you are mostly on your own.

 

Nope.
We dropped Hybrid Renderer and Physics in our latest project.
We hover needed features for HDRP from 2021, when we were deciding on moving to it. At that time 0.50 wasn't announced and wasn't clear, which direction DOTS will go, while understood that overhaul is in works.

Since we don't use them anymore.
We have installed these packages. But is no errors.
Nothing unexpected so far. Other than some DOTS weird UI behaviour in the inspector, when entity is selected.

But with 2021, loosing opportunity to use 0.50. At least to the moment of 0.51, once is released once upon time.

 

@elliotc-unity Awesome. Some questions and feedback. From what I know job system is also bursted at 22.[2|3]. Can I expect huge performance boost at 22.[2|3] Editor? Currently I get too slow performance at my dots netcode project at editor that can't even reach 30+ fps at desktop pc but the real build is still fast that able to reach solid 60 fps at desktop pc.

Regarding Case 1415919, I would like you to take a look at it to fix the version number and option to run issues. One more thing is I believe since all the platforms packages will consolidate into just single platform package. I would like u to migrate most of the platform specific components into platform package. For me currently I need Android and iOS platform specific components. The current Platforms 0.50.0-preview.4 is just missing too many platform specific components. It's not acceptable that I really need these platform specific components to setup different kind of build configs for various builds.

 

nice