New enabled/disabled state filtering

This relates to the post from Joachim here on new feature coming but I thought it better to start a new thread on it than pollute that one.
Also I realise I'm getting ahead of myself as the functionality isn't out yet but the choice of filtering vs tagging is an area I struggle with so just want to throw out some queries on this new mechanism.

Is this just going to use the existing archetype/chunk architecture with an added bitstream per component or is it going to be achieved through some new architectural mechanism? I.e. the more components added whether disabled or not is still going to widen the archetype and reduce the entity count per chunk?
Will bitstream be stored in chunk also?
Although I'm sure it's negligible, I presume all structural changes will now require copying enabled status as well?

I've used such filter technique myself where the filter is a seperate stream from its component, but it made me wonder whether only touching every nth enabled component in a stream could have a negative effect on sequential cache prefetching?

At the moment, such filtering approach means running all relevant systems even if no component in query is enabled.
Is there going to be any kind of mechanism at the chunk/archetype level maybe to determine if some/none of a component type is enabled so we can filter out entire chunks/systems?
Will we have ability to specify that we're not using enabled/disabled so we can remove any behind the scenes filtering checks?

Will we get flexible options for filtering on these as opposed to treating disabled components as non existant?
E.g. you might want to enable CompB based on timer value in CompA and then set some properties of CompB at same time.
I guess this is the same as just being able to disable builtin filtering and access components regardless of enabled state.

This is my biggest difficulty with tagging vs filtering. It's really an optimisation choice, yet it's very hard to determine ahead of time which of these options is going to be more performant. Except in the simple case, entities contain many components so optimising for one scenario can be detrimental to others.
Problem is it's not easy to refactor between these two choices. Tagging has far reaching consequences like ecbs and synch points and filtering requires conditionals all over the place with excess Systems running and increased mem and fragmentation. Perhaps refactoring will be a bit easier with built in enabled state though.

Looking ahead, I wonder that this new filtering approach won't eventually become the defacto standard instead of add/remove (tagging) components as

1. it's going to be built in to every component anyway
2. it's way easier than having to deal with ecbs and structural changes especially as it's hidden
3. you perhaps won't want to mix the two techniques as tagging components of a wider archetype is going to be even more costly. I personally found mixing both techniques a bit messy/complicated as well.
   
4. the tagging/filtering choice is going to be confusing to newcomers (I include myself) as they achieve the same goal, so I imagine most will start with filtering as it's easier.
5. there's many benefits to a built in filtering approach from an ease-of-use perspective with the only downside being unknowable (ahead of time) performance issues.

I'm not advocating for one or the other as they're both going to exist anyway and experienced devs will choose the right tool. I'm just curious what the future ecs recommendations are going to be given Joachim's comments about their game code teams preference for filtering.
Alas for me, indecisiveness is an illness. Next topic, entities vs buffers.

 

Join to all these questions and want to ask additionaly: is it actually will be built in to EVERY component or it is will be choose of component's author?

 

I'm just going off what Joachim said but as it's a new feature and not released yet, I'm sure it's open to changing as they see best.

 

Additional Question:

1. Will DynamicBuffers be included?

And a comment: The only obvious downside I see is that disabled component data would still exist in the entity’s chunk, reducing its chunk utilization.

When I first approached ECS, I thought archetype changes should be avoided at all costs. So I took a similar approach to this (disable/enable). My entities started with every component they could ever need, disabled. As a result, my archetypes never changed, but my chunk utilization was very low: 8 for most of my entities.

Later, I switched to an archetype switching approach, and that chunk utilization jumped to 23.

 

Sounds like a great addition. Do you have any plans for being able to react to enable/disable? Not instantaneous ofc.
Do we perhaps have to track the old status ourselves and then check every frame with versioning filter?

 

Thank you. The more I think about this, the more I'm excited for the potential. There's a chance this could eliminate all but one of our custom sync points (the remaining one is only occasionally used for spawning).

A few questions:

1. Regarding mega and tiny chunks: Is it right to assume this feature is only in consideration right now, and shouldn't be expected to drop at the same time as enable/disable states?

