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

Farseer Physics Engine 2.1 released

Jun 11, 2009 at 2:22 AM
Edited Jun 11, 2009 at 2:27 AM

Farseer Physics Engine 2.1 has finally been released. We have a lot of changes in this release. Both large and small. See the list of changes on the release page.

I would personally like to thank everyone that contributed to FPE 2.1 - Thank you.
If you would like to be added to the Acknowledgments list, contact me with your username and name, and I will add you to the list.

I would also like to thank our testers. We had a open-test discussion here where you can see what our testers found and what was fixed. Thanks to all of you.
Be sure to let us know if you find any bugs or the like. Any thoughts are appreciated.

Update: Info about the next release of Farseer Physics Engine will come out as soon as the 2.1 version has been tested and potential bugs fixed. Stay tuned.

Jun 11, 2009 at 12:24 PM

Great news! I'll check it as soon as I arrive home. Great work and thanks!

Jun 11, 2009 at 2:51 PM

Music to my ears! I'll give some of the new features a go when I get a minute (or a few hundred) at the weekend. I do have one question though: the Downloads section advises that there is a new XNA water sample bundled with the release of 2.1 but I haven't been able to find this in either the Simple or Advanced samples. Seems to be the only one that's missing... any ideas?

Jun 11, 2009 at 3:04 PM

@cpt_pik3y: Thanks, I always forget something. :)

Jun 11, 2009 at 3:06 PM

No, thank you! I'm just glad to find I'm not going nuts in my grand old age! Sorry to cause more work... and thanks again for the update. :)

Jun 11, 2009 at 3:15 PM

@cpt_pik3y: Both the XNA and Silverlight water samples should be included now.

Jun 11, 2009 at 3:21 PM

Legend, cheers! :)

Jun 11, 2009 at 8:06 PM

Sweet! I can't wait to integrate this to Gum Drop tonight

Jun 11, 2009 at 9:00 PM

all right! i'll replace my source control copy just as soon as i can, reading the manual for now. Which reminds me: you might want to put a little more emphasis that you only use a single bar/ampersand for doing bitwise operations or nothing will happen. looks great otherwise!

Jun 12, 2009 at 3:20 AM

I've just fixed a bug that could cause weird collisions. If you experience this bug or just want to be on the safe side, re-download the updated 2.1 packages.
Thanks goes to mechaghost for reporting this bug.

Jun 12, 2009 at 6:17 AM

Thanks for genbox for the super speedy reply! :)

Jun 12, 2009 at 1:01 PM
Edited Jun 12, 2009 at 1:05 PM

very cool, thanks for the great work!

btw: there is no precompiled binaries downloads

Jun 12, 2009 at 1:41 PM
Edited Jun 12, 2009 at 4:31 PM

Hey genbox

I just thought I should point out that in the online documents it says

9.      Inactivity controller

Farseer Physics Engine 2.0 includes a new thing called an inactivity controller. This controller enables what's called "resting bodies". This means that if your game contains a lot of elements that do not move around a lot, you can get some performance by deactivating them for the time being.
 Inactivity controller does this for you. You only have to enable it in the physics simulator and set some basic settings. See the "Inactivity controller" chapter for more information.

Now this is all pretty good but it says to “See the Inactivity controller chapter for more information.” But I can’t seem to find such a chapter.

Not so much of a problem for some of us who know how to use it (most probably don’t use it) but I think it is a great way to speed up your game and sometimes make better looking physics (If tweaked correctly) and granted it could probably be a lot better I still think it is very good.

Also I was thinking of ways to make it better since I use it quite a lot.

I had 2 ideas (1 I have tried with some pretty good success in my scenario)

