Farseer Physics Engine 3.0 Update (February)

Feb 5, 2010 at 11:40 PM

Time for another update. In January we released a list of stuff to do, you can see the list here.

Box2D is very close to a release. I'm not sure how much longer Erin wants to have it inside the source control (to get the last bugs fixed), but it seems that he is finally satisfied with the new implementations - he has started to move around folders and do "project stuff", usually that means he is close to a release. Anyway, the Box2D.XNA team is working on updating their port to the newest revision of Box2D. Once they are done, I will port over the changes that we can use into FPE 3.0 and adapt the code to the FPE 3.0 structure.

Matthew has been working on the Path generator (now called Curve2D), he is currently optimizing the code, so that is probably close to done. He is also working on the new drawing code for the samples which is very much needed at the moment.

David has been working on the joints. He has created fixed versions of the joints, just like FPE 2.x had it. Fixed joints are easier to use and more intuitive, so I'm looking forward to see what he has come up with.

Feb 8, 2010 at 5:22 PM

Good news.

The Box2D.XNA team has updated their XNA port of Box2D to revision 55 (the latest). I'm going to update FPE 3.0 codebase with the new code on saturday. (it is a huge update - complete rewrite of CCD)

Hopefully that will be the last updates to Box2D source code and we can focus more on getting FPE 3.0 specific features done.

Feb 8, 2010 at 6:04 PM

Great news Ian!

I highly appreciate all the work you do here on farseer.

I also highly anticipate the release of the new version.

Keep up the great work! 

Feb 14, 2010 at 2:34 AM


I've updated FPE 3.0 with the latest update from the Box2D.XNA port. CCD (Continuous Collision Detection) has been overhauled and it looks (kinda) stable it its current state. There is also a new edgeshape test that shows the power of edgeshapes (it is created like a edgechain). I have to profile the new CCD implementation and see where I can optimize. There were a few places where I saw some allocations that the GC (Garbage Collector) is not going to be happy about.

David has committed his fixed joints to the official repository. He still needs to "fix" a joint and change some testbed samples, but it is looking very promising so far.

Next task for me is to clean the new updated code and optimize the CCD code. After that I will take a look at creating easy to use arches/curve shapes and make breakable bodies more intuitive.

Feb 14, 2010 at 3:39 AM

Hey Ian,

I've got a question about this new Farseer version.

From the looks of it, it appears that Farseer 3.0 will use SAT as the default (or possibly only) NarrowPhaseCollider.

I recently updated a project I'm working that uses the Farseer engine from 2.1.1 to 2.1.3 in order to try out this SAT

NarrowPhaseCollider, because NarrowPhaseCollision checks-- specifically Applying Impulses is my biggest problem.


Well, the SAT completely killed the framerate. The simulator view reveals that the NarrowPhase takes ~22-24 [units of time],

bringing it to maybe one fps =/.


My question is, what are your thoughts on the matter ?

Thank you!

Feb 14, 2010 at 12:08 PM

SAT's performance depends on the amount of edges it has to check. The more edges, the lower performance. So make sure that you have the necessary points to make up the polygon, but no more than that. - You must have no vertices along the edges like you need with the distance grid narrow phase collider.

In Farseer Physics Engine 3.0, the SAT implementation will be very fast. Both the narrow phase colliders have their positive and negative sides, but I hope that SAT is the right choice for the moment and that I can minimize the negative sides by providing tools that extend the flexibility of SAT (such as convex decomposition).

Feb 17, 2010 at 5:43 PM


David has made another update to the fixed joints. All the joints now have a fixed version and he is working on getting the GearJoint to work with fixed versions of the joints. The WebTest is a good example on how to use fixed joints - before a ground body was needed, now it can live without it. That makes it easier and more intuitive to use joints.

I've been working on optimizing the engine. I managed to squeeze a 14% performance increase (14% on Xbox360, 40% on PC) out of FPE 3.0 by optimizing the contact system. I will dig deeper into the engine and see where we can get even more.

Feb 18, 2010 at 12:40 AM

