Context
I have a need to detect the collisions of high speed objects within a physics simulation. Due to the truncating of numbers from a grid and the digital representation of objects, there is a high chance that fast moving objects will pass through each other or miss. I am trying to perform an interpolative collision by emulating the properties of 'analog' or real life motion where an object moves through every point. (Objects in the real world don't normally teleport to their next point on a macro level)
Research and forethought We are able to find the final and initial points of a projected object, displacement in time and velocity. I am using a per pixel collision to get a pixel map so we have a pixel cluster. Currently my approach to this problem is to use the newton's method to calculate a linear intersection.
The question: How does one calculate the intersection of a pixel cluster like they would a 'single pixel' or 'normal' line.
Bonus: what about non-linear motion (velocity with an acceleration) or calculating multiple collisions within an interpolation (where an elastic collision would make one of the colliding object collide with another additional object that would otherwise be moving close by, but missing, the initial collision. This is all preferably within the interpolation calculation.)
Well, one year later and no answers, so I thought I'd try to answer my own question as best I could with my own knowledge.
It would seem that a lot of games don't care about this special case, which can be observed, unfortunately, quite often. Many high speed objects in games will sometimes become glitched into walls or through walls because of a lack of mechanic for catching this. Implementing something to capture high speed objects would require interpolation calculus, which would inevitably lead to higher overhead for the game.
The concept of increased overhead is clear here, if you really want the most accurate physics simulation, you're going to introduce more and more calculations which for a game would effectively make it more and more difficult to maintain a smooth playback of the simulation, especially if there are a greater number of objects to check in with. For example compare the performance overhead of the perfect Per Pixel Intersection to less perfect Axis Aligned Bounding Box Intersection. If you had a game of Pong or Atari style breakout, AABB would be more than acceptable, with the only catch being the ball hitting another rectangle exactly at the corner. At the same time, there aren't enough objects where Per Pixel Intersection would be horrible either (especially if you only consider intersections in terms of only the ball with respect to other objects).
When one is dealing with complex intersections in games, cheating and using approximations to cover up lackluster physics calculations is key. Take our earlier example of per pixel intersection, and this time use something like a game of Mario. We can't just figure out intersections only with respect to mario because he can also throw fireballs which need collision detection, or enemies that interact with other enemies. In this case you could use something like a Quad Tree which continually refines a greater number of collisions into collision zones which contain a predetermined density of object collisions. Now reconsider our pong example with power ups, like adding 4 more balls into the mix. A truly devious programmer could first use a quadtree to put intersections into zones, then perform a preliminary intersection with AABB before determining the exact collision with Per Pixel Intersection if the shape is marked as complex.
Algorithms like Minkowski Portal Refinement or it's cousin GJK distance algorithm, which gives you the shortest distance between convex sets, are probably the closest answer I can give as a solution. I personally don't have a lot of experience with these algorithms, but this is the best I can recommend as the true answer. These algorithms are quite advanced and most definitely beyond beginner-intermediate programmers.
Additional note on Bullet collisions
Now if you came here because you were thinking in terms of a shooting game, I have one more gem for you. I would not recommend actually making bullets "collidable" objects (slower moving missiles, maybe). Instead you could keep your muzzle flash, but turn the visual bullet into an effect. Now to calculate whether the bullet hit, you can calculate using an aligned cone that extends from the muzzle. The change of radius of the cone from tip to infinite bottom can be determined as a constant from an accuracy stat or expanded based on successive fire. Then you take into account, a percentage of how much of the desired object is being intersected by the cone and multiplied by a RNG probability on whether the bullet is a hit. Thus, we simplify the the bullet interaction to a cone vs. objects collision and simply leave the rest up to random number generation. Thus, obtaining the illusion of an accurate physics simulation. Imagine how easy it is to implement a mini-gun now, which would create a ton of lag by all the bullets it would have to spit out in our non-RNG based example.