Farseer Physics Engine 3.0

Jun 15, 2009 at 12:04 AM

We have just released Farseer Physics Engine 2.1 and we are now focusing on 3.0. We took the chance and started over - we now build our foundation on Box2DX witch is a C# port of the wide known Box2D physics engine. Box2DX is very different from Farseer Physics Engine, even though we use many of the same algorithms and have a similar design, it has a lot of new features.

We found ourselves implementing more and more code from the Box2DX project over to Farseer Physics Engine, so we simply switched roles and now start implementing Farseer Physics features into Box2DX instead. Hopefully we will get a good hybrid that takes the best of both engines.

Here is a list of features that we will gain from going in this direction:

1.       Optimized SAT and SAP

Box2D has an optimized SAT algorithm that for example can check multiple axes at once. Not only is the narrow phase very fast, it also has an optimized Sweep And Prune (SAP) broad phase collider that supports queries. Querying is used by the ray casting mechanism, but can also be used to make a quick proximity check of all geometries in the world.

2.       Real circles and specialized geometry shapes

You will have the possibility of creating real circles; this enabled realistic behavior of collisions between circles and polygons.  They split geometry shape structure also gives better performance.  Utilizing specially crafted algorithms for collisions between circle shapes and polygon shapes improves performance.

3.       World AABB

Box2D uses a world axis aligned bounding (AABB) box to check whether a geometry is inside the world or not.  Whenever a geometry in the world exits the world axis aligned bounding box it gets disabled.  This improves performance because it does not have to update the geometries that are no longer inside the world.

4.       Continuous collision detection

Using the conservative advancement algorithm and we can have continuous collision detection in Farseer Physics Engine 3.0.  This means that objects no longer inter-penetrate each other and the problem known as tunneling can be resolved simply by turning this feature on.  The algorithm is quite expensive and should only be enabled for geometries than need it (fast moving geometries).

5.       Fast ray casting

Ray casting is implemented directly into the broad phase collision detector, this means that you can ray cast into the world and get the first possible hit very quickly.

6.       Joint motors

Instead of applying force to the bodies attached by joints, you now have the possibility of applying force to the joint itself. Take revolute joint as an example: You tell the joint how much torque you would like to apply to the body attached by the revolute joint. It takes offset and other stuff into account automatically.

7.      Extensive sleeping bodies

Box2D has a great implementation of sleeping bodies. This improves performance a lot and you can have several 1000 geometries in your world and one time, as long as they are sleeping, they will not affect performance.

8.       Rich documentation and standard

Box2D is used by a lot of users (Farseer Physics Engine is based on Box2D Lite) and there is a lot of documentation; both in the form of manuals, wikis and forums. Most physics engines have some kind of component from Box2D, this provides us with the possibility of easily integrate features from other engines.

So what is the difference?

You might ask yourself: Why not use Box2D then? Is it just a rebranded version of Box2D?

Well, while the internal components are based on Box2D, all our tools and API is completely rewritten to be as easy to use as possible. Many new users find it hard to utilize physics engines, but with the clean and flexible API, it’s a lot easier to learn and use. Our huge collection of tools for manipulating polygons is also one of the main reasons to choose FPE over vanilla Box2D. You can convert texture data to polygons, union and subtract polygons collections and vary the details of the polygon form, by simplifying or adding points to the polygon.

Another key point is the targeted platform. We target the .NET 3.5 framework with focus on Silverlight, XNA and Xbox360. We will still provide a dependency-free class library version that can be used with Winforms, WPF, OpenGL, MDX and the like.

I've made quick list of features that we will implement in Farseer Physics Engine 3.0 from FPE 2.1:

1.    Factories

The easy to use factories is a consistent way of instantiating geometries, bodies and physic logic. It makes the engine more flexible and appealing to new users.

2.    Buoyancy controller and wave generator

We have extended our buoyancy controller to be of high quality. We also have a very flexible wave generator that we would like to keep. Both will be improved to be easier to use.

3.    Decoupled broad phase design

If Farseer Physis Engine you can easily create your own broad phase collider. In Box2D you are restricted to use the Sweep And Prune collider. Creating your own customized collider can greatly improve performance, so we decided to implement that in FPE 3.0.

4.    Path generator

