Official Exciting developments in upcoming Entities 1.0 releases

For me the current limitation is size of chunks. I would like to have mega chunk (eg. 256kb) and tiny chunk (eg. 512 bytes) feature implemented. Currently I been forced to move components to another new entity because of 16kb chunk limitation. I'm curious why this feature is still not a thing yet despite this feature has been mentioned since 2018? Actually will it affect performance a lot of for mobile platform tat has very weak CPU after increase chunk size?

Spoiler

 

I rely on converttoentity game object with my skinned mesh game object entity.
What method do I use if I can't convert.
This character can't be part of a subscene it seems.

 

You should separate the graphics from the ECS parts and maybe use object pooling.

 

Does this mean that we can no longer use this way of managing prefabs? If not, what is the alternative?

 

No it's way better. At least there's no 5 ways this could be indented, doesn't involve an anonymous function, etc.

 

What was a lot more comfortable with the old Entities.ForEach are the GetComponent/SetComponent methods for quickly looking up data from other entities.
Having to create ComponentLookups, updating them, and passing them to the IJobEntity struct is a lot more annoying than the old system (but apart from that the new way to do things is quite nice).

Are there any plans to make ComponentLookups more comfortable to use with IJobEntity?
Maybe generating and passing them automatically, kind of like how the parameters for the Execute method work?

 

At least when using SystemAPI.GetComponentLookup, creation and updating of the lookups are handled for us automatically by code generation.

 

Ohh I had no idea that's possible! In the DOTS Guide examples it's always done the annoying manual way...
That makes it a lot better, thanks for the info.

 

How I see it, if you have entities with just one float component, they should not be entities. Instead. they should just be represented by data. Which is why I think the enforcement of the 128 cap is important. Often times you see people passing data between systems through entities. These, in majority of cases, should not be entities. So, if you do not have enough data on an entity that it would exceed a 128 cap, chance are they either should not be entities, or the 128-chunk cap is really not a huge source of inefficiency. Plus, you can usually achieve greater performance in these cases if you think simpler, like NativeLists and commands.

 

I am curious, how to set name to idiomatic foreach job, in a similar way, as with lambda approach Entities.WithName("myJob")?

Job names are extremely helpful when profiling. Also helps for readibility of the code.

 

As far, as I understand, you don't need them with the idiomatic approach, cause it is a main threaded invocation.
So, you can just create a static method and use it inside if you want named hierarchy in Profiler. But if you find anther way, I would like to know it

 

Another option might be to use ProfilerMarker, although I'm not sure if those are Burst compatible.

 

Given that ISystemBase exists to provide an API for fully burst-compatible systems I kind of wish you would have assumed it would be bursted by default and provided a [WithoutBurst] attribute for the few instances where you don't want to burst it. Pros and Cons:

• It would be way easier to scan your project for which systems that don't run in a performant manner. Just find all references on the attribute
• Cleaner code by default and easier to set up a new proper system. Less things to remember.
• It is a wee bit unconventional to use exclusion instead of inclusion, but this was also how you did it with Entities.ForEach
• It would align more with your performance -by-default mindset
• It's easy to just miss adding this attribute now and not realizing you're not running it bursted. With the opposite default you would get burst errors for your mistakes.

This could also be a project setting in case you want to leave this default assumption to the developers

 

It would not be that difficult to write a custom editor tool that scans your project for structs inheriting

ISystem

that don't contain

[BurstCompile]

. You could even ping the files that they're contained in.

You could make it a setting window, with a refresh button that shows you all of them. You could take it a step further and set it to throw errors on build if you want to enforce it yourself.

I think I could make this in a weekend project and share it to github if you promise to give it a star.

 

Entities.ForEach was really productive, especially for smaller jobs. The new foreach syntax seems ugly and creating a job struct for each task feels like going backwards (so much typing!).

 

Yeah, we're currently changing all of our systems from Entities.ForEach to ISystem with IJobEntity job structs and it's about twice as much code for the same thing and a lot less readable :/

I don't mind writing the IJobEntity structs, but scheduling the jobs is very annoying and feels like you need to do a lot of stuff twice. Why do I have to do SystemApi.GetComponentLookup(isReadOnly = true) when the ComponentLookup in the job struct is already marked as [ReadOnly]? It's kind of error-prone too, when scheduling a job you first have to look into the source code of the job struct (which might be in a different file) to make sure you are matching all of the [ReadOnly] attributes. Feels like you need to know an implementation detail in order to use it.
Why do I have to pass in the ComponentLookups manually at all?

The ComponentLookups should just be part of the jobs Execute() method signature and be passed in automatically, like it's being done for individual components already anyways, or alternatively something like GetComponent/SetComponent as we had in Entities.ForEach should be brought back.

I think that change alone would make all of this significantly more comfortable to use.

 

I do wonder if idiomatic for each will be as much popular and wildly used as Entities. For Each. In current state I highly doubt it.

Also it confuses with normal foreach lookup.

And correct me if I am wrong, but isn't idiomatic for each code-gen anyway, as Entity.ForEach? If so, why there is even a thing, than one approach is better than other, if in the end, it results in equivalent of IJobChunk anyway.

I don't know the back end of one or other, apology for my ignorance, but to me it seems, they could work in a same performant way, as long backend is fixed, rather than writing with new idiomatic approach in mind.

 

Idiomatic foreach is very limited, it is a replacement for only Entities.ForEach.Run. It does not generate an IJob struct, so any code you write with it runs entirely on the main thread.
If you want to do multithreading with ISystem (which should be what you want to do most of the time when using Entities) then you have to write your own IJob struct because there is no replacement for Entities.ForEach.Schedule.

 

IJobEntity is the code generated and schedulable version.

 

Yes, that's what I said. You have to write your own IJob to be able to schedule since there is no foreach-style way of doing it for ISystem (which is less comfortable but fine, there's just a few small annoyances with it - see my post further up).

 

"idiomatic foreach
When Entities.ForEach was introduced, it was the quick and easy alternative to writing full-blown job code. However, the fullness of time revealed some limitations. The biggest problem was that nested loops were impossible, making it cumbersome to model many typical solutions. And after the introduction of IJobEntity, the barrier to jobified code was now no longer as steep, so we went back to the drawing board to express the most common remaining use case for Entities.ForEach - main thread immediate code - using more natural C# syntax. We call the mechanism idiomatic foreach."


Idiomatic foreach its a huge no go for me, nested for each feels soo anti ecs pattern and for me its such nasty anti pattern. nested foreach its basically the antithesis of one system does one thing efficiently huge huge compromise. I can accept it not being in jobs a but never ever please remove it from system base. Like for me my main issue with dots its not performance but huge architectural upgrade of systems, normal unity way its basically so random everything has to be with run order correctly but messy nonlinear determinism is what monobehaviour is. now normal foreach its so clean and straight forward I don't believe even 5% of users will be using ECS it looks like such ugly lambda syntax compared to normal foreach.

I'm a jr developer, normal foreach was very beautiful and supremely elegant even if one doesn't know lamnda it still was humanly knowable at first sight and very straight forward. now it looks like a convoluted mess what makes me mad is that this seems such a disconnected one sided choice suddenly ditching readable code for some seemingly random backend compromise. please don't remove it!!!!!

I came to dots for ecs architectural upgrade away from objectOriented land; this is such backwards compromise! the worst thing about this is that this is exactly the worst kind of compromise an exact anti ecs pattern that affects readablity for the worst kind of reasons.

if someone wants mindless nested forlops that should be done in monobehaviour world most users should not suffer because some want bad objectOriented practices in ecs land.

this idomatic foreach is so bad please don't.

 

I'm scared, after 0.51 and closed community feedback suddenly 1.0 comes out with big compromises

please never remove entity archetypes that's the best neat feature the entire dots stack has.

please let entity archetypes stay!! its been 4-5 years since its was announced please never get rid of entity archetypes best revolutionary feature on ECS systems.

 

You don't have to use nested loops.

I think readability is similar. We'll get used to it.

I don't think you have to worry about that. They are core to the architecture and performance.

 