2. Please help me understand the benefit of mega-chunks: I thought the 16kb limit for chunk size was based on the L1 cache length of most CPUs. By using a mega-chunk, would we be making a concession that most of its data would live on the L2 cache, but with the argument that that's still really dang fast, and not a real-world bottleneck for most projects (like you mentioned above)?

3. ...I'm still nervous about chunk utilization - specifically, the need to load an entity up with a lot of components, up front. In our project, we use Components and DynamicBuffers to represent ai behaviors. Some behaviors use DBs, because agents can be performing multiple instances of them at once (for example, counting down multiple, different timers). This approach has worked very well - it's both super performant, and intuitive for our designers to understand. I've been blown away by how fast dots makes this pattern run.

However, for a single agent, the possibility space of all the behaviors they might perform could be vast. Having all of these behavior components on an agent from the start might be infeasible - I could imagine a single agent not even being able to fit inside of a chunk.

We always try to bound the number of behaviors an NPC can perform, in our ai design. But if every new behavior type means a possible perf hit, that is...an uncomfortable design constraint to have. It would mean the engineering and game design are in conflict, working against each other.

For these reasons, a while back we switched to using an on-demand approach, in which agents only receive their behavior data when they are actually performing them. The behavior possibility space isn't a concern now, but it does require making structural changes. <-- and just to be clear, this approach has been performing very fast. I'm just trying to figure out if-or-how we could take advantage of this new enable/disable approach.

- - -

Sincerely, thanks for your time. I'm excited for this feature.

 

Thank you! That answers a lot.

 

Hi @Joachim_Ante , any update to this functionality?

 

Here’s hoping this feature lands in the not-to-distant future.

 

Is this still planned?

 

Here's hoping that any feature lands in the not-too-distant future .

 

Even just some more communication/info about DOTS plans would be much appreciated.

 

Preaching to the choir, DOTS devs are hiding in trees and we're all dogs running through the forest barking randomly. Sometimes one will come down and yell in our general direction and then disappear into the shadows.

 

If you have a question about DOTS right now then feel free to make a thread, but there is not much chance of any speculation about future things.

 

Nice, this should vastly increase Tag-like component performance, since you can add all tags that 'might' be added to a component, and then just enable/disable them when relevant.

 

Setting aside any hopes of plans or a roadmap being shared, I'd love to hear more about the active state of development regarding DOTS. Does anyone know if that info is available anywhere? I wouldn't want to make a new thread if I'm just not looking in the right place.

 

We all would, trust me.

 

The sticky posts would be my first go-to.

 

Specifically you might look at profiles of anyone posting in the DOTS forum with a Unity Technologies tag for recent comments, AFAIK they haven't released an updated roadmap in a while. Until then, sometimes their posts hint at what they're working towards.

Most helpful recently:

https://forum.unity.com/members/martingram.1307855/
https://forum.unity.com/members/joachim_ante.3/

 

That's a good suggestion, thanks. Though, I do generally check in on the forum, discord server, and youtube multiple times a day, so I was kind of hoping that I just hadn't seen another good place/site to follow.

 

100% can't wait for this feature. It will eliminate the need for so many workarounds and hack-togethers.

 

Will this be in the next release of Entities?

 

Hi there ! I was wondering if there is any news about this in 0.5 ?

 

AFAIK it will be part of 1.0.

 

I’m very interested to know how this will be implemented.

I assume that this change will make zero-sized components no longer zero-sized. Seems like they would at least have to add 1 bit of size to each entity.

that’s not a big deal if you have a small number of tag components. But if you have 300, then chunk efficiency will suddenly take a big hit.

 

Any chance the Enable/Disable feature will be in Entities v0.51? I too was hoping it would come in v0.50 and v1 still sounds like a long way off...

 

Not unity but their Gdc slide had it as a feature of 1.0

 

Too late Played with it a bit last week in an empty project - not because I expect it to work but just because I wanted to get a feel for the work flow to ensure I was designing certain systems the right way for a future painless switchover. Very happy it's opt in with IEnableableComponent and in general how it's been setup. Obviously things might change before 1.0 and I take all my testing with a grain of salt.

