This is how our solver works; there are a few papers describing Steward-Trinkle/Anitescu-Potra solvers which also do this, for instance: http://www.cs.rpi.edu/~trink/Papers/EBTtr03.pdfmewert wrote:I would actually like to put contacts into the LCP solver before they even become contacts. That helps the bullet-through-paper problem. Kind of a speculative contact.
What we do is wrap shapes in AABBs which enclose their current and predicted positions, and then generate constraints for any shapes whose AABBs overlap; this could also be seen as similar to Guendelman, using a predicted/future position to collect collision info.
The two biggest downsides for us is that (1) you end up with more constraints to solve, (2) narrow/sharp features (acute convex corners) which are rotating quickly can cause fly-through -- this may simply be due to our method of extrapolating/collecting future collisions though (the AABBs don't really model the path of the objects perfectly).
Still, it's pretty awesome in that you get really solid collision using only static tests, without having to resort to a complex event-scheduling problem as with real CCD; the simplicity of "move everything forward, then solve everything" is nice.