[ODE] Location of contact points

[Charles James Leonardo Quarra Cappiello]

>My questions are:
>
>* Is it more correct to have the contact point always on the surface of
>at least one of the volumes ? or is it better to have it kind of "in the
>middle" if the volumes overlap" ? (how does this decision affect the
>physics simulation? )
>


>* If two boxes overlap with one corner each, what is the correct contact
>normal ? should i try to find some kind of "secant plane" or just use
>any normal ?
>


AFAIK the current paradigm of collision detection in ODE tri-collider with 
the hash map stuff and OPCODE can be minimalistically expressed as:
for each object, move from frame A to frame B, CD module reports overlaps of 
the objects in frame B. Note that in this case interpenetration always 
occur, but (at this point is where i dont fully follow u) you DONT WANT IT 
TO HAPPEN. ODE assumes the CD module puts contact points on the _surface_, 
and any contact geometry belongs to the colliding geometry. There are ways 
and ways to do it, at least to my minimalistical knowledge, {.. maybe others 
around the list can (or even want?) to enlighten us a bit more)


GJK- and other convex hull based algorithms use the concept of 
closest-features distance tracking (where features are points, edges and 
triangles), but these algorithms requires objects to be split into a convex 
hull, and its horribly inefficient for deformable geometry.

Note that with a GJK-like algorithm, even when a interpenetration occurs, 
you can enforce the non-interpenetration constraints with phisically correct 
forces at the contact and grinding them into the LCP solver (this is handled 
different in the David's iterative approach, isnt it?). But without the 
penetration depth, you dont have a trustworthy measure of how much force i 
need to push in order to remove the overlap condition or at least keep the 
resting contact at the boundary.


Ok, now that i've talked all this jiggerish, now i wave my own way of
dealing with this problem, so knowledable ppl can give me a hint :)


im also trying to do with own collision stuff (im doing it since i need to 
include deformable stuff in the picture). The concept here is that
since i cant rely on a GJK-like algo to get penetration depth, i _suspect_ 
that i can get a good deal getting instead, the exact _time-of-contact_(tm), 
that is, the exact time between frame A and B, in which features first 
overlapped.


At first sight, this approach looks really nice since then i can do a
iterative-like loop inside each timestep and apply impulses at the contacts 
(which would depend only on the velocities,coordinates of the
objects and their contact point) at the correct time. This is, a nice O(n) 
algo with exact response. However, im afraid that good' ol' box stacking can 
be really hard on the performance.

Note that i expect that this system be usable just as a realtime framework, 
also as a physically-correct MD-simulation-quality collision module, but i 
have my doubts about the performance on the compact aggregation regime, ....
any thoughts? pros or cons? jokes?


Greetings,

-CharlLls


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963