Official DOTS Development Status And Next Milestones - December 2021

you can just put multiple singletons on one entity and it only takes up 1 chunk

 

Finally, some communication!!

You can't just go "Oopsie woopsie uwu, we broke Entities completely! The code monkeys at our headquarters are working VEWY HAWD to fix this" and then not communicate anything for almost a year.

That's the problem with announcing stuff; from then on, you're kinda liable to maintain transparency until it's released.
Even a heads up of "we're still working on this" and answering some questions would've helped a ton.

The last official answer in the previous thread about 2021 support was April 20th 2021.

 

Not really.
But here what is going most lilely to happen, based on responses in this thread.
DOTS team will spend maybe few days with us, to answer our questions. Then will go into quite mode until next update, which will be 0.5 for 2020.
Then there will be burst of open communication like this one, followed by silece mode until 0.5 for 2021. And so on for lts 2022.

Obviously I would love to have continuous communication as just to be, before 2021.
But if Unity choose to be this way, so be it. At least they are clear, they will communicate in such form. And it was also announced in April this year. However, it was misinterpreted and misunderstood by many readers.

So I advise anyone here, not to be surprisde for lack of communicqtion in Jan / Feb / March, until next update.

 

Some of DOTS components and benefits should be used in the background to benefit everyone including people using the gameobject system.
Rendering/editor performance and so on

I see URP/HDRP already ship with burst and so on, using it to improve decal or light culling performance which is great

I don't see myself moving to DOTS unless I have a project that would benefit a lot from the move.

 

Am I the only one who feels DOTS is no longer relevant? I mean...DOTS is coder's dream, full memory management, clean approach...but Unity is a game engine...

While DOTS took almost 4~5 years to realize this new direction, the game engine industry has moved on...and I just don't see the justification for it anymore...even if it were in its full potential right now (which it is not by like a few years)

DOTS will never be able to match Nanite + Lumen...
Unity should have focused on rendering...imagine where we would be if the team spent 4~5 years to R&D rendering...

Also, the more I use Unity and DOTS, I feel like DOTS should have been a runtime back end.
So, for example, in editor all things are handled as per usual and when standalone builds are compiled and run, DOTS kick in and optimize all data structure. So, same easy usability of current monobehavior and the power of DOTS at runtime.

Then they should have worked on letting people custom use DOTS.

We can do everything that DOTS offers now without issues...maybe a bit slower than DOTS but:

• VFX -> runs on GPU so no need for DOTS
• Many objects -> GPU instancing
• Occlusion -> Same old stuff
• Animation -> not on DOTS
• Audio -> not on DOTS but hopefully someday

On the other hand, Unity's priority should have been:

• High quality Terrain and details -> requires a third party asset
• Terrain streaming -> requires a third party asset
• GI -> SSGI is very bad and DX12 drops performance by 12ms alone.

but even with third party assets, we are no way near competition. So, stuck at terrain that looks like something we can see in 2010 games.

And then personally I feel the following should have been worked on:

• Garbage Collection -> Why is this so hard to be fixed so that we don't have lag spikes...why no follow up after the introduction of Incremental Collector...why can't we meet industry standard and every Unity game out there is suffering from GC spikes...
• Async Instantiation -> Or any method to instantiate something over multiple frames...
• GPU based culling -> I mean...this can't be that hard...
• Bug Free Navmesh/Agents -> I refuse to say no more...

So, like I said, DOTS while welcomed, kind of feels outdated already. Unfortunately, the next 10 years will all be about open world (Metaverse and other trends) and guess who is really bad at open world....Unity. And DOTS is not going to help much (1) not ready or released and (2) DOTS and open world do not have much in common to benefit...maybe a minor performance boost. I can imagine the subscenes in Hybrid helping with large world stream...but this approach is already old and not practical. Why can't we have the world chopped up in runtime...instead of creating chopped up worlds...

If you think otherwise, look at the competition...clearly they have realized the current trend...

Also, if you want to argue that not all devs are working on open world, then think again. If something is made for open world, then chances are it will benefit yours in many ways because currently open world games require very high standards, many objects, far distances, large areas. The three forces the workflow to be optimized for pretty much all other genres. Maybe not if you are making an auto chess game...but you get the point. Open World Games require high rendering capabilities...

So to close it off, I wish the best for the DOTS team...but I also can't say that DOTS will be our savior...the game industry has changed completely...and seems like the wrong thing to chase...

 

