Question about using the DynamicHierarchy

[Telanor]

I've been digging around looking at the DynamicHierarchy class and I'm wondering if it'll be a good solution to my problem. My world is divided up into sections called regions which are laid out in an infinite grid and loaded/unloaded as the player moves around. The regions contain entities which can possibly span multiple regions at once. I need to be able to take a position and run a query to find what entity (if any) exists at that position. The entities are mostly static and won't be responding to physics.

The DynamicHierarchy looks like it'll be able to do that, but I have a few questions. Would it be best to just use the DynamicHierarchy by itself, create a separate Space, or perhaps just use the already-existing Space that I use for normal physics? And is the BoxEntity the simplest/most-lightweight box shaped BroadPhaseEntry to use to represent my entities?

Also, how well does the DynamicHierarchy handle/perform when there are multiple "islands" of physics regions? I ask because in multiplayer, each player will load a certain amount of regions around him, and if many players are spread out, they'll essentially each be on their own physics island.

[Norbo]

Would it be best to just use the DynamicHierarchy by itself, create a separate Space, or perhaps just use the already-existing Space that I use for normal physics?

I wouldn't recommend a whole extra Space just for the DynamicHierarchy queries.

If queries are frequent, a separate lone DynamicHierarchy almost certainly wins.

If queries are very rare and there aren't many of these entities, the combined everything-in-one-Space approach might win by a little bit. Of course, at that point, it would hardly matter. In this case, development convenience would be a more important metric than the performance difference.

And is the BoxEntity the simplest/most-lightweight box shaped BroadPhaseEntry to use to represent my entities?

A Box entity is a bit heavy. All of the entity part would be useless for the queries since the dynamic hierarchy is unaware of Entity as a type. It just deals with BroadPhaseEntry objects. A lighter option would be a ConvexCollidable<BoxShape>.

Technically, the lightest possible option would be a custom BroadPhaseEntry. The RayCast and ConvexCast queries would need to be defined, though. The RayCast could just be Ray.Intersects, and the ConvexCast could just return false unless you plan on using it.

[Norbo]

Oops hit reply too quick:

Also, how well does the DynamicHierarchy handle/perform when there are multiple "islands" of physics regions? I ask because in multiplayer, each player will load a certain amount of regions around him, and if many players are spread out, they'll essentially each be on their own physics island.

The DynamicHierarchy is not really sensitive to the layout of objects. It'll work fine and run at normal speeds.

A couple of extra notes:
-The DynamicHierarchy will try to find collisions when it is updated. If you need to call update frequently to update the tree structure, it may be worth customizing it to not perform the intersection tests.
-The DynamicHierarchy and systems touching it are in for a fairly significant rewrite in the not-terribly-distant future. Limiting what directly interfaces with it would avoid some pain later on.

[Telanor]

Ok, I'll go with the separate DynamicHierarchy then. If the entities never move, does that mean I don't have to call update on the DynamicHierarchy?

[Norbo]

If the entities never move, does that mean I don't have to call update on the DynamicHierarchy?

Almost. It may be a good idea to call Update after adding and removing objects (or more efficiently, batches of objects). It will work without it, but queries could get quite a bit slower depending on the add/remove order.

If you rarely or never add or remove objects, you might get better performance just using a BoundingBoxTree<T> and calling its Reconstruct as necessary.

[Telanor]

Alright, thanks for the help as always Norbo.