General question about how colliders work

I have always wondered how colliders work in the sense of, what/how many calculations are occurring based on X amount of active colliders, Y vertices per collider, Z actual collisions occurring? Less on how colliders calculate reactions, but more on how much checking is occurring. I know Z is probably the biggest hog here, like when colliders are on top of each other say in a fluid simulation.

I imagine a world of localised per frame colliders near moving entities ie. player, streaming the localised collider data (say 16 points/9 quad per chunk_collider) from a master dataset of a non-moving but malleable/fluid world.

Just wondering what is happening when there are big colliders everywhere that are not actually causing a collision with anything? I'm sure such things are optimised, but I don't understand visually how this is working. I've heard of the AABB concept which presumably is enabling colliders or not depending on distance more in the sense of moving objects vs moving objects.

I do love to spend time on these custom adventures, but you know, it's just fun and I learn things along the way! The last time I actually started working on the concept it was in a large deforming world with just the player object as the moving entity, so of course changing one massive mesh collider was out of the question. The visual representation is virtual and enhanced by going straight to the GPU, however the physical representation only matters where collisions are likely to occur. I imagine that can easily be buffered ahead of time from the GPU, giving time to create local chunk colliders.

This thread has an interesting example on how colliders work:
https://discussions.unity.com/t/882653

1 Like

Collision detection in physics engines usually is split into a broad phase and a narrow phase. The broadphase checks for objects that are merely near each other, and that may be colliding. The narrow phase takes all pairs of objects that the broadphase deems necessary to check, and does the actual collider math to see if they're indeed colliding and generate collision information (closest point between them, amount of penetration, contacts, etc).

There's many broadphase algorithms: regular grid, hierarchical grid, BVH (bounding volume hierarchy), BIH (bounding interval hierarchy), KD-Tree, Sort-and-Sweep, etc. If you google these names you'll find detailed descriptions of each one. The goal for a broadphase is to be fast, and as long as it's conservative (it may incorrectly return pairs of objects that don't collide, but must not skip pairs of objects that do!) it doesn't need to be accurate.

So if your world has lots of dynamic objects lying around that don't collide with each other, most of them will be quickly discarded by the broadphase. Some of them may make it into the narrow phase, but overall the amount of work required will be very low.

Also note that broadphase algorithms may be combined, and you may have a sort of middle-phase between the broad and the narrow ones. For instance, you may use Sort-and-sweep as a first broadphase, then if it says that complex colliders - such as mesh colliders- are close to each other, BVHs may be used on those colliders to further prune mesh triangles and reduce the amount of math performed during the narrow phase.

1 Like

Thank you for your detailed answer. Suppose what my thinking on this part is, how much memory do we allocate for this, and levels. And do we assign things to a defined grid/cells, or relative tracking areas. I assume that not all algorithms are broad/narrow, depending on the type of world/environment. Anyway, I hope to have a look at it one day, I just love messing round with algorithms/concepts in my own way without influence on what already exists! I suppose an initial pairing would take the longest, but further pairing could be predictive, ie. collisions may or will (straight bullet/solid) occur x ms away. It's all beyond me, but I always like to try. Destruction physics always look so cool, but are probably extremely complex requiring compute shaders. But then if we have a predictive/pre-emptive strategy, things can be computed before they exist.

Entirely depends on which type of data structure you use and you game's needs. For instance, note that under the umbrella term "BVH" you can have lots of variations: shallower or deeper trees, constructed top-down or bottom-up, different heuristics for balancing, etc. Same goes for most other algorithms.

The term "narrow phase" is generally reserved for the actual geometric tests between pairs of colliders. IE is this capsule overlapping this convex polyhedron and if so, by how much, what's their escape vector, etc. So any prior pruning you do could be considered part of the broad phase.

You just described speculative contacts.

Good luck on your collision detection journey! :)

2 Likes

Interesting I'll have a look at this! :-)