This project has moved and is read-only. For the latest updates, please go here.

Contact normals direction fix?

Topics: Developer Forum, User Forum
Apr 13, 2009 at 7:05 PM
I hate to make a new topic for this, but I was wondering if the Contact normal direction bug was ever looked into or maybe even fixed in SVN?

The problem is described in these two threads:

Basically the problem seems to be related to the creation order of Geometries in Farseer. Sometimes a Contact normal will point in one direction, and sometimes it will point in the exact opposite direction. This bug can be replicated by following the instructions by yobiv in the first thread. In particular, reversing the load order of the two rectangles inverts the normals.

Contact normals can be especially useful in figuring out where one Geom is relative to another Geom that has contacted with. For example, this method is mostly accurate for determining if the player is standing on a "ground" or standing on top of another object in a platformer. It can also be used to determine things like if an object has fallen on top of another one (like a rock falling on top of a player, for example). This appears to be one of the most straightforward approaches to doing these kind of collision checks, therefore it would be nice if this little bug was fixed.

In the meantime, some alternatives are:
- Checking the position of one Geom relative to the other. But this often involves testing the type of object associated with each Geom, which can be a hassle if you only want it to handle certain types of objects. It can also be unreliable if not implemented properly (checking relative positions isn't always enough).
- Checking the contact points of the collision and comparing it to the positions of the objects associated with each Geom. This method is seen in 3rd post here. But sometimes this check fails because the Contact position isn't always located at the exact border of a body (i.e. the check for "contact.Position.Y - player.v2Origin.Y == player.body.Position.Y" does not always work in my own testing - sometimes the two positions are off by some small fraction less than 1).
Apr 13, 2009 at 7:52 PM
I've emailed Jeff about this and hopefully I will get an answer soon.

It might be a problem of multiple levels. When two geometries are colliding, an arbiter is created. Inside the arbiter, the geometries are ordered by their Id (First created geom gets id = 0, second id = 1 and so on).
This means that when the arbiter needs to test for collision (with the narrow phase) the order it checks the collision in, depends on the creation order of the geometries.

I hope that Jeff is able to come up with a solution. I will copy this thread to a bug report and give more information when it is available.
Apr 13, 2009 at 7:53 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.