#bevy_mod_index

18 messages · Page 1 of 1 (latest)

open wadi
pulsar cradle
#

So make the pitch: why should we migrate to bevy_mod_index from an already working "Hashmap in a resource" solution? 🙂

coarse canopy
#

Right now the I think the big plus is that Indexes refresh themselves when you use them, so you don't need to maintain a system to update them with the latest data, and you will see changes from earlier in the same frame.

pulsar cradle
#

They don't exactly change their position very quickly

tawny ginkgo
#

@coarse canopy have you considered using a bloom filter? Seems it could be nice for very large entity counts, can narrow down for fairly cheap the set of things to check, especially for 4/8-bytes indices.

frosty jasper
tawny ginkgo
#

I specifically mentioned "4/8 bytes indices", a simple PRNG would be a good hash, furthermore, bloom filters are specifically about saving memory, you don't have to store the preimage and you can get away with a 64 or 128 bits (bits, not bytes) array.

#

I thought this was a surprisingly but promising use-case for a bloom filter

#

Iirc, I computed a 95% hit rate on a few thousand entries for a 128 bits bloom filter

#

The way you do it is:

  • you run the PRNG on your index value
  • Pick the first 7 bits as the index in the 128 bit array to enable
  • Pick the next 7 bits for the second index to enable
    That's the bit array to compare against

Now you have the base array to compare against, it's the same process to do "contains" check. This can save a lot of computation depending on how sparse your indexed lookups are.

As you can see, I thought about this a bit.

coarse canopy
#

Interesting, I hadn't heard of bloom filters before. I'm not sure how helpful they would be though. My current assumption is that updating the index is the bottleneck, not the lookup itself.

#

From what I've just read, it seems like they are best at when the real lookup is quite slow (like reading from disk) and you can't keep everything in memory, but I would already need to keep the actual source of truth in memory anyway

frosty jasper
quick mulch
#

Hi, I am currently looking into bevy_mod_index and was wondering: Is it possible to specify an index that only works on entities with a specific set of components? What I mean is this: I am using marker components which I suffix with "Tag" and for the example's sake let's say I also have an Id component. Now what I would like to do is create a way to retrieve all entities with FooTag by the value of the Id component. And at the same time, I would also want an index for BarTag entities. Ideally, this would also support some combination similar to queries where I could specify the indexed entities need component A but cannot have component B, etc. I hope this makes clear what I am trying to achieve. Happy to elaborate further if necessary. Is this already possible?

coarse canopy
quick mulch
#

Thanks for the quick reply. After playing around with different solutions I am for now going with a separate Id component for each type of entity. It's not as elegant but seems like the best solution for my current goals.

frozen terrace
#

I'm doing some experimentation with this crate, I didn't test it to replace resources yet, I only used it in a very simple use case to try out, where I replace a query with a lot of checking by a index lookup. However, I noticed up to 20x slow down in some benchmarks I was doing.

Am I doing something wrong? (maybe the scenario I picked doesn't fit this well).
Or is that expected?