Agreed. This is the reason why our team decided to stop using ECS. We were having to engineer hybrid solutions left and right, and this made the code very complex. It also forced us to sacrifice many of the performance benefits that ECS was supposed to provide in the first place.

While I'm happy Unity has finally said something about ECS, I'm disappointed that so many core Unity systems will not see ECS implementations anytime soon. The announcement has validated our decision not to depend on ECS.

 

yes even ten times slower or even more.

It is impossible to magically convert OOP to DoD. Have you ever used DOTS? Take some mildly complex project an convert it to DOTS. Then imagine someone has to create code that is able to do that automaty for any OOP architecture.

 

Open world (you think of something like Skyrim?) is mostly done by huge teams with huge budgets in their custom engines. Small indies or solo devs (who primarily use Unity) simply have not the capacity for such ambitious projects anyway.

So you suggest UT to run AFTER the competitors and chase a "moving" target where others clearly have an advantage already? When those engines you mention are superior for those type of games everyone is free to choose them instead.
Instead UT is focussing on something every game could benefit from (in theory). Not just a small subset of types/genres.

The benefit for developers I imagine is the paradigm shift towards data oriented design. OOP projects tend to get very complex soon. I expect DOD to simplify this (if there were not the "overhead" of forced hybrid). I have not made the transition to pure DOD thinking yet. But I also have not dived deeply into ECS because the silence and "treatment" of community has scared/pissed/discouraged me. And from the looks I will have to wait another 2 years before even considering it. ECS beeing an experimental tech does not mean UT can disappear for year and leave early adopters in limbo, IMHO.

 

In a stress test, yes. In an actual dev environment? No, mostly not. Unless you are making a massive sim based game...which is a scarce case anyway. I mean openworld vs massive number sim game? Open world is gonna win any day in terms of number of projects. Heck Open world games are starting to take on massive num sims, so....yep. If this doesn't convince you think about it: No one else has DOTS...and yet things are done and have been. Once there is DOTS, then the need for DOTS like enhance may rise, but so far, no. The market itself doesn't exist. On the other hand, can we use Unity to make something like GTA? Arma? Farcry? Sure we can...but its going to be a nightmare. You know it. I know it. And pretty much everyone knows it.

Also, as for how difficult it is to convert OOP to DoD....they had 4 years. 4 freaking years. I just refuse to believe that they couldn't do it in that time. The current DOTS mess is more of a direction thing rather than how hard it was. Also, if they took that route, nobody would be arguing why DOTS is crap or not. We will be discussing something more constructive.

 

I don't know what year you are living in but open world is not exclusive to AAA studios. Every level of studios and indie devs are working on it. It has been like that for about 3~4 years. The simply don't have the capacity is not true. Scale? yes but capacity? No. You are talking 2010-ish stuff here.

As for your second point. If UT is falling behind industry standard (clearly) and the leader is far ahead...does that mean that UT should not try to close the gap? And try something that will add value in other ways? Remember that rendering to a game engine is huge...not just a feature....like huge...don't know why UT trying to catch up is so not rational to you but to me seems pretty rational. Is it not a given at this point? How do you even confuse this...?

Also, to add on. Another 2 years for DOTS to be ready? I bet you by then even Godot will have something like Lumen and Nanite...and you think DOTS will just trump all this? Remember Lumen and Nanite is not alien tech. It is just a polished, production ready feature of very well known techniques. I mean, someone came up with Nanite like asset above. One guy. One guy! So this is not alien tech. I don't know mate...unless I am underestimating DOTS by a large margin, arrival of DOTS won't even make headlines in the industry. By then, the industry will be chasing something far superior and advanced.

I just sometimes get the feeling that Unity users are afraid of new advanced tech and keep saying "We don't need AAA or BBB, us indies have no way to utilize it. If you don't like it go use Unreal! Leave us Unity users alone!" kind of vibe.

This is not healthy.

And this is why Unity Tech adds splines in Dec 2021. And people still say yay!

 

When I read this

"Not all of Unity will have complete Entities compatibility, and based on many successful experiences of our early adopters, we are fully embracing the hybrid nature of our 1.0 release. This means the scope of 1.0 includes strong conversion workflows allowing you to choose ECS for its value in solving specific challenges while leveraging GameObjects for other aspects of your production. Our goal is to enable teams that are able to ship a GameObjects-based production to leverage ECS for reaching goals beyond what Unity used to be able to support."

