BEPUphysics

Hey Norbo, just wondering if you have any insight on this. I'm currently upgrading (hopefully big-time) the AI for my game, and I'm thinking about the best way to keep track of nearby enemies and allies for each AI creature in the world. The quickest thing to write was simply a pythagorean distance check on all creatures in the level. However, this wouldn't use any sort of space partitioning system, as BEPU does, so I assume it would be significantly slower. And I really don't want to build my own octree or whatever magic you've got going on in BEPU!

So my question is, what do you think about using a bunch of dynamic (or kinematic?) detector spheres on every AI creature. I could just use one large detector sphere representing the edge of a creature's awareness, and then check for distances on anything inside of that, or I could use a series of differently sized spheres (which don't broadphase with each other) representing the different thresholds of a creature's behavior (awareness range, preferred maneuver range, emergency threat range, etc)

The game will have probably a maximum of 20 enemies on screen at a time, plus a possible four player characters. 20 enemies running around with one or more detector spheres which are quite large, which don't actually have solver collisions with anything, but which fire events -- is this a bad way of going about this? The main thing that seems weird to me is that all the detector spheres will be so large, but if they're only set to have even a broadphase with the objects I care about (enemies, allies, and maybe moving obstacles) the fact that they're all really huge and intersecting each other shouldn't really matter, should it?

Of course, doing the pythagorean distance checks would allow me to only run the checks a few times a second, and maybe spread one check out over several frames. I'm not sure I'd be able to do that using BEPU entities.

Anyway, thanks for reading. I think I'm just nervous about this big last challenge I have to tackle before all the game systems will be in place. Been procrastinating for three days now!


Alex

So my question is, what do you think about using a bunch of dynamic (or kinematic?) detector spheres on every AI creature. I could just use one large detector sphere representing the edge of a creature's awareness, and then check for distances on anything inside of that, or I could use a series of differently sized spheres (which don't broadphase with each other) representing the different thresholds of a creature's behavior (awareness range, preferred maneuver range, emergency threat range, etc)

The game will have probably a maximum of 20 enemies on screen at a time, plus a possible four player characters. 20 enemies running around with one or more detector spheres which are quite large, which don't actually have solver collisions with anything, but which fire events -- is this a bad way of going about this? The main thing that seems weird to me is that all the detector spheres will be so large, but if they're only set to have even a broadphase with the objects I care about (enemies, allies, and maybe moving obstacles) the fact that they're all really huge and intersecting each other shouldn't really matter, should it?

This would run the risk of polluting the broad phase. The acceleration structure must be tested down to the pair level before the broad phase can decide that the two objects do not need an actual pair. This isn't a massive cost, but it can add up when there's lots of stuff going on. You may want to try setting up a mock simulation just to find out how much time it will use.

In addition, creating contacts is relatively expensive. Depending on the number of objects the sphere is allowed to detect, it could have quite a bit of overhead.

Of course, doing the pythagorean distance checks would allow me to only run the checks a few times a second, and maybe spread one check out over several frames. I'm not sure I'd be able to do that using BEPU entities.

If you don't need the information every single frame, it would be faster (and probably easier) to just use broad phase queries. For example, instead of having a sphere follow the character, call Space.BroadPhase.QueryAccelerator.GetEntries(boundingSphere, entries). That will give you any BroadPhaseEntry which has a bounding box which overlaps the given bounding shape.

Since it operates on the level of bounding shapes, it's slightly less precise than contact generation, but quite a bit faster. If more accuracy was desired, you could implement your own test to prune out entries from the list (perhaps center to center squared distance or create a pair handler and force collision detection to run).