[ODE] Location of contact points

[Michael Lacher]

Charles James Leonardo Quarra Cappiello wrote:
> 
> 
> 
>> 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.
i think this is also true for other collisions (ie: sphere|sphere, ...)

> 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)
> 
Ok ... here comes the problem: onto which surface of the two do you put 
the contact point? In the ideal case this doesn't matter because the 
surfaces just touch, but we don't have an ideal case here. Let me add an 
example to clarify my problem (use monospaced font):

---   surfaces

-+-   corner vertex

1   1st calculated collision position
2   2nd calculated collision position
...

We assume we have two boxes which just collided at one corner (ideal case):

Fig 0

+---------+
|         |
|         |
+---------+-----------+
           |           |
           |           |
           +-----------+


In this case it is quite clear that we have only one contact point, 
located at the corner:

Fig 1

+---------+
|         |
|         |
+---------1-----------+
           |           |
           |           |
           +-----------+

The location is quite clear, the only thing i am not sure about in this 
case is the actual normal (i will come to this later).

Now lets take the case which will normally happen (not ideal):

Fig 2

+-----------+
|           |
|      +-----------+
|      |    |      |
+-----------+      |
        |           |
        +-----------+



Now, where do i put the collision points ? One possible solution is to 
treat this as it were the above case, in this case this would produce 
only 1 contact, which can have 3 positions:

Fig 3a                    Fig 3b                  Fig3c

+-----------+             +-----------+           +-----------+
|           |             |           |           |           |
|      1-----------+      |      +-----------+    |      +-----------+
|      |    |      |      |      |  1 |      |    |      |    |      |
+-----------+      |      +-----------+      |    +-----------1      |
        |           |             |           |           |           |
        +-----------+             +-----------+           +-----------+


the position of the contact in fig 3b would be exact the middle of the 
ones in 3a and 3c. The direction of the normal is again undefined, like 
in the example in fig 1 (again i will talk about that later).


Alternatively one could position the collision as follows:

Fig 4

+-----------+
|           |
|      +----1------+
|      |    |      |
+------2----+      |
        |           |
        +-----------+


In this case the contact is exactly on the surface of the two boxes, but 
  we suddenly have two contacts instead of one.


The reason why I am asking all this is, that two sphere colliders seem 
to behave like indicated in Fig 3b, while two box colliders seem to 
behave like in Fig 4. Now i am of course wondering which behavior is 
"better" since they are mutually exclusive.

About the normals

the normals are an even bigger problem sometime. In Fig 1 the normal is 
indefined since any plane which touches both boxes in the contact point 
and does not intersect the boxes itself otherwise seems correct. How 
does the normal in such a case affect the simulation ?

The contact points in Fig 3a to Fig 3c actually should use the same 
normal as the one in Fig 1, because it is actually the "same" case.

Normals get really tricky in Fig 4. Should I use the same normal for 
both contacts (the one from above ?) or rather two seperate ones ?
In the later case, should they be normal to the surface of one of the 
boxes (which one ?) and is it a problem, that they would then point to 
different directions ?

I am sorry if this sounds confusing, but I am rather confused :) I try 
to understand how the location and normal of the contacts influences the 
actual physics simulation, so that I can then judge myself which is the 
best case for my own collision library ...

> 
> 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?
> 
This is actually superior, but rather much more complex, than the 
current ode collision system. You will need to include the current 
rotation matrix and velocity vector for both objects into the 
calculation which increases complexity a lot. I decided against such an 
aproach since ODE cannot deal with the better time resolution anyway ...

I think there are physical simulation methods which take this into 
account and do not work on a step by step basis, but afaik they are 
numerically more complex and not as fast (but more stable).

Mucki