A though immediately jumps to mind. The past year I completed 2 ECS projects. One was using tiny and the other one regular ECS. For me personally the tiny project went a lot smoother. Initially I though it was the great examples, but thinking back it was the challenge of mixing GameObject/Mono with Entities/System that really killed me ( not taking anything away from the tiny examples). Even-though I was limited with featured in tiny the development work was much much easier, simpler and enjoyable simply because it all sat in ECS. Im i the only one that feels this way?

 

As far as I know (please correct me someone if I'm wrong) - it is still possible to do everything in DOTS/ECS but you would simply roll the missing solutions yourself. There is a lot of surface for hybrid solutions but I think it's possible to have close to a pure project.

If say, a UI has 20 moving parts per frame, it's just still not something that DOTS can accelerate all that much. Sure you could save 0.05ms but why? You will usually only have one UI.

DOTS probably does - for sanity's sake - need a tool for job approach. Or a lot of horses of for courses.

 

I'm literally using a data oriented framework in my current project, built upon an ECS framework I've been using in Rust and this is uh... pretty absurd. Data oriented design is a massive improvement over concepts like OOP for game development. In fact, I'm not even making a big game but it's already been saving me massive amounts of hassle because of how much more smooth data management and debugging have become. This whole "DOTS/ECS are only good for massive projects" is the most absurd misunderstanding I have seen come up repeatedly.

What are you talking about? You can't just magically make these things even remotely interoperable like that, otherwise this would have been a foundational element of the compiler process.

The reason I and many others are particularly bullish on data oriented design in general is because it has become a proven solution over a fairly long period of time.

This is like saying "blenders are out of date, they'll never be able to put a nail in wood like a hammer."

 

Seeing how they already did that with multiplayer, realtime GI, and SRP, I'm not so sure.
It seems to be their forte.

They bought weta-digital, but if that actually benefits us is a different matter. They also acquired speed-tree, and others, but we got nothing so far.

 

I think you are taking what I said and completely missing the point.

1) This whole "DOTS/ECS are only good for massive projects" -> not what I said. I said massive number sim games.
Why do I say this. Well lets go over a few number of games in terms of entities vs objects

• A small relatively basic game with minimal objects (mobile game)-> no real need for DOTS as it is simple and fast enough.
• A medium sized FPS/TPS with mostly static environment (eg. shooters like Call of Duty or CSGO) -> no real need for DOTS as the scene will most likely be a small sized scene with baked lighting and static objects mostly.
• A larger sized game (eg. Tarkov, Dark Souls) with larger environment that has medium dynamic objects with culling -> still no real need for DOTS as it will be mostly GPU based.
• Open world game with larger environment, many dynamic objects (eg Rust, Open world survival games) -> May or may not benefit but right now its gonna be a nightmare.
• A game with many entities moving around (RTS for example or EBS) will benefit from DOTS 100%
• Then there are low-end mobile devs who need to prioritize performance no matter what. DOTS 100%

Now look and decide. You really think Unity, world's largest game engine company should be chasing DOTS as their priority? Really? And sink 4~5 years to get to where they are now and spend another 4~5 years and beyond? This is up to your opinion, but the notion that DOTS will benefit every level of devs and projects is just absurd. And even if it is true, do you really believe it will be that great? I mean, are you sure you are not imagining than what it actually can do? CPUs in game engines have lost their throne to GPUs long ago. Do you really think it is all worth this much effort?

2) You can't just magically make these things even remotely interoperable like that, otherwise this would have been a foundational element of the compiler process. -> Hybrid ECS does this exactly except the user has to make it work and as said by many it is an ugly process. The idea of Entity or Database orientated approach is praised by many game engine devs, as it provides some significant performance gains in some cases. But there is also the reality and the practical side of it. And that is that is has many limitations and not easy to implement. And often the performance gained is not significant as one expects as modern games tend to offload heavy lifting to GPU anyway. So, is suggesting the DOTS to work as an backend to auto-ECS-fy for built standalone an absurd thing? I think not. In fact, it probably is one of the few ways to actually make DOTS worth it. And if you still think this is an absurd approach, DOTS's multithreading is exactly this. It takes hard-to work with, prone to error threading and takes it all in house, and the users have to use a simple interface to access it. Why not the same for the whole DOTS system?

3) This is like saying "blenders are out of date, they'll never be able to put a nail in wood like a hammer." -> I think you are missing the whole point again. If you thought I was trying to say DOTS is unity's Nanite & Lumen then you should have really read through more carefully. But let me elaborate as the opportunity presents itself. UE chose to move into a game engine that can render open worlds like no other and we are saying that this works with the obvious current trend.

