this thread is about the question, whether it is a good or bad idea to add AABB colliders for every map square to a Physics World. I know that performance tests would be the only we way to have a reliable data on this. But to do so some time has to be spent and I want to know whether this can be handled by ECS Physics without noticeable performance drops in general or not.
Whats the reason to do so: My game world already has a level map which is divided in map squares. Now I want to use the map square grid for choosing AOE targets by the computer intelligence. A simplistic approach using a score system based on each map square would do the job here.
Lets assume it would need 10000 (10k) map squares to represent all of them within a level in the Physics World. So 10k entities had to be added with an AABB Physics Collider. No rigid body required, so they are only static bodies which are not moving at the end. These colliders are placed on it own layer so they don’t interfere with other kinds of colliders and can be queried on its own.
The advatage I see is, that raycasts and other collision tests would also determine the affected map squares which are hit. I have to do obstacle collision checks with raycasts in any way. But without using 10k of entities/AABB colliders all the map square calculations have to be done additionally without ECS Physics. Without knowing it, my guess is that ECS Physics can handle these calculations faster regarding performance than doing it without, because ECS Physics is optimized for collisions and all this is done in one step instead of doing Physics and separate calculations.
But my fear is that introducing 10k of AABB colliders causes some serious performance issues on my Physics World overall for example for non-map square related collision tests. Additionally I have also to state that I am using Netcode for Entites and I want to rely on Lag Compensation. This causes copies of the Physics Collision World to be made and accessed for compensating client lag. And I worry about, that the overhead of the AABBs would be immense here.
Have you thought about using a navmesh instead? It might be a more effective approach. However, you have your reasons, and if using squares is essential, consider adding a WorldRegion feature to your game. This feature would divide the map into regions along the x and z axes, creating sub-scene sections for each. You can then place squares or any other entities within these sections. By loading and unloading regions based on player position, you’ll significantly reduce the number of active squares and other entities.
Thanks for your answer. I do not know how navmesh could be integrated in a useful way here, because I thought it is only used for pathfinding.
My issue is not about finding a route instead I want to find a suitable position to fire grenades onto by the computer intelligence. Because of grenades are capable of hitting multiple targets at once the targeting is more difficult than simple straigth shots. A map square in my game project is very small, lets say one unit can be part of a square so an adjacent unit may be in a map square next to it. For calculation of an effective grenade spot each square could get a calculated local score depending on the unit within. The scores of each square are then summed up to an area score. These area scores includes the local scores of squares within the grenades radius. Then the computer intelligence can target the grenade onto a square which has the highest summed area score. This is a very simplified approach and not totally accurate due to having the approximation of using squares, but fully sufficient in my case.
I have to do Physics raycast probing to most importantly see which squares can be targeted, because of obstacles in the way. Then I need to remember every traversed square by these raycasts because it is a potential square which can be targeted by the computer intelligence. For all potential squares the area score is calculated then and the square with the highest score is chosen as target.
The WorldRegion feature you mentioned sounds like an idea for big maps, but my maps are small at the end so 100 * 100 map squares for examples which is not much when considering that one unit fits into a square. Also introducing a system for dynamic loading/unloading of regions would made things more complex.
Sounds like you just want to do your own grid of data, such as a gradient cost map. Instead of abusing the Physics system for it, you should just calculate the grid cells along a line as necessary. If you have static obstacles, you can precalculate some of the visibility, but even if you don’t precalculate, traversing through the grid for a live linear check of visibility is not that complicated.
Relying on your second message, it seems like you are trying to create some sort of influence map. Which is a very common approach to access area related data. Like Danger/Safe area or get the right position to hit multiple players …
Thanks for your answers. Now after reading your responses I also think it is best to do these grid calculations without using Physics. Indeed it should not be that complicate.