There is nothing OOP in nested loops. You realise that some algorithms require nested loops?
Archetypes will definitely stay they are at a core of ECS.

 

I'm really disappointed that Entities.ForEach is going away. It was a big reason why I actually started using ECS.

IJobChunk is really tedious to build and read. It requires dramatically more code, and trying to read through a system and understand what is happening is dramatically more painful.

The fact that IJobChunk's code isn't inline means that trying to follow what is happening is essentially a cache miss in the developers brain every time you need to know what happens inside a job.

This choice is going to have a big negative impact on maintainability, as well as collaboration, as it will be harder to go through someone else's code and fully understand what is happening.

The whole thing is code generation anyway, how is it causing performance issues when it should just be generating the annoying IJobEntity for us?

 

Please consider renaming "Bake", "Baked", "Baker" class names to something else. It is a cute naming scheme, yes definitely, but also taken from OOP book and not from DOD one; tells me nothing about the problem it solves.

Just watch one of the community members try to explain what this entity baking is to us and please note the very natural escalation of language so typical to OOP:

Spoiler: video

I don't know about you, but imo he did a good job but still left me understanding less, not more. Do I need flour buffer or a dough pointer next? What :V

seems like a solid advice to follow here.

Code (CSharp):

1. // fairly self-explanatory
2. public abstract class ConvertToEntity<TAuthoringType> : IConvertToEntity where TAuthoringType : Component
3. {
4.     public abstract void ToEntity(TAuthoringType authoring);
5. }
6.  
7. // `SceneAssetPreProcessing` may be long but tells me something `BakeSystem` doesn't
8. [WorldSystemFilter( WorldSystemFilterFlags.SceneAssetPreProcessing )]
9. partial class MyEntityBakeSystem : SystemBase
10. {
11.    protected override void OnUpdate() {}
12. }

 

This shows to me how subjective this is. I did not like the "conversion" naming scheme because it furthered confusion about what exactly is happening, whereas the "baking" paradigm more correctly describes what we are doing: taking authoring data and baking it into a structure that is more performant for the game to run.

This is certainly not a OO concept and dates back quite some time. For the DOOM engine, the team was defining levels in one format, and then that data was "baked" into a BSP once they were done. The "conversion" terminology implies that you can convert from one to the other, whereas a baking process better enforces a uni-directional flow. We have been spoiled with Unity "simplifying" authoring of a game world a lot, but that has come at a cost and teams are now operating at the level where the added bit of complexity to bake data into a more friendly ECS paradigm is becoming useful.

 

Idk. "Convert" is the very first word the documentation uses to explain what "baking" is.

 

To be fair, your example is not the perfect case. If you already know what baking is, then you don't need to read the explanation. Baking is also a specific kind of conversion, so it would make sense to describe it as conversion then go into the details in an article. Using a word to describe something does not mean that word encompasses the whole meaning of that thing.

 

You may be right guys. Idk, I am surprised how well you all receive this name without objections.

 

Treat it like a process of converting "raw" design data into data layout that is finalized for use.
Raw --- Baking -> Baked. Makes sense to me.

Naming is not the worst thing with the "Baking" though. It has other, more substantial flaws.
Alike missing proper GameObject (hybrid) support, and general subscenes instability on multiple platforms.

 

Because it's a term perfectly defined in gamedev for decades? Navigation baking (baking nav mesh, baking flow fields), light baking, SDF baking, LOS baking etc. etc. Having editor time data representation convenient for editing, which then will be AOT built, as different runtime friendly and efficient data representation is pretty common to be named as Baking.

 

I was an 3d artist >decade ago and can confirm what you all say - literally every other tool was "baking" for us back then. But I moved to programming since and my expectations changed, a lot.
It still makes sense to continue labeling designer-facing tools this way, for the reasons you all described.
But code, class names? Different set of requirements to say the least. I will stop here as we will see the consequence of this choice unfold in the future, either way. And there are definitely more important things to write about instead.

 

I'm sorry if the bakery analogy confused you. :/

