Looking forward to DOTS roadmap information in 2020

When the Pandemic began to spread this year, Unity wisely came out and said there would only be a single, remotely broadcast Unite-style event in 2020 - probably sometime in the fall.

When Unity wrote their ‘2021 focus’ blog post, they mostly excluded DOTS information, saying it would be shared in another, upcoming blog post.

since then, we haven’t heard much about either of these. We got Unite Now (which is a great format). But if I understand it correctly, it won’t involve the kind of forward-looking, feature announcing keynote that Unites usually kick off with - the type of event where Big new DOTS announcements have been made in the past.

And a few weeks ago, I realized I should probably stop excitedly checking the Unity blog every day, to see if this newest one was finally the “DOTS future one” they had said was coming. Now I wonder if maybe that was a miscommunication - maybe they were saying that hypothetically, DOTS info would be shared in a later blog post, if there was any - not that a specific one was planned.

So I’m of course still loving DOTS, and like everyone here I’m eager to hear more about Unity’s future plans. There are several big engine features we are still waiting to see translated for dots (skinned mesh animation, for one). And there are always questions about when ECS will be out of preview.

What should we be looking forward to, along those lines? Will there be any sort of Unite - style keynote event in 2020? Are plans for a ‘future DOTS plans’ blog post actually real? Thanks to anyone with information.

 

I am interested in this too.

 

Still waiting for that blog post as well!

 

More regular updates would be appreciated, yeah

 

Been pressing F5 on the blog page as well

Or if unity wants to limit the DOTS talk for the wide public right now, a simple forum post here would work

 

Knowing Unity ... you may need press Ctrl+F5, to dump cache
But I wouldn't mind to look into blog update too.

 

StickyThread++;

Perhaps something like this: https://forum.unity.com/threads/wha...nity-with-scriptable-render-pipelines.924218/
Except less apologetic and more hype because we all know most of this stuff is still in preview and our community is

 

I am fine with only the multithreading part and if they at some point manage to replace Monobehaviour with something better (or if it just gradually becomes all DOTS).

 

Can we have update in this blog about bursted commandBuffer or bursted job using ECB ? It's a topic since a long time but with little news

 

What are you looking for?
ECB playback is bursted already and has been for a while.

 

Jobs with ecb fully burstable for a long time. ECB Playback also burstable for a long time.
Edit: ah @tertle already mentioned that

 

It has been quite since Entities 0.14

So what do we know will come in 0.15 or the next releases?
I know of support for Enable/Disable components
The problem of scheduling overhead has been acknowledged in the past and I expect improvement in the next versions.
Not really aware of anything else. Does anyone know more?

What do I personally need?
More straight forward instantiating from World A to B. Command Buffer instantiating from World A to B.

Otherwise I'm just expecting the obvious ones. More stable core packages like Animation, etc...

 

I need this soooooo bad. Right now for my soldier entities, each of them occupy an entire archetype chunk due to owning different permutations of "tag" components. Not good when there will be about a hundred soldiers per World. Having all soldiers own all tag components at once, but still activating some of them when needed would pack them together nicely

 

https://forum.unity.com/threads/feedback-request-ijobentity.888121/#post-6315795
This post made me think that they're currently focusing on rewriting their codegen to cut down on assembly reload times. This is a big thing for me and my team. We've got hundreds of jobs and systems. This causes the ILPostProcessing that is triggered on any code change to be super painful. For us it takes more than one minute on our top end computers to reload our main assembly. We've tried to alleviate this by splitting the assembly up into separate smaller systems assemblies, but it's still a large pain so we're very happy about this upcoming change.

Apart from that, it sounded like the IJobEntity API was coming along soon as well.

 

I'm looking for have a job bursted even if I use ECB inside.

Oh boy, oh boy, you're right! I don't know just how I missed this super important point in release note ! even if I work every day with DOTS
Thanks for the hint

 