The first one which I have used before in a stacking game I’m making is to have each object store/calculate how many other objects it is on top of, then with this info I change the speed at which it falls asleep (about 10% per level) so that the more stacked the object the more encouraged it was to fall asleep. This actually worked much better than I thought it would and not only made the simulation look much better but also made the game run much faster. Basically before I enabled this bool which I called “EncorageSleep” when I had a 6-12 high stack or pyramid of boxes (with sleep values that were set quite low i.e. The objects had to be moving very slowly to sleep, I found that the sleeping would wave though the pyramid or stacks (bottem to top) and then the bottem ones would wake up again and then everything else would wake up and start falling a little making the whole thing look very bad and unstable (and the framerate jumped from 120 to 30 every 1 second (my sleep time)). When I enabled this “EncorageSleep” bool and gave the objects a 10-15% higher speed they could sleep with for every level high they were at, I was amazed because suddenly everything just started working amazingly, everything was super accurate with no sliding or jittering, the game ran really well, and to top it all off when I moved one of the boxes the rest did not start jittering or anything but just worked correctly.

Anyway the 2nd thing I had thought of which I haven’t tried but I think some guys at box2d have is to give objects a memory of what happened when they last awoke, and used that to tell them to sleep longer or ignore objects until they are closer. They also look like there sleeping kind of happens in groups of nearby objects reducing certain things that normally happen with using inactivity.

Anyway just thought I would give you my random 2 cents, I know you are really busy at the moment so just respond whenever you can.



Jun 12, 2009 at 3:39 PM

some things i noticed:

there is a Vertices.CreateSimpleRectangle but no GeomFactory.CreateSimpleRectangleGeom

GeomFactory.CreateSATPolygonGeom limits the number of Geoms. how about making it unlimited when omiting numberOfGeoms or setting it 0. just a small issue, but i think the parameter name would be more expressive if it is called maxGeoms.

Jun 12, 2009 at 10:45 PM
Edited Jun 12, 2009 at 10:48 PM

Thanks to both danthekilla and yobiv for the suggestions.

@danthekilla: The inactivity controller chapter is my fault. I simply forgot to write it before releasing 2.0. It seems like I'm alone on the project for the next couple of months, so I might not get around updating the manual because I'm buzy preparing for the next version.

As for your solution; good idea - it could improve stacking alot and I would like to see a quick demo of your results. However, it only applies to the case that you have horisontal stacking. The perfect inactivity controller is generic in the sense that it does not know about orientation, it only cares if the geom is moving or not. This should be implemented directly into the engine and bodies are per default at sleep, and only wake up when force / impulse is applied to them.

Right now we have a separate controller that have no way of hooking into the engine more than it already does. It can also give a lot of overhead when running the controller (noticable when you have a lot of disabled bodies or several active areas in your game). To combat this it would be better to use the broad phase algorithms instead of a O(n^2) complexity implementation. I am working on getting a good sleeping/resting bodies implementation working for the next release.

@yobiv: The Vertices.CreateSimpleRectangle() was added to support SAT a little better. It creates 4 vertices instead of the 16 vertices in Vertices.CreateRectangle(). SAT only need the vertices that makes up the shape (having more degrades performance) - Distance grid needs a lot more.

I will make sure that GeomFactory.CreateSimpleRectangleGeom() is added to the next release.

As for the numberOfGeoms - When you supply 15, it will try and separate the geometry into 15 geometries. This is needed for concave polygons. In the next release, I will focus on making it fully transparent to the user. It will detect a concave polygon and split it into a (approx) optimial number of geomtries.
Setting it to 0 to have unlimited geometries does not make sense to me. Can you elaborate a little on that?
maxGeoms does sound more logical. Thanks for the suggestion.

Jun 14, 2009 at 9:43 AM

if someone uses auto-divide he probably doesn't know or care what the polygon looks like and more probably doesn't know how many Geoms it will consist of after dividing. thus the polygon should be divided into a number of Geoms of whatever it takes to make the polygon perfectly convex. int.MaxValue or Polygon.NumberOfVertices would just do fine as there won't be more Geoms than vertices but having a inifinity option would be more conviened.

Jun 14, 2009 at 2:43 PM

I agree that it should not be up to the user. The auto-divide feature should be internal and automatic. But, for now we have to supply the choice to the user because we have two narrow phase algorithms and distance grid is still the default. If a user decides to use SAT, the manual and forums should be enough.

The modified earclip algorithm used does not triangulate. It can split into larger polygons than 3 vertices. If the user specify int.MaxValue as maxGeoms, they might get a suboptimimal number of geometries (A lot of geomtries = more overhead). This will be autocalculated in the next version, but now we will have to live with what we got.

Jun 15, 2009 at 1:22 PM

there's a bug in Vertices.CreateCapsule. the last vertex on every halfcircle is missing. to reproduce, add in any simple Demo.Draw():

            var capsuleBrush = new PolygonBrush( Vertices.CreateCapsule( 128, 32, 4, 32, 4 ), Color.Gold, Color.Black, 1, 0 );
            capsuleBrush.Load( ScreenManager.GraphicsDevice );
            capsuleBrush.Draw( new Vector2( 256, 256 ), 0 );


Jun 15, 2009 at 6:43 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.