Feedback request: IJobEntity

That looks like a great solution. I would use it for 90% of my entity jobs. I think the disadvantages are not really significant and worth the sacrifice.

 

Agreed with the statement above. The disadvantages are very minor and won't affect many users that are still on IJobChunk or IJobForeach.

One side note IJobEntity name is not as specific as IJobForeach, maybe something like IJobBase, IJobUpdate, or even IJobForeach itself just without generic parameters will be helpful to slowly deprecate generic version of it.

 

I love the interface name. That is about as intuitive of an interface name as you could get, as it compares itself well to IJobChunk.
I don't like the interface's method being called OnUpdate instead of Execute. OnUpdate is for systems. Similarly, invoking the job also could use a better name, such as reusing ForEach, or maybe Entities.Job or something.

 

This looks fantastic! I love it

Seems like it's basically an IJobChunk that skips all the boilerplate

Would it be possible to also have a "OnBeginChunk()" function that we can implement aside from OnUpdate()? To give us an opportunity to do some per-chunk logic before we iterate on all entities of the chunk? I feel like we'd almost never need to use IJobChunks again if we had that (for use cases like these, it would be better than working with a threadIndex at every entity iteration, possibly)

 

Nice to see, that Unity heard community Disadvantages really negligible
Couple of small things which will be useful:
- Explicit query usage (same many people want fot Entities.ForEach), when we can explicitly define query, set types and access rules, and use that query as argument for that jobs (and Entities.ForEach) for reducing WithAll (AllInQuery) WithNone (NoneInQuery) WithAny (AnyInQuery) (and that namings, maybe lead them to one denominator? )
- About

ref

, extend it somehow if possible (through codegen and code analysis maybe) for check if we really write to component (like with setter of ComponentDataFromEntity, chunk.GetNativeArray) for bumping chunk version and not just bump it every time just by definition. It will make life easier for change filtering

Can be a bit confusing for newcomers, because we have IJobFor IJobEntity IMO best naming for that type of job.

I also agree with this point. Well Execute (for me) sounds natural and represent behaviour which I expect - execute that block of code.

 

Pretty much what I think most of us wanted. I also don't think OnUpdate is a good name. It has strong historical ties to the gameloop and I think it's best kept reserved for that.

 

Is there a reason it cant reuse the same scheduling as chunk/old ijobforeach, ie Dependency = new Job().ScheduleParallel(myQuery, Dependency)? I personally prefer that over the proposed Entities.WithXXX.OnUpdate(job) etc

 

A small nitpick:

instead of

• Entities.OnUpdate(rotateEntityJob).ScheduleParallel();

I think I'd prefer something like one of these:

• Entities.ScheduleParallel(rotateEntityJob)
• Entities.CreateJob(rotateEntityJob).ScheduleParallel()
• rotateEntityJob.ScheduleParallel()

Especially that last one, if the codegen can deal with it... but that is very much a nitpick

And as @eizenhorn mentioned, an optional entityQuery that we can specify when scheduling would be great

 

I generally prefer Phil's suggestion with `Entities.ScheduleParallel(rotateEntityJob)`, it makes it easier to read and see what it's doing at a glance.

With IJobEntity's OnUpdate(params), the OnUpdate method kind of picks at me since Execute(...) is so much more familiar, since IJob/IJobParallelFor/IJobChunk still use it.

I'm not too much of a fan with Attributes in function params, I find that syntax to be difficult to read, so being able to use entity queries alongside scheduling would be very nice addition.

 

+1 for:

1) (and most important) - an optional entityQuery that we can specify when scheduling would be great
2) Execute instead of OnUpdate
3) This style: Dependency = new Job().ScheduleParallel(myQuery, Dependency)

Good work DOTs team!

 

This is looking pretty good, still needs an OnUpdate function that would give you Entity and iteration Index so same as IJobForEachWithEntity. I use that a lot!

Thanks for listening to our feedback .

 

Yeah IpI much agree with the above.