On the other hand Unity spends 4~5 years on DOTS system that is still few years away from production. Even when this arrives,

• DOTS cannot improve high poly handling like Nanite as it was never meant to handle that.
• DOTS cannot handle dynamic world stream (it uses subscene chunk LOD for hybrid renderer)
• DOTS cannot improve realtime GI (Unless you think the current implementation of GI is good enough and this is another talk)

The only side of DOTS that I can think of that will benefit is the improved memory and cpu utilization eventually leaving slightly more time for the CPU to do other things...the only issue is, is that enough? To match the impact of Nanite and Lumen? No of course not.

So then the question comes naturally...why is Unity spending time on DOTS and not on rendering? I mean even Unity must have thought about this - they went silent and people started wondering if it is abandoned...has that crossed your mind?

 

If you think "Eye-candy for kids" is nothing to pay attention to, then you my friend are in the wrong business. This is literally one of the most down-to-earth description of modern video games. We are all toy makers in many ways.

Also, Weta wasn't acquired to improve rendering or VFX. There is more story to this end, but most likely it is the cinema side of Unity (Mostly to counter Unreal's film advances). Unity really wants the movie industry to use Unity but fat chance. Also, why are you using Macbooks to work on 3d stuff...this is your mistake no one else's

But back to why Unity should not be focusing on DOTS and really work on an engine that can produce open world games,

Enjoy.

 

Yeah, we shouldn't be surprised, but it's not acceptable when there's A LOT of confusion like last time.
I've seen very many people, the kinds that don't spend a lot of free time on this forum being basically convinced that Unity was throwing in the towel with ECS.

 

Again, you're completely wrong. I'm not making anything close to a massive sim game. I have seen the benefits.

Wrong. DOTS and Unity's other underlying tech dramatically reduces power draw on mobile devices. I have tested this myself.

Wrong. DOTS has nothing to do with lighting or static object. It is about data flow and management.

Wrong again, DOTS is not rendering tech. DOTS is efficient data flow and management.

Correct in the sense that DOTS is a natural fit here, just as it is in all the prior things.

I'm convinced you don't actually know what DOTS is at this point.

DOTS performance benefits on mobile are applicable across the board.

Yes, the user has to make it work. This is the opposite of what you said.

You seriously just keep showing that you don't know how DOTS is applicable across the board in gamedev. ECS and DOTS are systems that are designed to improve performance but also have major benefits from an architectural standpoint over Monobehaviours, a system that was already showing massive weak points ages ago. Hell, Unity's own documentation even covers this.

https://unity.com/how-to/how-architect-code-your-project-scales

 

Sounds like DOTS is great for simulations and or many small things processing but what we really need in game development is DOTS for graphics on the GPU?

 

Guys read the topic title. It's your only chance to talk to Unity properly. Unity asked you to ask them questions, which they will get to. A moderator said he'd remove posts that were offtopic. Please focus on useful things (directed at people doing small talk and banter among themselves).

When a thread gets noisy and people start bickering with each other, the staff does move away from it as it is time consuming and pointless. Please bear that in mind.

 

Which IS using DOTS.
Pathfinder WOTR - massive RPG with static world - Use DOTS.
Overwatch - ECS based FPS. (not unity, but in the context of usability for FPS and networking)
Many companies already use DOTS and take its benefits.

This is not the idea of DOD. Before making such statements I recommend you, please, at least learn the topic basics.

Looking at what you're talking about - you completely missed\misunderstood the whole point of ECS (and Unity Entities implementation specifically in DOTS). Performance is a side effect of what ECS itself provides (Burst is more about performance in DOTS stack than Entities and Jobs together). The whole point is architecture, code structure, maintainability, modularity, scalability, debuggability, and many other things which is often a nightmare in any more or less serious OOD project.

Yes. Especially auto-ECS-fy part.

Because game development is not only rendering. You are so focused on rendering that you completely ignore all other aspects of game development. And in fact, Unity IS working on rendering the whole work behind hybrid renderer (and of course SRP) is exactly to make a better rendering core instead of the current one.

This is exactly what you should say to yourself when speaking about aspects of DOTS, and DOD paradigm specifically, without understanding what it all about No harsh context, just wrap your words.

EDIT: Ah @hippocoder sorry, posted before page refresh Feel free to remove that post At this point I'm out of off-topic discussion here

 

