Just upgraded Farseer...Have edge question

Apr 25, 2011 at 12:46 AM

Hey guys,

Just as the topic states, I just upgraded my Farseer from 3.2 to 3.3.1.  Prior to upgrading, I didn't have any problems with edges.  Now that we have to include a body when creating or attaching edges, even though the edges are created in the proper place, the position of the edge relies on the body it's attached to.  How would I go about finding the edge's position apart from the body?

I'm trying to create one way collision checks and when I compare my object's position with the edge's position, it's no longer working like it used to.

Thanks in advance for your help!

Apr 25, 2011 at 12:52 AM

Nevermind..solved.  I just got the median between the two vector points I used for the edge.

Apr 28, 2011 at 5:56 AM

Actually...getting the mid-point of the edge wasn't the complete solution.  What I'm trying to do is re-create the one way collision functionality I had prior to the update.  If the edge is long enough, testing for midpoint positions between the edge and the object to determine if the object can pass through the edge can break.

So my initial problem still stands.  My problem is, the edge is intialized and drawn at the proper location I initialized it to but because I attached it to a global body who's position is at (0,0)...whenever I grab the fixture's position, it returns (0,0).  How can I test for the actual edge's position?  I know that sounds confusing but I could really use some help with this one.

Thanks!

Developer
Apr 29, 2011 at 2:24 PM

You're right.. it is all a bit confusing so I may misunderstand something here. That being said...

I suspect if your edges are long enough, they might start missing contacts because of precision issues. Maybe. Or, if your body is at 0,0 and the edges are very far from the origin there would be other precision issues. An easy thing to try is to place the non rotated body near the edge, probably any end point of the edge would do for a first try, and build the edge in local translation coordinates from there (ie just subtract the body position from each vertex in the vertex list). Generally, it's not a good idea to leave objects at the origin unless object-object interactions are converted to model space to avoid precision problems away from the origin. I think it messes with debug draw stuff too. Be sure to turn on all the debug draw stuff once in a while (copy from the Debug View XNA projects as needed) because being able to visualize the bounding boxes in particular is very helpful in pointing out some common setup problems.

By "grab the fixture position" I'm assuming you are grabbing Fixture.Body.Position btw.

As for the original goal of implementing one way collisions, I think the best way to do it is in an OnCollision callback tied to the fixture (possibly applied to all body fixtures via Body.OnCollision property). Within that callback you can evaluate the contact normal in the manifold and the model space velocity of the body that can conditionally pass through the other object and decide if the collision should be ignored. Note that if both objects have OnCollision callbacks you will be encountering a problem I recently discovered while doing my own stuff, so you will probably want to at least locally implement the solution I posted here to guarantee reliable OnCollision behavior.

Apr 29, 2011 at 3:23 PM
Edited Apr 29, 2011 at 3:24 PM

Thanks Eric!  I'll definitely give that a shot.  Yes, right now the body that is used to create the fixture is at the origin.  I'll definitely try to move that body closer to the edge.  I'll also double check to see that I don't have OnCollision calls for both body and fixture.  Yes, I was using Fixture.Body.Position property but like I said, that was always located at the origin.  Which could also be the reason why using the manifold normal could also return a 0 vector? 

In any case, I'll give this a try and hopefully it fixes my problems.  This is really the last major issue I have post upgrade.  Again, thanks!