• The name is is clear. If IJobChunk is a job over a chunk, IJobEntity is a job over an entity. Is consistent.
• Use Execute() consistently with other job types.

Also I know this is unrelated but I don't think deserves a separate post... I find Job.WithCode to be a pretty bad name. Everything is code so it's a meaningless name. I think Job.Execute ( lambda) would be clearer in intent (execute what I'm passing you) and consistent with other job-related terminology.

 

I approve

 

Looks great.

 

If it increase the readability of my code be removing all the WithReadOnly/WithDisable...... boilerplate code involve in Entities.ForEach job, I am in

 

I think it looks great! I more or less create these kinds of structs already using Entities.ForEach, but the fact that we need to write the method declaration inside of the ForEach and invoke a method in the struct manually makes it tedious. This would simplify a lot.

 

Super pumped about this! Thanks for making sure this is implemented. I think it is a good idea to allow the rest of the Lamba stuff on these ForEachEntity structs. I think having the Lambas override attributes on the ForEachEntity would make the most sense, for example if your lambda said to include ComponentA but the ForEachEntity said to exclude ComponentA or something.

 

@Joachim_Ante A compile error would be even better, hadn't though of that.

 

Can we have multiple Execute methods within a job, while having different signatures? For instance, to have a single job for all the transform operation combinations instead of having a job per combination.

Also, would've been awesome to have some sort of extension methods on the interface in order to be able to use GetComponent, GetBuffer etc within such structs. It's really awesome thing to have

 

I am a bit bothered with the Entities. Execute(job).schedule....

Seems like execute and schedule are a bit contradictory to me.

I would prefer a Entites.WithJob(job).schedule
Or
Etities. ScheduledJob(job)

 

Yeah I agree with the comment above. Execute is the right name for the method inside the job, but not for the Entities method

 

I don't like ScheduledJob(job) because it is inconsistent with Entities.Foreach. And Dependency as a second parameter would look ugly.

 

Looks amazing! Would be nice if you paused deprecation of IJobForEach (keeping it deprecated, but not removing it) until this arrived honestly.

 

Best to depreciate it so there is fewer stuff to maintain. Less maintain code == more new features.

 

So hit a restriction today that I'm happy to look at alternatives but don't see anything obvious. Which is Job and Entities I can't pass via a method as they can only be used in a complete builder context. So any context that is complex, long lived, and you need multiple of them running concurrently I don't see a good way to do that.

We have multiple places where we have this paradigm. Navmesh surface/crowd handling for example.

Something like this is what I would like to do.

Code (csharp):

1.  
2. public abstract class AiSubSystem
3.     {
4.      
5.         protected LambdaSingleJobDescription Job;
6.         protected ForEachLambdaJobDescription Entities;
7.  
8.    
9.         public void Init(LambdaSingleJobDescription job, ForEachLambdaJobDescription entities)
10.         {
11.             Job = job;
12.             Entities = entities;
13.         }
14.  
15.         public virtual JobHandle OnUpdate(JobHandle Dependency)
16.         {
17.             return Dependency;
18.         }
19.     }
20.  

 

So the pattern I came up with that works now and hopefully won't break with some future update is putting every Job/Entities into it's own public method that takes the job struct. Then pass the system instance to the code that needs to call those methods.

Breaks encapsulation in multiple ways that I don't like.

Job/Entities after a second glance look like they probably create a new instance on each use so the approach I posted above seems like a non starter.

In any case long term a design that prevents abstracting out jobs seems problematic. That's going to create so much bad code over the long term that it's worth doing right IMO.

 

Personally, I am fine with Entities.ForEach. It's intuitive, and reminds me a bit of SQLAlchemy querying. The main issue isn't that its bad, it's that its hard to remember where to put the semicolons and brackets!

 

Entities.ForEach is fantastic.

 

Entities.ForEach is fantastic for short stuff for sure. Good for prototyping which is harder in entity systems. It won't handle very complex stuff. Glad we have both.

 

@joepl Are there any updates on if/when IJobEntity is being added?
It looks like IJobForEach has already been removed from the most recent Entities packages, but I don't really want to update till I won't have to move all my code over to lambdas.
Really hope it's coming soon as I really do like how it fixes the removal of the previous API.
Thanks!

 

Ah great, sorry I just didn't see a struct page for it in the Entities API doc:
https://docs.unity3d.com/Packages/com.unity.entities@0.10/api/
Though I do see a page for it in the manual if I search through that.
Thanks for clarifying @Joachim_Ante

 

Ah wow that sounds great. Those are some of my biggest gripes with DOTs. Tried out 2020.2 beta and that seems to have a better iteration speed back too. Things are looking good.

 

This seems very interesting and I somehow like it more than Entities.Foreach but don't know why yet

 

I am probably a bit late to this train, but I definatelly would be happy see more IJobs over lambda approaches. Specially because recent IJob type depreciation.

Also, I Agree, that execute is much more suitable, than OnUpdate. Less confusion.

 

100% Agree with this, I do no think we should be having:

Code (CSharp):

1. Entities.Execute(rotateEntityJob).ScheduleParallel();

My preference

Code (CSharp):

1. // Ideal, would need compiler magic so maybe out of scope?
2. rotateEntityJob.ScheduleParallel();
3.  
4. // Would need ability for overloaded methods? Not sure if it is supported in your compile chain
5. Entities.ScheduleParallel(rotateEntityJob);
6.  
7. // If overloads not supported
8. Entities.ScheduleParallelJob(rotateEntityJob);
9. Entities.ScheduleParallelEntityJob(rotateEntityJob);
10.  
11. // Otherwise my vote would go to an overloaded one of the following:
12. Entites.Job(rotateEntityJob).ScheduleParallel();
13. Entites.WithJob(rotateEntityJob).ScheduleParallel();
14.  
15. // If overloading not supported
16. Entites.WithEntityJob(rotateEntityJob).ScheduleParallel();

 

I like it. I will miss GetComponent() and SetComponent() though - they are very handy and much cleaner than setting up GetComponentDataFromEntity(). Is there any way to somehow sneak those back in?

 

Hey! Any news on it?

 

This has been released in 0.50 https://docs.unity3d.com/Packages/com.unity.entities@0.50/manual/ecs_ijobentity.html

Thanks ya'll

 

From what I've read, it seems to replicate the old system it replaced but the syntax is way less messy and it has more flexibility! Thanks for adding this and not just focusing on the Lambda systems .

 

All my IJobEntity have the following warning

There is no defined ordering between fields in multiple declarations of partial struct 'DecisionMakerSystem.DecisionMakerJob'. To specify an ordering, all instance fields must be in the same declaration. [Collapse]csharp(CS0282)

 

This works pretty well...

But I really miss GetComponent(). It would be really nice if there was an easy way to get that back in (or access data from other components without the extra boilerplate of GetComponentDataFromEntity.

Also, there is no easy way to exclude a component (that I know of). I have to maintain a query with 15 parameters that match the 15 parameters of Execute() exactly, and then have an additional ComponentType.Exclude<DeathData>() in the query?

If these two things were resolved, it would get a 10/10!

[EDIT: Good news concerning the second issue - although it's not in the documentation for IJobEntity, a clever person in the Turbo Makes Games discord figured out that this works --> [WithNone(typeof(SomeTag))] public partial struct SomeJob : IJobEntity { void Execute(){} } . ]

 

I'm confused what the true north is. I want this syntax but all the stuff I'm reading online doesn't use this syntax. So I've decided to go cry in a corner. I don't like lambdas and boilerplate, so this looks like an appealing syntax to me.

I just would prefer if Unity updated some examples using this newer, cleaner way to iterate over entities. Would that be possible?

I suppose I'm left wondering what the right way to write code is.

 

If case you haven't seen it already, this page explains its use - https://docs.unity3d.com/Packages/com.unity.entities@0.50/manual/ecs_ijobentity.html

edit: just read up and saw this already posted, so if there are some specific instances from say the entities repo post them and maybe I or someone else can help with a code example