I'm using btGjkPairDetector's getClosestPoints to find the closest points/penetrating points between two btConvexHullShapes.
Much of the time the m_normalOnBInWorld vector is pointing in the opposite direction from what I'd suppose to be the correct one.
Are there any known bugs or obscure caveats that I should know about regarding this issue? It seems to occur when the m_distance member is very slightly less than 0.
I simply have a large, box-shaped btConvexHullShape B and a number of btConvexHullShapes in compound, resting on top of the former. I'd expect all the resulting m_normalOnBInWorld vectors to point straight up, but half of them point straight down instead. All the unexpected cases occur when m_distance < 0, but the converse isn't true.
Can it have something to do with margins? I'm using margins 0, will that affect GJK?
Reversed collision normals from getClosestPoints
-
Sunken
- Posts: 9
- Joined: Thu Oct 28, 2010 1:40 pm
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Reversed collision normals from getClosestPoints
Thanks for the report.
Can you provide a reproduction case?
Does it also happen with default margins? 0 margin is not supported. Still, a repro would be nice.
Can you provide a reproduction case?
Does it also happen with default margins? 0 margin is not supported. Still, a repro would be nice.
-
Sunken
- Posts: 9
- Joined: Thu Oct 28, 2010 1:40 pm
Re: Reversed collision normals from getClosestPoints
Thanks for replying.
It seems it was indeed to do with having 0 margins; at least, increasing them to 0.05 appears to have fixed my problem.
My application is rather convoluted and I'm afraid extracting a repro case from it will be too time-consuming for me at present (deadlines...). Anyway, since you're not supporting 0 margins I guess it's no big deal, and perhaps reproducing it will be as simple as dropping a polyhedron onto a (kinematic) box, dragging it around and checking the sign of the normal coming out of getClosestPoints. That's pretty much the situation I had anyway.
It seems it was indeed to do with having 0 margins; at least, increasing them to 0.05 appears to have fixed my problem.
My application is rather convoluted and I'm afraid extracting a repro case from it will be too time-consuming for me at present (deadlines...). Anyway, since you're not supporting 0 margins I guess it's no big deal, and perhaps reproducing it will be as simple as dropping a polyhedron onto a (kinematic) box, dragging it around and checking the sign of the normal coming out of getClosestPoints. That's pretty much the situation I had anyway.
-
Sunken
- Posts: 9
- Joined: Thu Oct 28, 2010 1:40 pm
Re: Reversed collision normals from getClosestPoints
The reason I was using margin 0 was because I wanted to use getVertex on my bodies to get their "real" vertex positions, i.e. the ones I'd put in originally.
I fixed this by calling setMargin(0) before calling getVertex, now, and then setting the margin back afterward. Apart from being wasteful computationally this also forced me to un-const a whole chain of symbols in my code. The things we do when we're in a hurry...
Anyway, it would be nice if there was a method to get the original vertices (I know the shrunken version is stored internally for efficiency, but a little computational cost is better than switching the margin back and forth.)
I fixed this by calling setMargin(0) before calling getVertex, now, and then setting the margin back afterward. Apart from being wasteful computationally this also forced me to un-const a whole chain of symbols in my code. The things we do when we're in a hurry...
Anyway, it would be nice if there was a method to get the original vertices (I know the shrunken version is stored internally for efficiency, but a little computational cost is better than switching the margin back and forth.)