As a **senior** ECS user the name change definitely through me off in the begining.
But I do feel like the naming is correct considering other game aspect that do the same kind of work.
Like baking light or navmesh.
Which basically prepare data at authoring time for better performance at runtime.

 

Can you explain more on how to handle prefabs now that we cannot do prefab conversion? For example if we are making a LEGO game that has many brick prefab. Do we have to put each brick into it's own subscene to have it "baked" to runtime data that can be instantiated? This doesn't seems like the intended usage of subscene. Is there better way to handle use case like this?

 

You can make a single subscene to put all your prefabs in.
You can use single object to list all your prefabs to bake. Or have your authoring component fetch all the prefabs from the asset database.

 

After taking a look at the 1.0 ECS samples,
I find that the workflow and API is getting more convoluted compare to 0.17

To prepare a prefab for instantiation at runtime:

In 0.17
Create a unity prefab that has a Convert to entity component
For authoring component, just need to implement IConvertGameObject

Code (CSharp):

1. public class SpeedAuthoring : MonoBehaviour, IConvertGameObjectToEntity
2. {
3.     public float speed;
4.     public void Convert(Entity entity, EntityManager dstManager, GameObjectConversionSystem conversionSystem)
5.     {
6.         dstManager.AddComponentData(entity, new Speed { Value = speed});
7.     }
8. }

Use GameObjectConversionUtility to get a entity prefab that you can use to instantiate more entity.

In 1.0
Create a unity prefab
For authoring component, need to implement another Baker class

Code (CSharp):

1. public class SpeedAuthoring : MonoBehaviour
2. {
3.     public float speed;
4.     class Baker : Baker<SpeedAuthoring>
5.     {
6.         public override void Bake(SpeedAuthoring authoring)
7.         {
8.             AddComponent(new SelfDestruct {Value = authoring.speed});
9.         }
10.     }
11. }

Put said prefab in a subscene
Put subscene in your main scene
Somehow get the entity prefab from the subscene, then you can instantiate more entity.



The new bake class is cleaner in the critical code section where you add component to entity, without needing to reference dstManager or the entity or conversionSystem.
However, new API require you to write a separate class, if you nest it like the example, will make it even harder to read IMHO. But I can get the readability back by not nesting the baker class I guess.

Not sure how the new API handle the prefab reference, which was done using GetPrimaryEntity()

Code (CSharp):

1. dstManager.AddComponentData(entity, new Foo{ Value = conversionSystem.GetPrimaryEntity(boo) });

Maybe someone can point me to the right direction?

The biggest problem is that you have to put every prefab in a subscene in order to use it ingame.
I used to be able to just use Resource.Load to get the unity prefab and convert it to entity prefab.
Or use addressable if I need cleaner structure and modding capability.
That's it, no need to worry about forgetting to put prefab in a subscene. The prefab conversion is easily automated. Yes, you need to pay the price of converting prefab at runtime, but you only do it once anyway. Not a big deal.
Now with the new way of bake, I am kind of at a loss on how to make a easy to use pipeline.
Do I write some editor script to automatically put stuff in a subscene? And run the script after I added a new prefab?
Or make a subscene with a prefab manager that will auto collect the prefab I need and save the subscene with a editor script.

I confess that I use UNITY_DISABLE_AUTOMATIC_SYSTEM_BOOTSTRAP and avoided subscene like a plague and want total control over what entity is spawned in my EntityWorld.

 

GetEntity()

(or if you need to get current

PrimaryEntity

without incremental baker dependencies

GetEntityWithoutDependency()

)

 

Transform GameObject Data is Baking
I like Transduce GameObject Data..

Batter into Entity is Baking

Is there a live roadmap for 1.0 release link somewhere or is this it?.. I'd like to pop some popcorn and watch the countdown timer... anxiously awaiting... Updated Editor, Packages...

 

There is no such thing.
It may be tomorrow, or in next few months of 2023. Nothing for certain when. Only guesstimations.

 

Welcome to the "your use case is not supported anymore" club. U are member wxyz. Next club meeting will be in 2 weeks, bring something to drink
</sarcasm>

 