I'm getting pretty pumped for this release :-) . I've been getting excited over every little trick I learn in 2.1.3, and it sounds like 3.0 will be even better in both features(woot) and performance(double woot).

I'm willing to wait for a good thing, but is the estimated release date anytime soon?

Feb 18, 2010 at 2:30 AM

This is just a hobby and we still depend on upstream code (Box2D and bugfixes). I will not release FPE 3.0 if there still exist bugs in the code it is based on. So we don't have any planned release date. But after a whole day of work on the engine, I feel that we are getting close to a release.

That being said, I have another update:

I've worked with the collisionfiltering today and I decided to go with the same system we have in FPE 2.x. As something new, I'm brewing up a logic filtering system too that will make it easier to work with the tools and controllers in FPE 3.0.

I've fixed a couple of testbed samples. Only one fails: GearTest - but David is working on that.

Next step for me is to look at public API and breakable bodies. I'll get to that tomorrow.

Feb 19, 2010 at 5:51 PM


I've not had a lot of time to work on FPE 3.0. But I got some small but important changes into the latest release:

1. The API looks very much like FPE 2.x. I'm not sure if I want to lose more Box2D compatibility by changing the API, so it might stay where it is now or change a little bit more. The factories have not been implemented yet, but once they are, it should be as easy to work with FPE 3.0 as 2.x is.

One of the big changes is that we no longer use linked lists for the public API, we use ordinary lists instead. They are simpler to work with than doubly linked lists, but it comes at a small performance penalty. I'm prepared to loose 2% performance for a more user friendly engine.

2. Timings have been implemented into 3.0. Now you can see what part of the engine use the most time and optimize your game accordingly. I bet we will have a pretty debugview up in no time that displays those timings.

Next for me is still breakable bodies and cancel collision.

Feb 20, 2010 at 7:17 AM

Hey Genbox is there any/many sorted lists in farseer 3.X (im sure there were in 2.X) if there is you probably also know that they can be quite slow on the xbox 360 (and on pc if used frequently) would something like a Skip-List help boost performance? they can be upto 25 times faster on pc than a reguler sortedlist and almost 100 time faster on the xbox 360's cpu (because of the xbox's limited branch prediciton and 21 stage pipeline i have heard) anyway i just thought i would make you aware of them (i didn't know of them until recently)

Anyway great work with 3.0 so far, and i think having some box 2d compatabilty would be good.

Feb 20, 2010 at 2:33 PM

Lists are only used in the public API and none of them are sorted. The only place I remember seeing a sort is inside the broadphase, and that works on the array directly.

The lists are only iterated on each update and not modified, that should greatly minimize the overhead of the list compared to the doubly linked lists used before. I tested the pyramid sample on Xbox360 and before the update it ran at 42 ms, after the update it was 43 ms.

Feb 21, 2010 at 8:46 PM


While creating an easier way to make breakable bodies I also created the well known factories from FPE 2.x. Here is the code from before to create the ground:

Body ground = World.Add();
Vertices edge = PolygonTools.CreateEdge(new Vector2(-40.0f, 0.0f), new Vector2(40.0f, 0.0f));
PolygonShape shape = new PolygonShape(edge, 0);

Here is the same code using the factory:

FixtureFactory.CreateEdge(World, new Vector2(-40.0f, 0.0f), new Vector2(40.0f, 0.0f));

It looks a lot better to me. Remember that the factories are only there to simplify common tasks, no flexibility have been taken out of the engine. You can still do it the old way.

Mar 5, 2010 at 8:42 AM

Hi genbox,

Amazing update you're coming up with! Nice work.

I'm not sure whether you're still accepting requests, but there's been a motor patch for adding velocity control to Revolute joints circling around the forums for a while which would be very useful to consider adding for FPE 3.0. Basically, this allows you to set a desired speed and it automatically computes the AngularImpulse vectors required to keep it steady.

It's very useful for wheels and character locomotion schemes.

If you're still open for these type of requests I can submit you a patch for this.

Thanks for all the great work!


Mar 10, 2010 at 3:10 PM

Hi genbox,

I've read about fixed-point arithmetic in a previous post from you... is this a feature that is planned for FPE 3?

Keep up the good work!