among many other features, Svelto.ECS 3.3 introduces a new shiny and finally usable filters API. The previous one had the bad habit to get very awkward very fast with the growth of complexity. The new API learns from the previous mistakes and introduces a ton of sweet features.

To recap what filters are useful for:

Svelto.ECS memory layout is driven by the concept of groups. Any subset of entities is found in a specific group and for this reason, groups usually model the state of the entity. Each entity can be found only in one specific group, but this is often not a problem as GroupCompounds are designed to model multiple states, to be specific any combination of up to 4 different states. However in some situations, Groups can either get too awkward or fragment the memory too much, and in these cases, Filters come to the rescue as an alternative way to create a subset of entities. Filters are particularly powerful because can be used together with GroupCompounds. This means that thanks to filters and group compounds entities can be found at the same time in different subsets.

The most important change in the new API is probably the fact that the user now doesn’t need anymore to be aware of the groups where the entities are in order to use filters, making filters completely independent from the groups under the users point of view. The Svelto patterns assume that filters are iterated first and filters will contain the information about in which group the entities are found.

A good example of the new Svelto API can be seen in the shiny new Doofuses Stride example.

If you already used the previous API (probably you didn’t :P) the first thing you’d notice is that now Filters can be Persistent or Transient. While transient filters are cleaned between each entities submission, the more useful persistent filters are held and managed directly by the framework. If an entity is removed, the filters where the entity is found will be automatically updated.

In the new Stride demo, we had the necessity to instance a prefab many times, but demo groups do not represent the entity mesh, so in order to know which mesh the entity uses, filters are used.
The following engine has the responsibility to automatically and generically update filters according to the stride mesh found in the svelto stride entity.

Note that since the user can choose any ID as filter ID, I decided to use as filter ID the ID of the Stride Entity to instance, which becomes very convenient in the following engine that has the responsibility to fetch the list of instancing matrices per Stride Entity and update it with the new transformations from the Svelto.ECS entities:

if we delete some code that is necessary to make Stride render the instanced entities, we can see how the new Svelto.ECS filters API pattern works when it’s time to iterate filtered entities:

thanks to the filters and these two engines I can add any kind of Svelto Entity linked to a specific mesh without needing to worry about how to organise the memory layout to accommodate entity states and meshes combinations.

0 0 votes
Article Rating

Leave a Reply

Inline Feedbacks
View all comments