The path generator makes it possible to make chains, rope and tracks. It is a great tool and something we want to keep in 3.0 and improve on.

5.    Vertices polygon manipulation tools

We have some great tools to manipulate polygons. Everything from calculating the area, centroid, moment of inertia to union and subtracting polygons. They will be optimized and implemented into the foundation of FPE 3.0.

6.    Application Programming Interface (API)

We think that Farseer Physics Engine has a nice, clean and intuitive API. We want our users to focus on getting things done instead of tweaking internal parameters. The engine should take care of itself and automatically adjust to different scenarios - while getting its directions from the user.

EDIT: Biggest post award...

Jun 15, 2009 at 12:08 AM

Oh, forgot to mention. In a test matthew made, I can have over 1000 geometries (all active) at 40 FPS. We hope to keep number while we implement all the new features. Looks promising so far.

Jun 15, 2009 at 10:30 AM

Very Interesting

I think you just blew my mind.

So this is really interesting
what was the 40 fps 1000 geom sim running on?
i assume not the 360 :(

Great work thou :)

Jun 15, 2009 at 11:43 AM

sounds tasty, looking forward to it :)

> i assume not the 360

the xbox would give a stable performance measure environment however. most PCs are distracted by background services.

Jun 15, 2009 at 8:16 PM

Nope, it is not the results from a Xbox360. I unfurtnatly don't have one. Matthew has tested it on Xbox360, he might be able to elaborate on that part.

The results I posted was from my workstation - It's a 8-Core Xeon 2,33 Ghz (2CPUS) with 6 Gb slooooow FB-Dimm ram. I also tested it on my Dell XPS1530 laptop and it had about the same results. (1-3 FPS lower tho).

By the way, I was under the impression that Xbox360s have different configurations? It might just be harddisk and accessories - I don't know.

Jun 15, 2009 at 9:55 PM

Hey everybody I have tested it on the 360 and I can have around 100 geoms all colliding while staying close to 60 fps. The sleeping system is very good and this allows for a huge amount of geoms so long as they are not all colliding at once.

Also as far as I know all Xbox360's have the same processor speed, ram, and graphics core, so frame rates should be really close if not exactly the same.

As a side note we will be closely watching the performance on the 360 and tirelessly trying to improve it's performance. I feel multithreading will play a huge part in this as XNA allows 4 hardware threads to be used by games. This would lead me to believe there is enough power in that Xbox to make a 300% improvment over single thread design. Also since 2D rendering uses almost no CPU time and most of our users will be creating 2D games so rendering power is definitly not an issue on the 360. Expect some serious work on performance on the 360.

Jun 16, 2009 at 3:58 AM
Edited Jun 16, 2009 at 12:47 PM

Am I seeing the wrong thing, or are their composite geometries still using geometry specific AABBs? For example their V shaped geometry in the demos appears to have two interlapping AABB in a V shape. While this might be useful for static geometry in levels, it seems unnecessary and inefficient for small moving objects.

Another question is whether the engine's stability is reliant on more iterations per frame than Farseer. I'm not sure what the "Velocity iters" and "position iters" actually represent, but the defaults appear to be quite high in the demo.

Also it mentions that CCD is on by default for static geometries. What does that mean (does it mean that all dynamic object to static object collisions are resolved using CCD?), and what are the performance implications of it? Can it be turned off?

And regarding CCD, how much of a performance hit does it actually make? In a past game I was able to fire around 60 physics enabled bullets per second (using pooling + no bullet-to-bullet collisions) with a maximum lifetime of about 2 and a half seconds without even a hickup of slowdown on the PC. I probably could have done a few more. If I were to enable CCD on all those bullets, would the simulator screech to a halt or just half my frame rate, or would I even notice a difference?

Edit (addition):

from matt:

As a side note we will be closely watching the performance on the 360 and tirelessly trying to improve it's performance. I feel multithreading will play a huge part in this as XNA allows 4 hardware threads to be used by games. This would lead me to believe there is enough power in that Xbox to make a 300% improvment over single thread design. Also since 2D rendering uses almost no CPU time and most of our users will be creating 2D games so rendering power is definitly not an issue on the 360. Expect some serious work on performance on the 360.

