Re: [Algorithms] Using RAPID within a rigid body simulator

[Pierre T. <p.t...@wa...>]

I'm glad to see it works! Exactly what I wanted to see confirmed, thanks.


> No, I successfully postprocess RAPID's output to do that.  Specifically, I
> need a vertex-face pair or an edge-edge pair to be used as contacts.
RAPID

Agreed, those are the usual suspects.


> gives you intersecting triangle pairs, but if you look at where those
> triangles were one step earlyer (before they intersected) you can do some
> distance computations to find which of their features (verticed and edges)
> were the closest at that point, which gives the vertex face and edge
pairs.

This is what I was expecting to do, since this is the method used in
Q-Collide as well. I was actually wondering what kind of distance
computation would be the best here. I mean, while I'm at it I guess I can
use Johnson's distance subalgorithm on two triangles reported by RAPID as
intersecting in the next frame. But maybe there's no need for such a tool,
and simpler distance computations can be used. Would you mind sharing some
details there? (..oh... wouldn't this code be included in Source Commander
? - I think that was the name of the project IIRC. I'll check that.)


> The rigid body simulation itself typically doesn't need to track closest
> points, unless they are really close, as above.  Permanent closest point
> tracking between objects is usually used to speed up the collision
detector
> (temporal coherence).

I don't follow you there. To me, permanent closest point tracking (as used
in I-Collide for example) is only used to waste CPU time :) Because most of
the time you just don't need them: you just need them when there's a
collision. Makes sense ?

Pierre