Thanks all - please keep discussion focused on what you need to know from Unity staff.

 

Thinking that DoD/DOTS is good only for massive sims is a big misunderstanding. For example, it opens the possibility to process a lot of data for even smaller games. For example, fast calculating a lot of influence fields to feed AI algorithms of a handful of agents. And even for a simple game, ECS is a great way of making game logic, but first, you need to get rid of "bad" habits from OOP, that usually do not translate well to DoD.

 

Will DOTS be easier to work into GO games for performance e.g. simpler to integrate and/or convert GO component based code to DOTS systems?

 

Here's me hoping to get this thread back on track.

Thank you for this!

One of the things I have been doing has been hooking into the system update procedures to more tightly integrate ECS with custom functionality. Here's some examples:
1) I subclass World so that systems can access particular containers and special systems without caring about what systems actually exist in the World.
2) I override ComponentSystemGroup.OnUpdate() to skip updating of specific systems (which skips the expensive query checks and dependency setup/teardown costs).
3) I have a SystemBase base class which captures Dependency and propagates it to external mechanisms from within OnUpdate().

Are these types of things still going to be possible in future Entities, or are they going to be closed off so we have to use the "blessed" workflows?

Is ISystem going to provide enough public API to do these sorts of things?

 

Yes, bump what slims said!

All fantastic news and thanks for the communication Unity!

Can you give an idea of any known API changes? For someone starting a new project and deciding whether to be an early adapter for ECS, I just want to know where to expect deprecations.

 

You're definitely doing the right thing -- more communication is better for the community and helps us think ahead, even if all the answers aren't available yet. I salute you for being transparent, and for answering all these questions. Well done and happy holidays.

 

Hi
Thanks for the news

Want to know. Do Write Groups survive for DOTS 1.0

Write groups currently hard to understand but they very powerful tool

If they survive, can you please make write groups enabled by default in queries so all systems from 3rd party packages will be overridable by default unless 3rd party authors decide to make them sealed

If you create any new solution for query override. The same. Make them enabled by default please, it is important for 3rd party packages

 

Finally, some DOTS news.
I'd like to see the job system and the burst compiler integrated into the Unity Editor without any sort of package installation, similar to ui elements. Both these packages have been verified for several years, and asset developers shouldn't have to guess whether or not their customers have these core essential engine features installed. In fact, I'd like to see many Unity features go in this direction in the future, including the entire graphics pipeline (even in Unity 2021, you still have to enable the graphics packages in the package manager, why not make this enabled by default?). It would be nice if developers could still modify the source code for these packages, even if they are completely integrated into the core engine and enabled by default (or even impossible to disable).

It's nice to see Entities receive some needed attention, but stabilize and integrate the most important features first. The job system and the burst compiler really should be integrated into the Unity Editor at this point.

 

As an example use case, our team works on multiplier RTS, where we need process all many thousands of projectiles at any time. Something we wouldn't be able to pull of without current DOTS features (burst, jobs and ECS). So we look forward for any DOTS upgrades, but we are not hindered, by lack of features. And if need to, we may lock on current version of Unity, and we will be fine too.

But we only add effects like particles and trails to projectiles, when in view of the camera and close enough. Also, we use pooling and emit mechanics for such. So projectiles them selfs are entities. But effects are standard Unity particles. We may consider build own DOTS PS in the future, if we need to, as mostly we use few sprites per each effect. But until then, we mix both ECS and GOs when sensible.

Also, we use HDRP.

So only custom thing in our case is a spawning, tracking and pooling of PS.

 

Will all this fancy stuff be compatible with raytracing?

 

Edited for clarity:

HDRP works with DOTS so raytracing will work. You should direct your question to HDRP / graphics forum.

 

@LaurentGibert
Thanks for the news. I personally like the hybrid concept, hope it's easy to implement with OOP.

While other parts of Unity integrate with DOTS, will Unity Visual Script also be part of the supported features in the release of DOTS 1.0?

 

Can I confirm that they will not bloat the build sizes of our games/apps?

 

Animation:
Will there be a working UI for visually creating graphs in the 0.5 release(I know compositor was merged but in the current release the graph ui seems quite broken/missing just about every node that was available in compositor when it was standalone)?
Statemachines & Animation Events?

Physics:
Any update to including the lower fidelity havok 6dof/3dof rigidbodies that were mentioned a while ago for cases like particle effects?
Also will there be a parallel collision/trigger events job?

