DOTS development status and next milestones - May 2024

[boyaregames]

Noice. I always thought that aspects are just for splitting and confusing code. We already has queries and systems why even bother. And I’ve seen how people in TG group was asking questions about “how to XXX but i have aspects” noone was answering cuz noone use aspects or dont know the right way how to do XXX with aspects
Edit: deprecating Entities.ForEach finally!!!

[IAmChiagozie]

The future looks exciting! Although I will have to go back and rewrite my ECS code that uses aspects.

[WAYNGames]

Thanks for the update.

I’ve a few interrogation regarding the unification of entities and game object, physics and scene management.

Will we be able to query any game object with a mono behavior component from a system without having to make a baker for it and add it to an entity as managed component ?

Will the current work allow for mono behavior and systems to perform queries against the physics world(s) with single api call ?

Since all game objects will have an entity, does it mean that scenes will be baked like subscenes making subscenes irrelevant and allowing cross reference between game object and entities in the scene view?

[Neil-Corre]

Fantastic thread. Lots of things worthy of discussion here and I look forward to reading more about other devs’ thoughts about these updates. Like the others, it would also be nice to hear more about the optimizations of pre-existing Unity systems like the LOD update system and the jobs in it, the LocalToWorldSystem, and the Culling jobs. But, I guess those are for the rendering side of things.

More ECS-specific one - would love to hear more about handling open-world games. Will there be a guide or a recommended approach for generating SubScenes at runtime? Things that would improve streaming open worlds. I’ll definitely keep an eye on the Worldbuilding forum.

[axmsw]

Still no roadmap or mention of DOTS for the Web platform? Browsers are ready, and browser deployment is critical for enterprise usage (and many others)… Given Unity is forcing non-gaming users up to Industrial licences at 2.5x the price of Pro, this gap needs addressing.

Question - WebGL and DOTS - Unity Forum

[jGate99]

Hi Team,
Any plans for supporting 2D content (drawing 1000s of sprite renderers)

[sacb0y]

Yes, please bring Burst support to WebGL, it’s needed for a variety of things like cloth sim.

[in0finite]

I also think that Burst & DOTS should be brought to Web platform.

Especially now that WebGPU is coming, and that multi-threaded jobs are enabled (on Web) in Unity 6. Web platform will have so much potential.

With Compute shaders in WebGPU, entities rendering with high performance should definitely be possible.

So, the possibilities are here. Web browsers are ready. It’s up to Unity to decide whether to move on.

[desertGhost]

@topher_r

I think we definitely want a way to specify a kind of ‘meta’ type for queries and iteration. But Aspects ended up trying to do way too much, and the impact on iteration time through a very large amount of source-gen was just not going to work.

In our project, we use 16 aspects and all of them are for the purpose of accessing optional components in IJobEntity. We use them to avoid writing the extra code required for IJobChunk. A simple replacement that would provide all of the functionality that we need in our project would be to add support for an [Optional] attribute for components in IJobEntity.

[mrbinggrae]

There should be more DOTS tutorials. I want to learn DOTS, but there are too few tutorials.

[horeaper]

@mrbinggrae

There should be more DOTS tutorials. I want to learn DOTS, but there are too few tutorials.

Checkout Code Monkey and Turbo Makes Games on youtube, they both made a DOTS tutorial, for beginner and intermediate.

[diakou]

@DreamingImLatios

Anyways, I do believe there exists an API that is simpler, faster, easier to maintain, and provides more flexibility for the use cases that IAspect really solved when used correctly. And I think that solution is to have source gen be able to generate based off of interfaces.

Let’s start with type handles and lookups. The built-in ones all have SystemAPI methods which removes a lot of caching boilerplate. But without SystemAPI, they all have a creation method which takes in SystemState and possibly a second argument. And they all have an Update() method which also takes a SystemState. That can be an interface. It should be possible for a SystemAPI to have an interface-constrained generic that generates code invoking these methods. That way, anyone can write their own type handle and lookup aggregate that works with SystemAPI. This solve the Lookup and TypeHandle parts of IAspect, plus quite a few other pain points I have that are preventing me from doing even more awesome things.

I really don’t understand why we can’t have exactly this, it makes so much sense, it’s probably not that straightforward though and caveats must exist or else I feel like this would have been fantastic for a lot.

[scott-williams]

@Saniell

I would really appreciate if you expanded a bit on this point. Currently I have this potential problem where I schedule jobs that may run across frames (pathfinding), in worst case leading to stall if main thread needs new job to run. Which is why I’m very curious if new controls would allow to limit worker range or perhaps even take advantage of “e/p cores” on some hardware?

For this case, we’re looking at a means of implementing long-running jobs. This will likely involve managing state so these jobs can be paused and resumed in a controlled fashion, but the key will be to ensure it is easy and stable to use. We are also hoping to explore e/p core usage, but how we end up taking advantage of that is still uncertain. i.e. if you have 4 efficiency cores and each has a worker thread, and you have 7 background jobs, they still need to be able to alternate processing in some fashion.

[TheOtherMonarch]

@scott-williams

For this case, we’re looking at a means of implementing long-running jobs. This will likely involve managing state so these jobs can be paused and resumed in a controlled fashion, but the key will be to ensure it is easy and stable to use. We are also hoping to explore e/p core usage, but how we end up taking advantage of that is still uncertain. i.e. if you have 4 efficiency cores and each has a worker thread, and you have 7 background jobs, they still need to be able to alternate processing in some fashion.

I imagine E-cores need some kind of extra control. On my i7-13700K if I am multitasking a lot, I occasionally hit an E-core which basically locks up some apps. Having control over what gets sent to an E-core or just not using E-cores is extremely beneficial for real-time applications.

[Ryiah]

@TheOtherMonarch

I imagine E-cores need some kind of extra control.

E-cores shouldn’t need it. They’re just stripped down cores from previous generations.

[TheOtherMonarch]

@Ryiah

E-cores shouldn’t need it. They’re just stripped down cores from previous generations.

Windows 11 does not have proper thread scheduling for E-cores it often messes up and suggently you drop from 120 FPS to 0 FPS while you wait for the E-core.

[Ryiah]

@TheOtherMonarch

Windows 11 does not have proper thread scheduling for E-cores

Intel suggests otherwise.

https://www.intel.com/content/www/us/en/support/articles/000091284/processors.html

[DreamingImLatios]

@diakou

it’s probably not that straightforward though and caveats must exist

Don’t assume this. These kinds of assumptions are awful for plenty of reasons that I would rather not derail this thread describing.

[TheOtherMonarch]

@Ryiah

Intel suggests otherwise.

https://www.intel.com/content/www/us/en/support/articles/000091284/processors.html

Intel E-cores are Intel’s way of matching AMD’s core counts. I am not even sure if E-cores will remain in the market in a few generations. Intel’s small E-cores have a lot of real-world issues.

[Saniell]

@scott-williams

For this case, we’re looking at a means of implementing long-running jobs. This will likely involve managing state so these jobs can be paused and resumed in a controlled fashion, but the key will be to ensure it is easy and stable to use. We are also hoping to explore e/p core usage, but how we end up taking advantage of that is still uncertain. i.e. if you have 4 efficiency cores and each has a worker thread, and you have 7 background jobs, they still need to be able to alternate processing in some fashion.

Thanks you, this all sounds amazing actually. I would still love to constrain jobs to only certain cores for reasons stated here though, but there is a hack I came up to do that, so not too critical.
Will be waiting for further updates!