One observation I had was with the SetComponentEnabled on ComponentDataFromEntity which suggest that enabled states can be changed on the fly without the need for main thread/deferring them. This sounds great for a lot of cases however it also has the side effect that other filters have - that without a sync point you can not determine the number of valid entities in a query until scheduling a job. We won't be able to avoid scheduling empty jobs by early out using IsEmptyIgnoreFilter or calculating entity counts etc.

Not a big deal, just a little concerned about users unknowingly creating sync points with things like CalculateEntityCount as I've just found filter sync points to be super annoying recently.

So on a related note of filtering but a bit of a tangent to thread, are there any plans to make CreateArchetypeChunkArrayAsync actually async when filtering is enabled? It currently causes a sync point due to having to pre-define the length of the NativeArray.
Is it possible for us to get a CreateArchetypeChunkArrayAsyncDeferred variate or something that returns a deferred native array [disposing this is problematic though unless you force it onto World.UpdateAllocator] or just make it return a native list instead. I already wrote a proof of concept and found that apart from no longer causing unexpected sync points it significantly reduced main thread cost

 

This seems very similar but slightly different to what I have been doing with chunk components and as such I do wonder if the approach taken here might be slightly inferior. With chunk components, I can do metachunk iteration which is useful for some algorithms like a parallel prefix sum. In addition, the default is "disabled" for new entities which is nice because a reactive system can explicitly query for and initialize new entities while most systems only have to worry about the "enabled" entities. Are similar capabilities planned?

Also, 9X seems slow. I've seen closer to 30-50x speedups with chunk components.

 

Hi @cort_of_unity.
thanks for this details

Can you say more about decision to make not all components to have enable bit? How exactly pros and cons looks like?

I see that with current solution enable/disable no more replacement of add/remove because i can add/remove any component in project (home made or 3rd party one) but can enable/disable only small part that was explicitly designed for it.

So if some 3rd party lib designed around add/remove I can not switch it to enable/disable in late development phase when try to optimize something just because enable disable use different api to work with. Looks like changing internals of 3rd party to add IEnableableComponent to component will not help.

Can you please describe more about:

How it will be actually doable?

And the last question about 128 entities cap on chunk. This means that if entity is smaller than 128 bytes then we just waste space because entity can not be smaller than 16KB / 128. With this new limitation we want to have smaller chunk sizes once again. If we can use chunks of 4KB for some entities than each entity will be 32 bytes in size - 8 bytes for id = 24 bytes of actual data that can be something like 12b velocity and 12b of metadata for fast processing.
Do UT still consider to add option to have smaller chunk sizes?

 

Fun fact, if your entity has a LocalToWorld component, then you are guaranteed to use over half the chunk's memory when maxing out, as LocalToWorld + Entity = 72 bytes.

 

I think dynamic chunk size would be optimal, depending on the size of the archetype, the chunk size should be adjusted automatically 4K/8K/16K/32K.

 

I'm excited! I have a bunch of frameworks that are ready to utilize this. No more checking for "if(component.enabled)".

 

The entity itself is not stored in the Chunks, as far i remember, only the component data and the header. The header would also have to be accounted for in the chunk capacity for the actual component memory. Except that was changed and the actual chunk size was adjusted.

 

The entity itself does take space in the chunk

 

Either that was changed, it is displayed incorrectly, or I overlooked it in the code when I looked at how unity manages the data in the chunks a while ago.

 

Considering how similar ECS is to Databases, why not add support for 'Chunk Indexes' like one can add indexes for tables in databases? Would the performance cost of maintaining the index invalidate it's benefits?

 

It was from the beginning

 

This could make structural changes even more costly as all indices need to be changed. the index would also have to be updated with every change in components. I don't know to what extent that makes sense, since an index only makes sense if you also want a filter by value. It could well be that a simple iteration over all data is faster because it is more cache-friendly.

 

@cort_of_unity How about mega chunk and tiny chunk feature at 1.0 release? I really need this feature that it's essential feature at dots netcode project since it already consume lots of space at chunk at default network entity before I start to add my own components.