Animation & physics: Workflows for ragdolls? These were teased a while ago too..

 

Will Entities 0.5 and 1.0 have a new build system that would allow smaller build sizes a la Project Tiny?

 

Do we will have access to search of entities by index? I mean a filtering tool in entities debugger.
Atm. I can filter by entity name, providing I set it with an Entity Manager.

 

You can use fixed point arithmetic to achieve cross platform determinism, can see a discussion here about how it is implemented.

Have you guys written anything about the main challenges the Burst team has hit with cross platform determinism (rounding + vectorization stuff on ARM vs x86 I guess)? I read about it being a feature awhile back but haven't seen any announcements about progress.


Other topic: is there any information on the future of Unity DOTS Physics? I wrote a small post about it here, and made an experimental game object wrapper for it. Seems like a really nice tool, would be sad to see it fade away. Cross platform float determinism + stateless physics would be pretty powerful.

 

We would never use fixed points too many serious issues, relating to resolution and overflow. We could use software-based floats but it is a big lift to get right and have high performance. Fixed points also have similar issues. Cross platform determinism with soft floats is totally possible.

For example, this.
https://github.com/Kimbatt/soft-float-starter-pack

or C++ used by Spring RTS on Linux, Windows and MacOS
https://nicolas.brodu.net/en/programmation/streflop/index.html
https://github.com/spring/spring/tree/develop/rts/lib/streflop

I should have added that we currently do use a base 10 fixed point as a serialization format. Just not as a calculation format.

Cross platform determinism is not something we require. Currently Burst has some level of enhanced determinism. However it is not guaranteed to be reproducible from one computer to another. I think most people would be happy with just having determinism on Windows especially if it is significantly more performant.

 

@s_schoener If I understand correctly you are saying that there will be some game object based component won't be supported properly and no plan to support it properly. Then how official is going to solve this hard problem? I can imagine it's going to be very troublesome for my dots mobile project even when it reach dots 1.0 release. So, I believe I will need to use and maintain both dots addressable and game object based addressable to solve this hard problem.

 

@uDamian I think at very least change the UI Toolkit runtime API to struct based to make it compatible with struct based system just like how low level navigation API has been done so I can no longer using class based system anymore for UI update. The main reason behind it is class based system is just too slow for mobile platform. From what I understand class based system not matter how it optimize it will only from extremely slow to very slow. Maybe not even able to reach the same speed similar to at Monobehavior Update loop I dunno.

 

@uDamian Awesome. 2 questions want to ask.
1) Is that now I can see the name of entity just like game object name instead of just entity with index and version number?

2) Not sure if ECS Inspector is the tool that I want. Currently I'm looking for a tool that visualize all the data of entities with components in graph based way. With this tool I can clearly see the data relationship between entity and how they relate to each other. The tool also have a timeline bar that I can drag to do time travel that I can see how data is transformed i.e. which entity has been created and destroyed, which component has been added and removed.
I think it needs to have filter function, use different color for each line and node or other way to make the graph not become too messy. What I imagine the visualization can be like something as the following:

Spoiler

Spoiler

Spoiler

Spoiler

Spoiler

 

Is EntityManager.AddComponentObject (which is public) here to stay? Is it being made internal? Is it being deprecated?

I am currently using it in a couple of places including to support using Playables Animated GameObjects for animated Entities.

 

Awesome! It sounds like I have nothing to worry about regarding SystemBase, so I won't go into any more details there.

Making my managers and brokers with ISystem is something I am very concerned with. Currently, scheduling 50 mostly parallel jobs serially (no JobHandle.CombineDependencies) cause the system to take a quarter of a millisecond to execute. I have similar longer-running systems which generate more complex job scheduling patterns. I would eventually like to have these systems run with Burst.

Currently with ISystemBase, instantiating and adding unmanaged systems to a ComponentSystemGroup is internal. The process for manually updating an ISystemBase is also internal. Will these be exposed?

And my second question, with SystemBase I have managed brokers for native containers which can be accessed indirectly via the World object (if it makes it easier to understand, pretend one of these brokers is a SystemBase with an empty OnUpdate). I want the same broker functionality to be accessible from a Bursted ISystem. Is it possible to do that without having to create and populate a pointer to the broker in every ISystem implementation?

 

I posted earlier but I wanted to bump my question: for those of us deep in development with Entities 0.17.0, what level of effort can we expect to upgrade to .5/1.0?