[ODE] contact points

[Lewis Foster]

I agree the points need to be more accurate, and in some cases i've managed
to improve them, edges for example. The situation you described still needs
sorting out so that edges can be collision points as well as vertices (on
face-face contact) but i don't think that will be too difficult.

I'm testing at the minute with this situation:

http://img.photobucket.com/albums/v699/doof205/collide.jpg

With the following contact details it really should work, but it fails and
they pass through each other:

plane:
0.60x
0.35y
-0.71z

g1 - lower box
g2 - upper box

According to the documentation if g1 (the lower box) was moved along the
axis (which points down and away from the upper box - correct) by the
distance (0.01 or something) then the objects should no longer be in
contact....sounds right to me, but it just falls through. Oddly enough if i
keep the situation the same, invert the normal and swop g1 and g2, it works
because it is able to move the upper box away from the lower box.

Its not an issue with where the points lie, or how many points there are.

In fact i've just changed it so that g1 is always the first convex passed to
the collider function and it still fails when the contact normal points
toward the box on the floor. I dont see how it can be an issue with the
callback function either, that just adds the contact joint to the two
objects and now the ordering g1 and g2 is the same every time i'm more
certain that there is no problem there.

I'm completely stumped on this, i really think its close and could test it
properly if the collision points would work with normals pointing in either
direction.

Oh well, i'll see if theres anything else i can try.

Thanks,

Lewis







On 4/21/07, Rodrigo Hernandez < kwizatz at aeongames.com> wrote:
>
>
> I still think we need to calculate contact points some other way, did
> you added some code regarding that?
> I have no idea what could be wrong and really my only lead is what I
> wrote about on the last email.
>
> Anyway, I am going to make some checks and experiments to see what can I
> come up with.
>
> Cheers!
>
>
> Lewis Foster wrote:
> > Sorry to bring this back up but I'm still struggling with this. Given
> > my situation of one box on top of another I have the following details
> > for one of the collision points:
> >
> > plane normal  - Pretty much vertically DOWN:
> >
> > -0.089130431 x
> > - 0.011053018 y
> > -0.99595863  z
> >
> > depth
> > 0.0040335180 - sounds correct
> >
> > g1 = lower box
> > g2 = upper box
> >
> > With this arrangement of g1 and g2 the normal is pointing down, and
> > thus into the lower box, g1...which is correct according to the
> > documentation. However the upper box just falls though the box....I
> > can't see where this could be failing.
> >
> > When the situation is like this it works:
> >
> > plane normal  - Pretty much vertically UP:
> >
> > 0 x
> > 0 y
> > 1 z (near as makes no difference on these)
> >
> > depth
> > 0.00017637298 - sounds correct
> >
> > g1 = upper box
> > g2 = lower box
> >
> > So basically the order of g1 and g2 has been swopped round when the
> > contact normal has swopped...however for the second case it works, for
> > the first case it doesn't....how can this be?
> >
> > This is using test_boxstack so im presuming the callback function is
> fine.
> >
> > I'm really stumped on this, any ideas would really be appreciated.
> >
> > Lewis
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ode.org/pipermail/ode/attachments/20070421/4783582f/attachment.htm