[ODE] contact points
kwizatz at aeongames.com
Thu Apr 12 14:33:28 MST 2007
Are you using my code? if so, it needs to check for a edge-edge
collision, which I don't think is there.
About contact points, as the name suggests, these should be points on
which both geometries are in contact,
so, for example, if you have two cubes stacked one on top of the other,
and the one on top is rotated 45 degrees
on the z axis (z being UP) with respect to the other, none of the 8
points (4 per contacting face) would actually
be contact points, so you may have to calculate them instead. I believe
I made the mistake of
just taking them as contact points and thats probably why it all goes
You could calculate them by doing a boolean intersection between the 2
faces and then choosing at least 3 of the resulting points.
Lewis Foster wrote:
> Yes that's correct and in my case it works fine in the situation where
> the normal points in to the box that is in the air. What i found to
> cause a problem was when the normal pointed toward the box on the
> floor it was effectively adding contact points to the box on the floor
> which had no effect as it couldn't move.
> The obvious solution is to add contact points to BOTH geoms with an
> inverted normal on one, this seems to have fixed my problem although
> they're still acting somewhat erratically. Is this how it should be
> done, contacts on both geoms?
> David, good to hear some enthusiasm for it. I'm still not happy with
> the collision behaviour and i dare say the code is quite inefficient
> but i'll see where I can get with it. I'm going to test it with
> different convex objects and see how it behaves then i'll post the
> On 4/12/07, *David Walters* <hidden.asbestos at googlemail.com
> <mailto:hidden.asbestos at googlemail.com>> wrote:
> > I hope that makes sense. Any help would be greatly
> appreciated...I wonder if
> > i'll finish this before Erwin finishes the bullet
> integration...my work will
> > be obsolete otherwise.
> Don't forget that (as far as I'm aware) the initial plan for Bullet
> integration will not initially include interoperability with the
> existing collision code -- now I'm not saying Bullet won't be
> brilliant for all occasions - but there may be many reasons why people
> won't want to migrate to it. In fact I'm not sure it currently
> supports the plane primitive - so that makes a lot of the demos still
> quite dependent on what's already there ...
> What I'm trying to say is Good Luck! and whatever improvements you
> make, regardless if they're perfect, please consider submitting a
> patch because someone else could carry on the work even if you feel
> your contribution is 'obsolete' - it's not.
> David Walters
> ODE mailing list
> ODE at ode.org
More information about the ODE