11 comments

[ 3.6 ms ] story [ 30.2 ms ] thread
Hey that's Ascension from Halo 2. Cool test case!
This is novel indeed! What about non-spherical shapes? Do we assume a spherical bounds and just eat the cost? Either way, narrow phase gets extremely unwieldy when down to the triangle level. Easy for simple shapes but if you throw 1M vertices at it vs 1M vertices you’re going to have a bad time.

Any optimization to cut down on ray tests or clip is going to be a win.

I'm trying to work through the math here, and I don't understand why these two propositions are equivalent:

1) min_{x,y} |x-y|^2

   x ∈ A

   y ∈ B
2) = min_{x,y} d

   d ≥ |x-y|^2

   x ∈ A

   y ∈ B
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?
Aside: I learned the Sep Axis Theorem in school and often use it for interviews when asked about interesting algorithms. It's simple enough that you can explain it to non-technical folks. "If I have a flashlight and two objects, I can tell you if they're intersected by shining the light on it". Then you can explain the dot product of the faces, early-exit behavior and MTV.
(comment deleted)
Nice. It's definitely an optimization problem. But you have to look at numerical error.

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

I’m getting sick of the number of links submitted to HN blasting me with cookie spam bullshit.
-4 points suggests many HN users seem to enjoy being spammed by popups
This stuff is always so interesting to me because this is the part/step of solo game-development where people don't make too much content about it online, so you need to find books/scraps of content about rolling your own complex physics engine. It's all knowledge that's stuck in the industry/random github repos it seems.