registry.view<> on subset of entities without using Tags

[ostorek]

What would be the best way to limit view to subset of entities without using Tags.
We have entities linked in parent-children relationship and suppose i want to do view only on children of the entity:

for (const auto&& [e, c] : viewChildren<Component1,..>(reg, entity) {}

the obvious primitive solution would be emplace every child with ChildTag and then add the tag to the view. However tags would have to be added, cleared and calling this function from multiple threads would add another level of complexity.

Can i somehow create temporary storage, fill it with children entities and create on it view that would do the trick and then return them both?

auto viewChildren(..)
{
   auto onlyChildrenView = ...
   return reg.view<Component...> | onlyChildrenView ;
}

[skypjack]

Can i somehow create temporary storage, fill it with children entities and create on it view that would do the trick and then return them both?

Yeah, definitely. You can create the storage as a standlone member of your class or within the registry with its own name:

struct foo {
    // as member
    entt::storage_type_t<void> storage{};
};

// as managed by the registry
auto &storage = registry.storage<void>("my_name"_hs);

Consider that in the first case you have to manually cleanup it while ie destroy would work on the storage managed by the registry too.
Anyway, when you have it, you can slap it into a view and combine the latter with a second view as you like. For example:

for(auto [entt, my_t]: (entt::basic_view{storage} | registry.view<T>()).each()) {
    // here you get only the entities that are in storage and also have a T
}

Is this what you're looking for?

[ostorek]

That's looks like exactly what i need. Just for clarification:

If i create storage as member, i still need to set it up right, like call bind?
storage.bind(...) // to registry
However seems like bind is there only to later on publish updates to the registry which is kind of unwanted for me.

[skypjack]

If it's unwanted, you can disable the mixin as a whole for all component types. It's also slightly faster in general.
Look at the documentation. It's a matter of setting the storage traits. I plan to make it a compilation flag soon too.
If you disable signals, then you don't need to bind the registry. Otherwise, yeah, it's kinda required, although useless if you never bind a listener.

[eladm-ultrawis]

@ostorek @skypjack I have implemented a small example based on your suggestion.
What I wanted to achieve is to have an association between an object and the list of entities that it owns.
But I just hope I got it right. please see my questions below.

struct ComponentT
{
    int value;
};

using namespace entt;

static unsigned object_id_counter = 0;

class Object
{
public:
    Object(entt::registry& reg) :
        registry {reg},
        storage {registry.storage<void>(object_id_counter++)}

    {

        // Create storage for ComponentT
        //auto& storage1 = registry.storage<void>("sdfsdf"_hs);
    }

    ~Object()
    {
        storage.clear();
    }
    // Add entities and assign ComponentT to them
    void addEntity(int val)
    {
        auto entity = registry.create();
        registry.emplace<ComponentT>(entity, val);
        storage.emplace(entity); // Add to storage
    }

    // Get view of entities with ComponentT belonging to this object
    auto getComponentView()
    {
        return entt::basic_view {storage} | registry.view<ComponentT>();
    }

    void removeEntity(int val)
    {

        auto view = getComponentView();
        for(auto [ent, comp] : view.each())
        {
            if(comp.value == val)
            {
                registry.destroy(ent);
                return;
            }
        }
    }

private:
    entt::registry&      registry;
    entt::storage<void>& storage;
};

TEST_CASE("grouping by storage", "[site_scene]")
{
    entt::registry registry;

    // Create objects A and B, each managing its own entities
    Object A(registry);
    Object B(registry);

    A.addEntity(10); // Add entity to A
    A.addEntity(20); // Another entity
    B.addEntity(30); // Add entity to B

    std::cout << "A entities:\n";
    for(auto [ent, comp] : A.getComponentView().each())
    {
        std::cout << "Entity " << int(ent) << ": ComponentT value = " << comp.value << '\n';
    }
    std::cout << "B entities:\n";
    for(auto [ent, comp] : B.getComponentView().each())
    {
        std::cout << "Entity " << int(ent) << ": ComponentT value = " << comp.value << '\n';
    }

    A.removeEntity(10);

    std::cout << "A entities (after removal):\n";
    for(auto [ent, comp] : A.getComponentView().each())
    {
        std::cout << "Entity " << int(ent) << ": ComponentT value = " << comp.value << '\n';
    }
    std::cout << "B entities (after removal):\n";
    for(auto [ent, comp] : B.getComponentView().each())
    {
        std::cout << "Entity " << int(ent) << ": ComponentT value = " << comp.value << '\n';
    }

I am not sure about the following:

1. What exactly registry::storage do? is it creating a new storage eacy time?
2. How can I make sure to properly clean up my storage once the object is destroyed?
3. why would I use a storage and not storage?
4. Is it more efficient to use entt::basic_view {storage} | registry.view<ComponentT>(); than simply iterating the whole view and filter by some sort of critiria?
5. any comments regarding the attached code will be most welcome.

Thanks

[skypjack]

What exactly registry::storage do? is it creating a new storage eacy time?

The storage function only creates a storage if it doesn't exist. Otherwise, the already existing one is returned.
The type and name pair are unique though. Therefore, T/"foo"_hs and T/"bar"_hs are considered different storage.

How can I make sure to properly clean up my storage once the object is destroyed?

What do you mean with the object?
Since you're creating the storage in the registry, entities are removed automatically when destroyed.
As for ComponentT, you can use signals or a more ECS-y way like an AboutToRemoveComponentT component used by a system to perform cleanup tasks before removing the element.

why would I use a storage and not storage?

Wut?

Is it more efficient to use entt::basic_view {storage} | registry.view<ComponentT>(); than simply iterating the whole view and filter by some sort of critiria?

It depends on the criteria, of course. The pipe returns a view that iterates all the entities that have ComponentT and are in your storage. It's convenient but you have other ways to achieve the same if you like. 🤷‍♂️

any comments regarding the attached code will be most welcome.

I barely get the goal of it. At first glance, storage and the storage for ComponentT contains exactly the same entities all the time. So, why would you create a second storage at all? It seems pointless to me but I'm missing something probably.