Collisions in 3.5


I'm curious how collisions (and possibly restitution) have changed in Farseer Physics 3.5. I tried switching to 3.5 in my XNA project (upgrading from an unmodified 3.3.1), and the collision physics feel subtly but significantly different to me.

Here's my basic scenario: I have a ball that bounces around a room. There is no gravity in the room. The ball is created with BodyFactory.CreateCircle, its restitution is 0, and its density is 0. The room also has a bunch of walls and rectangular blocks. They're created with BodyFactory.CreateRectangle, their restitution is 1f, and their densities are 0.

With Farseer 3.3.1, if I give the ball a little push (set its velocity to, say, Vector2(5,5)), it will bounce around the room pretty much perpetually. Every time it hits a wall, it ricochets off. If it happens to hit a wall at a really low angle (pretty much parallel to the wall), it just "sticks" and slides along the wall instead of bouncing off. This is good, and the way I would expect things to work.

With Farseer 3.5, however, the ball sticks to the walls much more frequently, even when it collides at an angle that should clearly result in a "bounce". I'm not sure what causes this exactly, because the ball often bounces around appropriately for 5-10 collisions and works exactly as I would expect it to, but then suddenly it will just stop bouncing and stick to the wall.

My collision code and restitution settings are identical in both projects (3.3.1 vs 3.5), and they're really quite basic. Nothing crazy or fancy going on.

Has the collision code changed in some significant way in Farseer 3.5?




theremin wrote Oct 16, 2013 at 3:55 PM

Just want to respond to your most recent comment on this (in the forum thread):
The Box2D engine was never built to simulate realistic elastic conditions, and that is why your ball hits the wall and then slide along the edge. This is not a bug, it is just how the engine is designed. On a similar note, this also makes restitution unrealistic, as a restitution of 1 can actually make an object increase in speed, if it hits two objects at the same time (and creates 2 contacts).

I will take a look at your testcase tomorrow, but for now assume that this behavior is intentional.
Understood, but as noted, this doesn't really have anything to do with realism. The problem is that the collision angles are different between 3.3.1 and 3.5 using identical basic settings. A quick test of my sample code in 3.3.1 and 3.5 demonstrates the problem.

wrote Oct 18, 2013 at 12:36 AM

wrote Oct 18, 2013 at 1:35 AM

wrote Dec 10, 2013 at 6:59 AM

wrote Feb 22, 2014 at 7:55 AM

elasto wrote Feb 22, 2014 at 8:12 AM

I have the same issue with 3.5:

I drop a single 1m radius ball vertically from a decent height (say 10m), it bounces a couple of times (restitution=1 so it reaches the same height) then on the third bounce it might just stop dead for no reason.

theremin wrote Feb 25, 2014 at 3:19 PM

Just an FYI that there's a detailed forum post about this issue too here, with a simple test case to reproduce the issue and a video demonstrating the problem in action:

If you have a TestBed test case that also reproduces the problem, feel free to post it in that thread.

That said, my suggestion is just to stick with 3.3.1, because I don't think a solution will be forthcoming. (The Farseer developer hasn't responded to any messages in that thread in almost 5 months.) It's a shame, because if Farseer 3.5 had worked the same as 3.3.1 with more efficient mobile performance, I definitely would have been a paying customer/donor.

wrote Apr 29, 2014 at 5:19 PM

wrote Jul 12, 2014 at 7:36 AM

wrote Aug 5, 2014 at 11:43 PM

genbox wrote Aug 30, 2014 at 10:05 PM

I'm unable to reproduce this error. The code posted in the discussion on this problem does not result in an error on my platform. Have in mind that due to .NET optimizes differently on different platforms, floating point errors result in a different simulation on my computer, however, the ball has been bouncing for 20 min. without error.

genbox wrote Aug 30, 2014 at 10:06 PM


Please post a testbed testcase (use the testbed project) that shows the error you are having.

theremin wrote Sep 8, 2014 at 1:41 PM

@genbox: That's interesting. What is your platform? I'm testing on Windows 8 with XNA. Are you using something else?

Did you watch the video that I posted in that other thread? http://vimeo.com/74416243

You're saying that you don't see that behavior when you run my testbed project?

genbox wrote Sep 8, 2014 at 4:00 PM

@theremin: Windows 7 SP1 x64, Intel core i7-2600

I did watch the video, and my simulation is radically different, and never fails.
Could you please download the latest version of FPE from source control, add your test, set it to compile in Release mode and watch the test without debugger attached?

Note that the version in source control uses MonoGames as XNA is dead.

I did comb all the changes between FPE 3.5 and the older release, and I did not see anything that would result in the behavior you have. It might very well a platform depended change in floating point operations due to optimizations done by the compiler. If just I could get the simulation to reproduce the results you are seeing I could fix it.

Fetze wrote Nov 2, 2014 at 8:41 PM

Is there any news on this?

I'm currently using Farseer 3.3.1 in Duality and am considering to switch to 3.5 in the long run for performance and memory usage improvements. However, I'm also fearing to introduce new issues by upgrading, this issue being the most pressing one.

wrote Nov 2, 2014 at 8:45 PM