-
Notifications
You must be signed in to change notification settings - Fork 21
Kinematic collisions broadphase #444
Comments
I was already thinking about collisions optimization and I have a plan to keep BodyRect pool sorted in some "chunks" to check only the limited amount of bodies. I will code that in a few days and check how much faster it is comparing to the current algorithm (it should be much better). Another advantage that I want to take from specific components order is to make collisions calculations run concurrently. |
I'm going to try patching the collision detection systems to take advantage of EnTT's reactive systems. That could vastly cut down the number of entities processed without needing to change much code. |
@PiotrGardocki |
@20zinnm |
@Czapa10 I dug into it a bit. Though I think using the reactive systems would improve the performance, it alters the ECS paradigm and we'd probably see better gains by implementing a broadphase. |
Also, that particular EnTT API is undergoing rapid changes, so adding a code dependency there might become a headache later on if you try and upgrade the EnTT version. |
I was just looking through the code to see what sort of things I might be able to help optimize and I stumbled on the kinematic collision solver. It looks like it's performing a brute-force collision detection algorithm, which has a complexity of O(n^2).
Since all of the collision bodies are rectangles, it would be fairly trivial to integrate a broadphase algorithm to reduce the number of nearphase collision checks needed. This would become more important as you add increasingly sophisticated nearphase algorithms, i.e. detecting circle-on-rectangle (#443) or rectangle-on-polygon collisions.
The text was updated successfully, but these errors were encountered: