What you explained works yes. Instead of having separate limb colliders that just activate when shot I would consider just doing the calculations manually since collision data gives you the collision point and you can then measure the difference between that and the enemy’s origin. This is if all enemies have the same size and limb positions etc. If not then the colliders system you got might be the simpler way.
As a side node, performance-wise circle/sphere colliders are actually better than box colliders.
Yeah, that’s pretty much how I’ve done it. Another thing this gets around is the limit of active colliders you can even have in the scene. I don’t remember exact numbers but I definitely know you’d be going near or past the limit at the point you described.
As for the box colliders being faster, in theory an AABB would indeed have simpler math than a sphere. However, the idea that it might matter is rather outdated. Computers are absolutely insanely fast these days and it might not matter at all. Thorough testing on a variety of platforms would be required to actually confirm that. This is also assuming that Unity is clever enough to tell that an unrotated, rotation-locked box collider will be able to be treated as an AABB. I’d imagine its more likely just to treat it like any general case box which is much more complicated that a sphere. Perhaps you can get someone from Unity to chime in on this?
A thousand is no problem. I think the limit might be like the 65k-ish realm but that’s going by memory from years ago. The only real thing to watch out for with 1k+ is that they aren’t all in very close proximity to oneanother with collisions enabled for each other. That will grind to a halt pretty quick.
Exactly. The physics engine already does spatial separation and probably even internally uses a bounding box to early out clear misses. I wouldn’t expect manually adding a bounding box collider around objects to positively affect performance.