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

[Adam M. <amo...@dp...>]

>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.)

Sun, not Source!  But yes, the source code is all on my site, as part of SC.
It is all in this function, in the file CollBody.cpp:

void CollBody::GetCollisionReport(Mat33 &q1, Mat33 &q2, Vec3 &pos1,  Vec3
&pos2, clCollisionReport & cr);

It is rather long, so I won't paste it all in here.  It doesn't use anything
complicated like Johnson's whatever, only some heuristics.  It is also used
in the bouncy rigid body demo on the site, there you can see (I think the
faces and edges which are used are marked in red) that it is quite robust.

I'd like to point out that I am no longer using this code with my current
resting contact project.  I am currently using custom algorithmic collision
detection for simple cases as seen in the MathEngine demos, and am working
on implementing an OBB and space partition tree based approach I made up
myself.  This will not descend to the level of triangles!  Aside from the
obvious speed benefit, I believe getting perfect edge/vertex/face pairs for
resting contact is far more important than for colliding-only contact, and I
don't think I can guarantee this when I use arbitrary geometry and a simple
heuristics based scheme.  Also, as I have mentioned earlyer, I don't think
we will be able to/want to use display geometry to do physics on anyway,
with the rise of HW T&L in grx boards, and the associated explosion of
polygon counts, as well as the introduction of progressive meshes and
subdivision surfaces which keep the display geometry in constant flux
anyway.  I think bounding volumes can provide enough information about the
shape of an object to create very realistic looking physically based
animation.

--
--Adam Moravanszky
http://www.n.ethz.ch/student/adammo

>
>
>> 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
>
>
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list