This is a sort of pie in the sky idea: One potential avenue we could take with Box2D base code is the automatic multithreading of the narrow phase collision and collision response solvers, using the island detection system already built into Box2D. The solver could automatically split the steps up by islands. If you had four islands in the simulator detected by the broad phase, in the narrow phase you could split each island up and give it a thread, up to four on XBOX 360 or however many cores you have on the PC, or up to a user specified maximum. Then each thread could work simultaneously to solve their islands.

Then you can tune it to use a threshold for island size before spliting into a thread, and balance multiple islands per thread so that each thread has a roughly even amount of work.

This would be very useful. I know for me drawing and game logic combined take less than 5% of the CPU time per frame and physics takes a good portion of the rest (putting the physics engine in its own thread doesn't help my performance by much), so I think if this were feasible it would give far better results than tying to roll your own multithreaded solution.

I've done some more testing and I have to say the inactivity detection system in Box2D is very good, other than objects staying active too long (which I'm sure is tuneable). I can't really judge relative performance in release mode though since none of the demos in either Farseer or Box2D really tax a PC's CPU. I'll have to see if I can whip up a good stress test on both Farseer and Box2D and do a performance shootout.

Jun 16, 2009 at 2:09 PM

Thats great that you guys are going for more 360 performance :)

about the multithreading thou, I love the idea but i would say to use only 3 threads (the 3 non default ones) leaving basicly all of the default one for ai, pathfinding, particle(big user), 2d rendering, and other things

this would let farseer run up to 3 times faster still and as a added bonus it would let the full reg thread be used for the game

i also think the 360 would be a good test platform because they are all the same

every one has the exact same cpu, same speed mem etc

Eather way this looks great :) :) :)

Jun 16, 2009 at 5:05 PM


I'm not sure what you mean by geometry specific AABBs. Box2D uses AABBs for all it's geometries just like Farseer. Box2D does also have OBB for all its polygon geometries.

Box2D uses sequential impulse (split impulses) just like Farseer. The accuracy of the calculations are based on iterations - the more iterations, the more accuracy. A high iteration count give a stable simulation. The default iterations is simply just a number picked for the engine that gives a stable simulation most of the time. I can imagine Erin has made some changes to his algorithms after Jeff implemented them into the old Farseer (pre 2.0) that would require a higher iteration count. The main focus for Erin is a stable and simple simulator - performance is not the main focus and thus you probably can lower the iteration count and still get a stable simulation.

As for the CCD. Yes, it uses CCD by default on all static<->dynamic collisions. This is to make sure that static shapes like walls don't have tunnel problems. It is simpler that way. It has a flag to turn off CCD all together, I have not yet tested the performance with and without CCD.

Matthew has been playing a bit with dynamic multithreading of the broad and narrow phase. He knows alot more about how it should be implemented as I have not looked into it yet. It would be great to see some performance tests on both Farseer and Box2D. I know that the algorithms in Box2D are way more optimized for special scenarios and that might make it a lot faster than Farseer.

Jun 16, 2009 at 10:58 PM

@JeroMiya: CCD seems to have no affect on performance when used with only static to dynamic collisions. Performance of CCD should only be an issue with lots of CCD bullets. About the iterations I don't see where there is more then Farseer? In the testbed I whipped up to get a baseline I started at 8 for velocity and 1 for position. On Windows I was able to take these all the way to 50 each and only loose 10 fps. I could also set them at 1 and 1 and still get a decent simulation. Please understand this is only some minor changes to Box2DX, we have done nothing to optimize or update this at all. As for CCD being a performance issue please don't ask for perfection and expect speed on the Xbox. Me and Ian are going to do our best to get the performance to the max. The engine will perform better then Farseer 2, in all cases. Don't think I am bitching, I love to hear ideas and any suggestions. I love it even more to see patches and code improvements and additions. This source is available to everyone and if you have a specifc need then write a test app to prove to me and Ian there is a problem. Then we'll fire up our brains and look for answers.

@dan: When I implement the multithreading it will have no limits on how many threads you want to give to the physics engine. This should make it very easy to tune the multithreading performance i.e.- if you have 4 threads available (Xbox360) and you give them all to the physics engine and the game is running slow because your AI needs more time then you will simply just tell the physics engine it can only use 3. It will be up to you the programmer of your game to make this call. I will make this next version completly thread safe i.e.- you will be able to render, modify, adjust the engine any time, any thread, any where.

@everybody: I know you all read all the posts anyway, right? Don't expect this to be ready for use a in game for some time. There are some major hurdles to cover and only me and Ian as the primary developers. Please offer to help. I bet I will be able to think of tons of stuff that needs to be done. Porting code is easy. Getting it to work right after porting can be hard. Both take a lot of time to accomplish.

Jun 16, 2009 at 11:17 PM

I agree with Matt. We also have to overcome the obstacle that Box2D is undergoing some major changes and all porting has haltet. We are not going to be source compatible with Box2D like jBox2D is - this means that once we have ported all the required code, we are going to change a lot of things to improve the existing design. First comes a major cleanup and then comes all the structural changes to make it multithreading friendly and generally user friendly.

It is a lot of work and it will take a lot of time. We hope to get the foundation done first and then look at a release. Don't expect too much for the first release tho :)

Jun 17, 2009 at 1:22 PM

I didn't mean to say I was expecting perfection - I was just excited about the new direction and had a lot of questions. After playing around with Box2D a bit I am totally on board with the conversion, especially since it won't be a straight port (I don't really like all the C++ isms in the original engine, so the API cleanup you're planning is much appreciated).

If there's something I could work on, let me know. I'm usually considered the "Code Nazi" by people I work with (in a good way!), so I can help with cleanup/refactoring if you have a general direction you'd like me to go.

Jul 7, 2009 at 3:59 AM


>When I implement the multithreading


You just got me very exited, I understand this may not be for some time but right now I can have ~1000 bodys with no slowdown in my game (haven't tried on the xBox360 yet) with multithreading the future of FarseerPhysics look bright. :)

Jul 7, 2009 at 6:09 AM

We hope to get multi-threading implemented in such a way that it scales over multiple CPU cores and at the same time is easy to use. Matthew has already done some tests, but we need to look into the threading overhead a little more. A game running at 60 FPS only have 16.666... ms to finish its game loop and that is not a lot when you have 6 ms overhead in threading. (Example number - ms can't be used as a unit since it will vary from machine to machine)

I've had a chance to look into the FPE 3.0 code a little more and our initial tests with 1000 bodies at 40 FPS can actually be improved a lot. I think we might even come close to 1000 bodies at 60 FPS (on my high end machine). The future sure looks bright for Farseer Physics, I hope to get a foundation working in the near future so that we can start to implement all our planned features.

Jul 7, 2009 at 7:34 AM

I downloaded a copy of FP 3 (build 59920), and it only displayed a grey screen with a couple of nubers in the top left. Am i missing something?

Jul 7, 2009 at 8:22 AM

The current FPE 3.0 is in no way usable. We have several experimental source trees in the source control and we are working heavily on one of them. The source control is highly unstable and is not guaranteed to even compile. I would recommend waiting until official announcement of a stable build.

Jul 11, 2009 at 4:59 AM

Ok cool, just wanted to take a look....

Aug 13, 2009 at 4:29 AM

Current FPE 3.0 is not able to use then... Can I use box2dx (c# port of box2d) as a replacement of FPE until the official announcement of a FPE 3.0 stable build?
(Is it easy to port my program with box2dx to use FPE 3.0 when it turn out to be a stable build?)

I tried to use FPE 2.1 but I need a CCD(Continuous Collision Detection) since I need a physics engine that has very elaborate collision system.

Sorry for my poor English. :D

Aug 13, 2009 at 3:12 PM

The builds of FPE 3.0 in our source tree is a actually the newest Box2DX. It works like this:

We port over Box2D SVN to C# using Box2DX code style. We are 4 guys working on this including ihar3D (the owner of Box2DX). Whenever we are done, we give the code to the Box2DX project and then we begin to implement all th features from FPE, optimize it and make it easy to use. So far we only have the newst Box2DX build in our source control.

Box2DX and FPE will not be compatible API wise. They will look much like each other since Box2D just implemented split up physics logic (we have had that for years), but the API will be different. The behavior of the two engines should be the same tho.

You could try and implement Box2DX. The latests stable version is from October 2008.