A fast 3D collision detection algorithm
269 points| OlympicMarmoto | 8 months ago |cairno.substack.com
github repo: https://github.com/cairnc/sat_blog
269 points| OlympicMarmoto | 8 months ago |cairno.substack.com
github repo: https://github.com/cairnc/sat_blog
[+] [-] Animats|8 months ago|reply
I had to do a lot of work on GJK convex hull distance back in the late 1990s. It's a optimization problem with special cases.
Closest points are vertex vs vertex, vertex vs edge, vertex vs face, edge vs edge, edge vs face, and face vs face. The last three can have non-unique solutions. Finding the closest vertices is easy but not sufficient. When you use this in a physics engine, objects settle into contact, usually into the non-unique solution space. Consider a cube on a cube. Or a small cube sitting on a big cube. That will settle into face vs face, with no unique closest points.
A second problem is what to do about flat polygon surfaces. If you tesselate, a rectangular face becomes two coplanar triangles. This can make GJK loop. If you don't tesselate, no polygon in floating point is truly flat. This can make GJK loop. Polyhedra with a minimum break angle between faces, something most convex hullers can generate, are needed.
Running unit tests of random complex polyhedra will not often hit the hard cases. A physics engine will. The late Prof. Steven Cameron at Oxford figured out solutions to this in the 1990s.[1] I'd discovered that his approach would occasionally loop. A safe termination condition on this is tough. He eventually came up with one. I had a brute force approach that detected a loop.
There's been some recent work on approximate convex decomposition, where some overlap is allowed between the convex hulls whose union represents the original solid. True convex decomposition tends to generate annoying geometry around smaller concave features, like doors and windows. Approximate convex decomposition produces cleaner geometry.[2] But you have to start with clean watertight geometry (a "simplex") or this algorithm runs into trouble.
[1] https://www.cs.ox.ac.uk/stephen.cameron/distances/
[2] https://github.com/SarahWeiii/CoACD
[+] [-] OlympicMarmoto|8 months ago|reply
Yeah I agree, the error analysis could be many blogs in and of itself. I kinda got tired by the end of this blog. I would like to write a post about this in the future. For global solvers and iterative.
> Finding the closest vertices is easy but not sufficient.
As I'm sure you are aware, most GJK implementations find the closest features and then a one shot contact manifold can be generated by clipping the features against each other. When GJK finds a simplex of the CSO, each vertex of the simplex keeps track of the corresponding points from A and B.
> A second problem is what to do about flat polygon surfaces
Modern physics engines and the demo I uploaded do face clipping which handle this. For GJK you normally ensure the points in your hull are linearly independent.
[+] [-] CamperBob2|8 months ago|reply
I wonder if it would be smart to restate the problem in just those terms -- managing bounding-volume overlap rather than interpenetration at the geometric level.
If everything is surrounded by bounding spheres, then obviously collision detection in the majority of cases is trivial. When two bounding spheres do intersect, they will do so at a particular distance and at a unique angle. There would then be a single relevant quantity -- the acceptable overlap depth -- that would depend on the angle between the BV centers, the orientation of the two enclosed objects, and nothing else. Seems like something that would be amenable to offline precomputing... almost like various lighting hacks.
Ultimately I guess you have to deal with concavity, though, and then the problem gets a lot nastier.
[+] [-] contingencies|8 months ago|reply
[+] [-] EGreg|8 months ago|reply
And part two: https://www.flipcode.com/archives/Theory_Practice-Issue_02_C...
[+] [-] msteffen|8 months ago|reply
1) min_{x,y} |x-y|^2
2) = min_{x,y} d What is 'd'? If d is much greater than |x-y|^2 at the actual (x, y) with minimal distance, and equal to |x-y|^2 at some other (x', y'), couldn't (2) yield a different, wrong solution? Is it implied that 'd' is a measure or something, such that it's somehow constrained or bounded to prevent this?[+] [-] OlympicMarmoto|8 months ago|reply
https://en.wikipedia.org/wiki/Epigraph_(mathematics)
[+] [-] Jaxan|8 months ago|reply
[+] [-] mathgradthrow|8 months ago|reply
U={(a,b,x):x>|a-b|^2}
and then were looking for the infimum of (the image of) U under the third coordinate function
d(a,b,x)=x
[+] [-] markisus|8 months ago|reply
edit: I see now that the problem 2) is missing d in the subscript of optimization variables. I think this is a typo.
[+] [-] leoqa|8 months ago|reply
[+] [-] ttw44|8 months ago|reply
[+] [-] RobRivera|8 months ago|reply
I highly recommend it to you.
[+] [-] reactordev|8 months ago|reply
Any optimization to cut down on ray tests or clip is going to be a win.
[+] [-] bob1029|8 months ago|reply
We pick the bounding volume that is most suitable to the use case. The cost of non-spherical bounding volumes is often not that severe when compared to purely spherical ones.
https://docs.bepuphysics.com/PerformanceTips.html#shape-opti...
Edit: I just noticed the doc references this issue:
https://github.com/bepu/bepuphysics2/issues/63
Seems related to the article.
[+] [-] bruce343434|8 months ago|reply
[+] [-] andrewmcwatters|8 months ago|reply
I would assume using this algorithm wouldn't necessarily change that creation pipeline.
[+] [-] OlympicMarmoto|8 months ago|reply
[+] [-] unknown|8 months ago|reply
[deleted]
[+] [-] socalgal2|8 months ago|reply
https://news.ycombinator.com/item?id=44334403
[+] [-] OlympicMarmoto|8 months ago|reply
[+] [-] unknown|8 months ago|reply
[deleted]
[+] [-] double051|8 months ago|reply
[+] [-] chickenzzzzu|8 months ago|reply
[+] [-] MortyWaves|8 months ago|reply
[+] [-] MortyWaves|8 months ago|reply