Hi! was working quite a while with 0.17, here are my thoughts:

1. The RefRo/RefRW are amazing! I hated having to use get+set so much. Feels like half of all the errors I ever made was not pairing get with set as soon as there was more than 1 return in a function. And it's so much more code! To re-implement references! I even had to make a ComponentRef : IDisposable, that would do a set in Dispose(). I lost any hope of this being ever addressed, after the initial arguments of "giving references is dangerous", such a great surprise.
2. Any plans for replacing

   Entities.ForEach().Schedule()

   - so generating and scheduling jobs with IFE? (I̶ ̶g̶u̶e̶s̶s̶ ̶u̶n̶l̶i̶k̶e̶l̶y̶,̶ ̶i̶t̶'̶s̶ ̶t̶h̶e̶ ̶r̶e̶l̶e̶a̶s̶e̶ ̶p̶r̶e̶v̶i̶e̶w̶.̶.̶.̶)
   
   Having single syntax sugar both for main thread/jobified queries with as little differences as replacing Run() to Schedule() was the main API achievement for me throughout all ECS.
   
   Step 1 for me when debugging jobs is oftentimes converting them to main thread, to be able to insert breakpoints/logs. So going to-from jobified and/or bursted code is a crucial iteration part. Before I could do that by commenting Schedule and uncommenting Run. Now I have to rewrite the whole Update method, so every component param the job takes? Isn't this a step back to first release, and the core problem of why the jobified code is harder to maintain?
   
3. Nested IFEs are great, but not available in IJobEntity. Not a huge problem anyway. Definitely not justifying the lack of 2.. The problem that nested loops solve is already solved for 90% by RefRo/RefRW. Previously all the pain was not from having to get components separately, but from needing to set them afterwards. Now it looks like the only profit from having a nested IFE is that it decouples components, saving you a few lines of code (possibly 8 but still)?
   

    var (rotateAspect, speedModifierRef) in SystemAPI.Query

   
   Also can't you just write a Get<T1, T2,..>() => ( SystemAPI.Get<T1>, SystemAPI.Get<T2>); Which I would totally do, it's important, just not as much as 2.
   (Edit: ah, only on main thread, where you don't need the lookups I guess that's just what IFE does since it's on main only)
   
   As I see it, IFE is not usable currently, because it adds a non substantial 3. but takes away vital 2. But I should be able to just use IJobEntity instead of Entities.ForEach. Still a lot of boilerplate with ComponentLookups for all the inner loops, but that's about all the problems at first glance. (Ideally of course would like to not have to use any Lookups, and have an ability to see the resulting generated dependencies of your job/query somehow in the editor). Then again, probably those would need to be rewritten again to new job IFE eventually...
   
   Edit:
   Ok looks like 2. is planned?
   "Code in the foreach body always runs on the main thread (until foreach is supported inside IJobEntity)."
   Still this supposedly close to final this might not happen who knows.

 

So this basically means in my case that I will have so many breaking changes that dropping out support for entities is valid option. It also removes support for easy automated testing of entities. Is this Unitys way of saying thatnk you for being a beta tester?

If I'm forced to rewrite all my code I might as well try ecs based game engines. I'm looking at bevyengine that is written in RUST. It has performance by default and no misleading Unity marketing.

 

You should probably do that. There can always be differences in direction that end up making people switch to another platform after a while. For Unity's part, deprecation of runtime conversion APIs have been a long time coming with at least a 1.5 year advance warning now, and removal should not be much of a surprise.

 

Finally got rid of all the errors and started test environment. Extremely exciting changes lol

 

Thanks for the encouragement. Sadly It looks like I cannot use ECS at work projects either.

This deprecation was mentioned in a tutorial that was created long after I started using ecs. How is this a common knowledge?

 

That was an easy example. It's mainly been talk around the forum whenever the subject of runtime conversion came up. Package docs from 0.16 (Sep 2020, 2 years ago) are fair game, as well.

 

The common knowledge is you don't rely on anything that is a WIP because it's unreliable. I remember Unity had always stressed this point saying that you shouldn't seriously invest in ECS at the experimental stage.