Advertisement

Contact creation

Started by August 12, 2015 02:35 PM
35 comments, last by Dirk Gregorius 9 years ago

Somehow, gauss-map SAT for boxes seems to be incredibly slow and when I crash the ball into the wall, FPS goes down to about 2 sad.png

In contrast, a brute force version (specialized for boxes) works just fine.

Also my wall is MUCH sturdier now, bricks sometimes get stuck in weird positions and I can't tell if that's correct or not. The demo is still at http://www.d3planner.com/webgl/, I added contact visualization to it too.

Did you check what is slow? Querying the features, clipping? You can ignore the edge cases and see if that helps. I also don't know what data structure you use and how costly it is to iterate the features.

Of course the specialized box collider will be faster. But how often do you have boxes in a game? Interestingly I never implemented a specialize collider for Source 2 since the SAT was so fast for me. Sure, it is still O(n^2), but the trick is the feature caching as I point out in the presentation. If the relative orientation doesn't change just re-clip. You just need to look out for the case when you clip away all points. This happens if two shapes slide off each other.

Again, the trick for fast collision detection is not whether you use GJK, SAT, EPA, etc, but to not call any of that functions at all if possible utilizing temporal coherence!

The demo looks good to me. Stability looks fine as well. It would be nice if I could shoot the ball into different directions and also mouse-pick objects to test weird sturdiness.

Advertisement

By the way, completely unrelated, in your quickhull presentation, is it possible for the horizon to consist of more than one face? At least in 2D case, it seems easy to prove that if you pick the furthest vertex on every step, you will never 'see' other faces from the consequent vertices? Or does it have something to do with using fat planes/faces?

Not sure what you mean. In this case e.g. I would have more than one face/edge:

Horizon.png

The clipping seems fast enough, its just the SAT itself that is slowing everything down. Profiler says most of the time is spent computing various dot products. I'll look into caching - I suppose we could just try the previous exis, ensure that the penetration isn't too deep, and that the clipped poly is non-empty, otherwise re-run SAT? I also don't exit prematurely if I get a non-zero separation, that could help I suppose.

Actually the stability isn't that great, if I tweak the number of iterations or add restitution it all falls apart pretty quickly, not sure why sad.png

As for quickhull, how is that configuration possible? Assuming you were always adding the furthest point, why is that point being added so late? It would seem that 'all unadded points see only one face of the hull' is an invariant that is preserved when we add a new vertex. Maybe I don't understand the algorithm?

Yes, if you clip away all points re-run SAT.

For this scene I would expect it to be stable with about 8 iterations.

I cannot answer your question confidently. You might be right that this situation can never happen in 2D. I would need to think about it more. If we can show that no new vertex can lie in the Voronoi region of an existing vertex on the current hull you would be correct I guess. In 3D you can have multiple faces for sure though! I didn't want to make a special case in 2D for that reason in the presentation iirc.

If you wanted to be able to add incrementally new points to an existing hull you might want to be able to handle horizons with more than one edge. If you wanted :)

Yeah you're right, in 3D there's the edge case that breaks everything sad.png
Advertisement

Okay, re-clipping indeed drastically reduces the number of SAT calls and seems to work really well. What do you do with edge-edge contacts though - just re-run SAT every time, seeing as they're pretty rare and often don't last very long?

Going through the collision table, in the Capsule vs Hull case, can you use the 'smart' SAT? What would be the plane normals for the capsule's only edge?

In the edge/edge case I simply recompute the closest points. You need to detect if the edges slide off each other. Luckily this is simple. I just compute the closest points between the lines through both edge vertices just check that they are actually on the edge. If t < 0 or t > 1 re-run the SAT as well.

Yes, you can use the smart SAT as well. The test is even easier. Randy wrote a summary here:

http://www.randygaul.net/2015/04/03/capsule-to-convex-sat-edge-prune-via-gauss-map/

I didn't check if it is correct though, but it looks good. Maybe a bit more complicated than it needs to be.

Oh, also make sure to cache a separating axis. Basically in the case penetration you re-clip or rebuild closest points. If you found a separating axis test this first the next frame before you run the SAT as well.

You should see the idea here. We only run SAT if we are forced with guns and knives to do so smile.png

You mean if I found that the objects don't intersect, I should use that axis on the next frame? Good point I guess, although if I quit SAT early on any separating axis, it might not find the best one for the next frame. Not a big deal though.

This topic is closed to new replies.

Advertisement