Our great sponsors
-
JoltPhysics
A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
ConvexBodyProximityQueries.jl
A fast module for computing proximity queries between convex bodies in 2D/3D
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
GJK handles closest points (and distance, normal) between two non-overlapping convex shapes. Once convex shapes penetrate, you can use EPA, the Expanding Polytope Algorithm, invented Gino van den Bergen (while we were working together at NaN/Blender). See also http://dtecta.com/publications and check out this recent implementation in C++ for both GJK and EPA is in Jolt Physics (used in the game Horizon Forbidden West): https://github.com/jrouwe/JoltPhysics/tree/master/Jolt/Geome...
The usual approach is some form of sweep to get a time of impact. Once you've got a time of impact, you can either generate contacts, or avoid integrating the involved bodies beyond the time of impact, or do something fancier like adaptively stepping the simulation to ensure no lost time.
If the details don't matter much, it's common to use a simple ray cast from the center at t0 to the center at t1. Works reasonably well for fast moving objects that are at least kinda-sorta rotationally invariant. For two dynamic bodies flying at each other, you can test this "movement ray" of body A against the geometry of body B, and the movement ray of body B against the geometry of body A.
One step up would be to use sphere sweeps. Sphere sweeps tend to be pretty fast; they're often only slightly more complicated than a ray test. Pick a sphere radius such that it mostly fills up the shape and then do the same thing as in the previous ray case.
If you need more detail, you can use a linear sweep. A linear sweep ignores angular velocity but uses the full shape for testing. Notably, you can use a variant of GJK (or MPR, for that matter) for this: http://dtecta.com/papers/jgt04raycast.pdf
If you want to include angular motion, things get trickier. One pretty brute forceish approach is to use conservative advancement based on distance queries. Based on the velocity and shape properties, you can estimate the maximum approaching velocity between two bodies, query the distance between the bodies (using algorithms like GJK or whatever else), and then step forward in time by distance / maximumApproachingVelocity. With appropriately conservative velocity estimates, this guarantees the body will never miss a collision, but it can also cause very high iteration counts in corner cases.
You can move a lot faster if you allow the search to look forward a bit beyond potential impact times, turning it into more of a root finding operation. Something like this: https://box2d.org/files/ErinCatto_ContinuousCollision_GDC201...
I use a combination of speculative contacts and then linear+angular sweeps where needed to avoid ghost collisions. Speculative contacts can handle many forms of high velocity use cases without sweeps- contact generation just has to be able to output reasonable negative depth (separated) contacts. The solver handles the rest. The sweeps use a sorta-kinda rootfinder like the Erin Catto presentation above, backed up by vectorized sampling of distance. A bit more here, though it's mainly written for users of the library: https://github.com/bepu/bepuphysics2/blob/master/Documentati...
I should be writing a thesis about AI but got inside the collision rabbit hole so I have this fresh.
From the description of the algorithm you are doing I think you are thinking about Lin-Canny or V-Clip, which certainly may have that kind of numerical error problems.
GJK has also numerical problems but they are different. In principle it shouldn't be affected by coplanarity of several faces since you just need the vertex with highest support for a given direction. It could be a problem if you find the support point by hill climbing from vertex to vertex. GJK however does have numerical problems but they are of a different kind related to the degeneracy of the simplices it computes.
But you are so right about the subtetly of the problem: there is a very fine thread between infinite looping and incorrect answers. I have been bitten by this trying to implement geometric algos. There should be a special hell for people that output coplanar faces.
I know one of Bullet Physics/MuJoCo has the GJK, not remember which one. If anyone is curious I know of two Julia implementations:
https://github.com/JuliaRobotics/EnhancedGJK.jl
and my favorite: https://github.com/arlk/ConvexBodyProximityQueries.jl
This latter one is great as you are just required to implement the support function and are ready to go. Julia performance is great if you are concerned about using a dynamic language (i.e: ~2us for collision between two convex bodies of 1000 faces each)
Finally, about the convex hull computation it looks like some kind of solved problem, I mean, O(n log(n)) for 3D. Wrong!!!! QHull in this regard is fantastic as it has several heuristics to solve problems caused by finite precision, not to mention that I think worse case is O(n^2) as it doesn't implement the asymptotically optimal algo (not sure...). If you scale to more dimensions, which could happen even in if 3D because you transformed your problem to a convex hull problem you will be hit with O(n^2), bad news. There are several other libraries (CCD, LRSLib and more) that allow you to use arbitrary precision but you will get something like a 100x penalization for the luxury.
I should be writing a thesis about AI but got inside the collision rabbit hole so I have this fresh.
From the description of the algorithm you are doing I think you are thinking about Lin-Canny or V-Clip, which certainly may have that kind of numerical error problems.
GJK has also numerical problems but they are different. In principle it shouldn't be affected by coplanarity of several faces since you just need the vertex with highest support for a given direction. It could be a problem if you find the support point by hill climbing from vertex to vertex. GJK however does have numerical problems but they are of a different kind related to the degeneracy of the simplices it computes.
But you are so right about the subtetly of the problem: there is a very fine thread between infinite looping and incorrect answers. I have been bitten by this trying to implement geometric algos. There should be a special hell for people that output coplanar faces.
I know one of Bullet Physics/MuJoCo has the GJK, not remember which one. If anyone is curious I know of two Julia implementations:
https://github.com/JuliaRobotics/EnhancedGJK.jl
and my favorite: https://github.com/arlk/ConvexBodyProximityQueries.jl
This latter one is great as you are just required to implement the support function and are ready to go. Julia performance is great if you are concerned about using a dynamic language (i.e: ~2us for collision between two convex bodies of 1000 faces each)
Finally, about the convex hull computation it looks like some kind of solved problem, I mean, O(n log(n)) for 3D. Wrong!!!! QHull in this regard is fantastic as it has several heuristics to solve problems caused by finite precision, not to mention that I think worse case is O(n^2) as it doesn't implement the asymptotically optimal algo (not sure...). If you scale to more dimensions, which could happen even in if 3D because you transformed your problem to a convex hull problem you will be hit with O(n^2), bad news. There are several other libraries (CCD, LRSLib and more) that allow you to use arbitrary precision but you will get something like a 100x penalization for the luxury.