how does unity physics work under the hood?

take this image for example
on image 1, one object moves into 8 other colliders, it makes sense to me that the physics engine has to iterate over every single of these 8 colliders and evaluate if theres a collision

on image 2, there is no feasible possibility of collision with any colliders, so the 8 colliders should not be iterated through and checked for collisions at all

Am I correct in making this assumption?

Lets say if i had 1 million colliders in some corner of my scene, and i was moving around on the other side of the map, would the 1million colliders that are completely static and outside of physics range impact the performance of the game?

(putting aside that there are million game objects, I just wanted to know how physics is working)

"Unity Physics" is Box2D for 2D and PhysX for 3D. DOTS uses it's own HPC# and there's also Havok C++. There isn't a single "physics" engine but they all approach this in a similar way.

Here's the 2D Box2D source though:

No. It only has to check the "colliders" it overlaps as defined by the fact that its AABB overlaps. As simple as that.

There's a common and well documented technique for all physics engines and other things that need to perform spatial queries and that's implementing a spatial acceleration structure i.e. a broadphase. Its role is to provide pairs of AABB that overlap meaning that "colliders" might be overlapping; it's fast and cheap. Only these pairs are then checked in what is called a "narrowphase" which is the actual detailed intersection tests which are more expensive.

This is well documented online so search for "broadphase", "narrowphase" etc.

1 Like

For the most part yes - almost any production quality physics engine will have some kind of spatial query data structure which allows quickly finding the approximate set of objects within certain region without having to iterate through all of them.

There will still be some increase in cost of spatial queries as the total number of objects increase (even if you ignore the cost of million game objects by themselves) as having more objects will increase the depth of search tree, but it will increase more slowly the more objects you have. For example difference between 100k and 1000k will probably be smaller than increase from 1 to 100k.

See if you want to learn more about various spatial data structures. (ignore the rest of wikipeadia article, physics engines aren't using actual spatial databases as those are made for different use cases with different tradeoffs, but underlying data structures are the same)

Also most game physics engines will have a concept of making inactive objects sleep. Once a group of objects sits still for a while physics engine will mark the objects "sleeping" and exclude them from most physics calculation until something collides with them. See last part of . So even if those million objects are dynamic instead of static level geometry, the performance might be not that bad as long as nothing touches or moves them.

But if you are making a game the best thing you can do is make test scene which approximates the scenario and interactions you are considering for your game. While some parts of engine might be able to deal with it, million objects is quite a lot, you might hit some unexpected bottle necks that you didn't predict. So do the profiling and check whether performance issues are caused by something that can be avoided.

But if you really want to learn details more about how physics engines work - Unity uses Box2d and PhysX as it's 2d and 3d physics engines, source code and documentation of both is publicly available. You can dig in as deep as you want. It won't necessary be the exact version as Unity have but for general learning it won't matter.

There is also plenty of general literature and videos of people making physics engine from scratch (mostly as learning exercise) you can learn a lot from those as well. Doesn't have to be unity specific as a lot of high level optimizations will be very similar.