Through daily forum & discord scraping I'm aware the following is being worked on:-
- Enabled/Disabled (as mentioned)
- Codegen (as mentioned)
- Better prefab support (BlobAsset based I think?)
- DFG, DOTS Timleine & Animation, Hybrid Renderer etc all seem to be in progress but no idea about specifics, planned features or anything other than they exist and occasionally receive an update.
That's it. That's all I've been able to glean. I really struggle to understand the lack of communication. No high level update for 2-3 years now. If anyone knows anything else, please help us out and share.

 

Thank you for that informative breakdown. It’s very much appreciated.

best of luck on the work towards 1.0.

 

With the Joachim reply, this should be stickied until the DOTS update arrives in order to inform people of what is going on while we wait for the update.

 

Is there any plan to implement DOTS Hybrid Render Pipeline for URP and HDRP that beyond Hybrid Renderer that collects the data needed to render ECS entities, and sends this data to Unity's existing rendering architecture? Not just DOTS Hybrid Render Pipeline, I also want other DOTS packages provide capability to extend and remove features easily without changing the source of the package. One great example is the implementation of Entities Transform. You can use WriteGroup to overwrite the custom logic you want easily without changing source code of the package. On top of that I think last time u mention about something called Feature that will supercede current ComponentSystemGroup. I believe it will make removing feature easily. I'm not the fan of modify source code of package. I want extend and remove feature on top existing package and able to update new version of package easily without a lot of breaking change caused by modified source code.

 

What if there was a Hybrid URP and a DOTS URP and they would be collectively known as hurp and durp.

[edit] This comment is blowing up, but I have nothing more to state except that the job system with burst is really nice for my intents and purposes so far. :'3c

 

Yes, please.
Half of me wants that because there's a chance we might get 2D Rendering (and associated features, such as shadows and a new-brand-spanking data-oriented tilemap) in DOTS with it!
...
The other half of me just wants it for those names.

 

Have you looked at the Entities 2D for the 2D rendering? https://docs.unity3d.com/Packages/com.unity.2d.entities@0.22/manual/index.html

 

Why yes, good sir, I have!
But last time I checked, I'm pretty sure the 2D Entities package was Project Tiny only.
And — while significant development has been made — Project Tiny is lacking some needed features for me as of this moment to make a larger-than-prototype project.

But I would be happy if 2D Entities became usable / compatible with standard DOTS! And if it already is — somebody slap me.

 

My personal opinion, as someone who really loves working with MonoBehaviours and GameObjects is: Don't even try to accomplish this (at least not in terms of "making DOTS approachable to everyone" ... if you meant "improve debugging" instead, it's a clear "yes, absolutely" ;-) ).

What I love about Unity's "old approach" is that it very much aligns with the way I think, and how I approach many of the problems I'm encountering while developing a game.

I also love DOTS, and I love it exactly because it's a very different approach. But I don't think there is a way to make DOTS work for people in the MonoBehaviour-mindset without breaking it. DOTS requires a different approach, and that's exactly what makes it so powerful as a new tool (IMHO).

Maybe by keeping the "old approach", pretty much as it is? The funny thing is that for certain things, I actually find writing DOTS-code much easier than writing MonoBehaviours, even though I have many years of experience with oo-concepts and how those apply to MonoBehaviours / GameObjects - and just a few weeks or months with DOTS.

I don't mind if you replace one system after the other with the DOTS-based approach under the hood, and maybe make a few additions to the MonoBehaviour-based approach that give people access to specific DOTS-features even if they are in the "MonoBehaviour-thinking" (I guess that would be "Jobs"). But I don't see any benefit in mixing the concepts because they are so different. Instead, draw a clear line, and define clearly where the two interface with each other.

I believe there's a tricky thing here: When you're used to the way things are done in DOTS, it feels simple, and genius, and powerful. And for many problems, it's actually the ideal "language". But for some problems, the "quick'n'dirty MonoBehaviour"-approach is actually a much better language. And performance doesn't always matter much.

I believe for prototyping, usually, MonoBehaviours will forever be the much more elegant approach. For prototyping a few specific things, DOTS may be ideal but I'd say those are very special cases. And "making DOTS as easy to prototype with as MonoBehaviours" would not be of any benefit for those cases.

In my opinion, the key is really to just drop "as easy as writing MonoBehaviours". Why not just say "How do we make it so the authoring and debugging experience of DOTS works well for people that work with DOTS"?

It's a different way of thinking, and while I definitely would love being able to click an object coming from DOTS in the scene view to select its entity in the editor to be able to inspect it, and maybe even change its components, for me, that's currently the only thing missing in terms of debugging / authoring.

I actually think you have already done an excellent job with what you have, in that regard. The missing piece in that puzzle, IMHO, is just a unified approach to visual scripting that can generate shaders, VFX (basically just a different kind of shaders), DOTS-code and MonoBehaviour-code ... and, um, Playables.

I'd wager that for some technical artists, DOTS may actually already be much more approachable than MonoBehaviours.

I agree about that one. I'm currently using Hybrid Renderer (V1) and I may be running into some severe roadblocks there but I can't move to V2, either. Also, being able to use Shuriken particle systems "completely swallowed into DOTS" would be nice, and Material Property Blocks.

In our project, I see some very clear boundaries of systems that really should be done in DOTS (and some of them now already are), some that maybe should be in DOTS but are too much work to move over (it looks like those are comparatively few), and some where I don't see how moving those over to DOTS would make any sense at all.

 

Because if it's not as easy to use as the solution they abandoned in favour for the DOTS approach, then they will have abandoned the current Unity for nothing.

If Unity loses its (surface level) ease of use it really has nothing going for it.

 

I think there definitely are areas of dots where the ease of use could improve without necessarily changing the actual paradigm of dots:

• Find an optional way to work with cases where we need "instant changes" in transform hierarchies. Maybe give us a "TransformWorld" struct (similar in concept to "PhysicsWorld") that we can pass to our job, with a bunch of utils to instantly make it update a child or a hierarchy, instantly give us the world rotation of a child, etc....
• Bursted main thread code (we're getting this soon!). Many people will want to cry when they see stuff like "WithDeallocateOnJobCompletion", "WithDisableNativeParallelForRestriction", error messages about dependencies and read/write problems, etc.... Having bursted main thread code would allow beginner users to write easy code in dots that still has better performance than monobehaviour, but doesn't have any of the complexities of jobs & dependencies. And much of the heavy engine features like physics, rendering, etc will still be multithreaded either way
• Job codegen: keep trying out new easier ways to write jobs, like the IJobEntity which was discussed a few months back
• Conversion/Editor workflows: I don't know what to say about the conversion workflow other than I think the hybrid/GameObjects nature of it introduces a lot of confusion, doubt, and the general feeling that it's a bit of a hack that could break in many cases that weren't planned for it (compared to a dedicated editor for conversion where only valid dots-compatible things are possible). I understand that a lot of people want to rely on hybrid for their current projects, but I can't help but feel like it complexifies the whole DOTS workflow. Object picking in scene and editing variables at runtime are also important
• (Not sure if good idea) provide some out-of-the-box codegen tools/utils that would make it easy and quick for us to write our own codegen for our specific scenarios? I'm sure a few utilities could be extracted out of NetCode package. I was writing an enum-based state machine the other day and was thinking that codegen would really save me a lot of time here. Same thing with "ability systems" or systems that would otherwise rely on polymorphism in OOP. Perhaps there would be ways of making user-created codegen a common tool to use in dots? I guess visual scripting counts as codegen...

 

Awesome! It is great that things are being worked on to find a path toward where it should be at the end!
Our team is doing pre-production using DOTS and we are really happy with most of the things. The hybrid renderer V2 still has a far road ahead but the core is fantastic. If we can disable components later on then core doesn't need much more ease other than debugability and conversion goodies.

I don't know myabe prefabs which are DOTS native and are stored as blobs are good. I'm sure you guys will find much better ways.

 

Why not have both? DOTS and MonoBehaviour are very different approaches to coding a game, and they already work together fairly well (no doubt that's an area that can use improvement).

That was basically what I was trying to get across: MonoBehaviours are an almost perfect tool to build a lot of things. DOTS is an almost perfect tool to build other things. Of course, you could use MonoBehaviours to build stuff that would be better built with DOTS (actually, you might not get the performance you need in many of those cases), and you could use DOTS to build stuff that would be better built with MonoBehaviours (but you might never finish your project). But why not just use the right tool instead of trying to bend a tool to be useful for all scenarios?

And I'm pretty sure Unity can and will move a lot of stuff over to DOTS internally. They already use C++ for most of the engine even though there are a lot of issues with P/Invoke. But it still was a good way of doing it (IMHO).

 

I agree with that. While having to do certain things in command buffers is one of the things I do find tricky, it may or may not always be possible to simplify this.

Very much agree with that. I think the conversion workflow has be used with plenty of special care. And I believe Unity should not assume that we want things to be converted. For instance, with Physics, I have removed the automatic conversion for now, and make careful decisions on what parts of the game live in the DOTS Physics world, and which live in the MonoBehaviour world.

I believe the approach there in terms of how DOTS evolves should be based on use cases: What use cases are there? When is the use case obviously best solved via MonoBehaviours? When is the use case obviously best solved via DOTS? What are use cases where the two systems need to interact? How can that interaction be done in a way that is easy to use and doesn't easily cause unwanted and unexpected side-effects?

And again, from what I have seen so far, a lot has already been done "just right".

 

This is a good back and forth, but I think it may have forgotten the source. In his first point, Joachim didn't say they wanted to make coding is DOTS more "Monobehavior-like". He said:

"1. How do we make it so that writing game code in DOTS is as easy as writing MonoBehaviours."

So that kind of solves the philosophical problem. DOTS doesn't have to become less DOTS-like. Instead, Unity can work on reducing the friction involved in actually writing DOTS code - especially for rapid prototyping.

FWIW, this is also something that happened with MonoBehaviors early in Unity's life as an engine. It used to be clunkier to write MonoBehavior-style code. Unity focused a lot on polishing that workflow.

 

To me a as easy to use path for DOTS easily exists which is comparable directly to MB but still a lot faster. This is assuming tooling works.
none-bursted main thread foreach code for debugging, and bursted version of it for release. or have a way to automatically map burst instruction to C# source code like what MS does with blazer.

I know you don't have resources of Microsoft and this doesn't have to be the first step and also know that it is harder in native code, a lot harder to do it compared to bytecode in the browser

 

I would be fine with having both, but Unity isn't willing, not really. A lot of systems and parts of "old Unity" have been put on hold / deprecated / in maintenance mode. A lot of requests for improvements for fixes and improvements are met with "well, this is going to get fixed when DOTS arrives, no point in messing with the old stuff" types of answers.

 

Honestly, I'd agree with Unity on this. Making a game engine is hard enough, so it's best to avoid making 2 game engines at the same time. Better to focus entirely on the one solution that will be better in the long term, even if that means present-day projects won't get access to the nice stuff

 

In that case, refer to my previous post, where Unity absolutely needs to make DOTS as "easy to use" as the current monobehaviour stuff, or else the engine is going to have absolutely nothing going for it.

But also, I wonder if you'll be saying the same, when you find a nice DOTS workflow in, say, 5 years from now, and Unity suddenly abandons it completely because the new DASHES stack will solve all problems that DOTS has, but you'll have to wait another 5 years for that to be usable.

 

Oh, yes it will happen. when Quantum Computer is ready for mass use...
Quantum coding with entangled state will make source code even harder to understand. But guess what, it can solve NP problem in polynomial time.
But I guess 5 years is far from enough.
Haha

 

Ralph Hauwert... Hmmm yes.



I now fully believe you are equally committed to DOTS as you are to OpenXR.

 

At least it won't be as bad as the Entities Rendering Pipeline. (Luckily only a tiny amount of people are unfortunate enough to know this reference.)

 

@Joachim_Ante I would like to see Chunks.ForEach (so we can work with shared components and chunk components) and schedule parallel jobs on chunks? and wouldn't frequent use of enable/disable components cause fragmentation issues?

 

Reading this made me very happy.

 

Too many cooks spoils the broth. - Just joking

 

Where/how DOTS and MB/GO fit in is something that just has to evolve over time. Unity can't answer where will the dividing lines be exactly in the future because it's unknowable. The only reasonable/sane approach is you keep working on your existing product mostly as normal. Future bets you just have to wait until they mature see how/where they get used. Once you get there and have some significant level of adoption then you might start to merge things or move to the next stage whatever that looks like.

 

That's not a realistic scenario. It assumes there are more good approaches to problems then there are for one. And that a new high level paradigm would come along so much better that they would just wholesale switch to it. And there is absolutely no basis for thinking that.

What's happening is Unity is just playing catch up to where modern studios are in terms of the approaches used. Entity component system design is fairly standard in the industry. We would have to see some new high level pattern come out of nowhere really for Unity to just switch to something else.

Lower level it's all mostly slight variations on what most of the industry has been doing for a while. Which isn't to take anything away from what they are doing. Burst and concurrency they not only caught up but pushed ahead of where most everyone else in the industry is.

Look at most any part of DOTS and you find well known approaches, or variants on the well known. There is just very little room for wholesale changes in these areas outside of the industry as a whole adopting some new approach.

 

I like how your argument is not that Unity wouldn’t screw its users again like that but rather that the random example I pulled out of my ass in unrealistic.

 

I’m just wading back in here, and not taking a side in any debate that might be going on. But I wanted to comment on this point:

ECS patterns may be present in the industry - and people are every large studio may know about them. But since companies and teams tend to move slowly, in low risk directions, I think it’s wrong to say they’re fairly standard patterns. Most teams aren’t using them, and it will probably be a while until teams that want to rewrite their code based that way actually have a chance to.

I mean, technically ECS patterns have been around since the 80s. And GadPowered Games made pioneering use of them in the Dungeon Seige. But there’s a reason why it was so newsworthy that Blizzard used the pattern in Overwatch. It’s still something pretty rare for medium-large sized studios to actually use.

I believe the reason is usually risk and investment. and what Unity is doing isn’t so much catching up, as it is removing some of that risk by doing the investment that those studios are hesitant to do (and then selling it as a product).

 

Joachim should be rewarded for the brave work he is doing. People are already making Dots memes, One meme I found was "Unity should replace CEO of Unity to Dots based CEO" . I dought Tim Sweney will ever take such brave steps.

 

Not trying to take sides either but AFAIK aside from Insomniac, now blizzard and a few other names , the industry is not on ECS and between those who are in data oriented design in general or in ECS, all are not in it for perf and actually I think unity is hoping to capture a bigger pie in the AAA space by making a great open world ready, deterministic ready, data oriented engine with fast prototype tooling.

Yes many companies using things like SIMD and almost all manage their own memory specially in lower level systems. Also many use the GPU for none rendering tasks (see the talk from Horizon's development about object placement on terrain) and unity is making these things possible in the engine as well but actually if Unity pulls off its DOD stuff which I'm 99.9999% no 100% sure it will do, it will be hell of a democratization.

 

I mentioned before, but few top large studios already recruiting DOTS guys, for their flag ship products. So there is definitely movement and large active interest in this tech.