Farseer Physics Engine 3.0 - Update

Aug 15, 2009 at 1:25 AM

Time for an update.

I've been working hard the last few days on getting the latest changes from the Box2D SVN source tree into our C# port. For those who have not been following the progress of 3.0, we are currently porting over Box2D SVN (bleeding edge) to C# and helping out Box2DX (A C# port of Box2D) at the same time.

We are a team of 4 (Paul, Matthew, Igor (From Box2DX) and me) that port over the code, but unfortunately the others have been a little busy, so I did the latest major upgrade myself. Here is a overview of what is new:

1. Dynamic tree broadphase collider

Box2D implemented a new broadphase collider that uses a dynamic tree algorithm. They have always used the SAP (Sweep and Prune) collider because it was mature, fast and stable. They finally upgraded to a new broad phase collider that is faster than the old one (in most cases - sometimes slower). There are no "magic" algorithms that can make everything super fast, it is a matter of developing an algorithm that fits the highest amount of users. (in terms of performance).

I really like the new broadphase since it makes the structure of the engine a lot simpler. There might be a lot of issues because it runs at a very low level (to get the most out of it) and thus not very fitting for C#. Thankfully I have the help of Igor and he will probably hook it up with a lot of unsafe code (unsafe = low level) to make sure it runs as fast as possible in C#.

2. The basics only

Another big update is that Erin (Box2D creator) decided to remove all user contributions from his engine. This is both a good and a bad thing. It is good because it simplifies the engine a lot and it means that we will get more updates since Erin has to update less code. The bad thing about this is that the workload was shifted to us - but then again, we can include only what we think should be included.

Will get a basic physics engine - just like we planned from the beginning - and then we can start to include all the features that makes a physics engine easy to use. (All the tools besides just simple collision detection)

3. More flexible

Flexibility is one of the goals in this engine. It means is that everything should be up to the users and if they don't like a certain feature, it should be possible to turn it off. After playing a lot with the source code I've identified certain areas where we can make it more flexible. Example: In the new engine you will be able to increase the performance at the cost of accuracy - more than normally.

Also, exception handling and other debug-related code will only run in debug mode. This will further increase the performance of the engine, but make it harder to debug once released.


I can tell you that the new engine is really nice once you get to know it. With the help of Matt, Paul and Igor I'm sure we will get a fast and accurate physics engine. I know everyone is asking one question in their head: "That's nice, when can we have it?". Unfortunately I can't answer this question right now, but I can tell you that we are close to have finished the initial port. (stage 1 out of 3 stages)
Once the next version of Box2D is out the door, we will be the very first to have an engine based on the release. Then stage 2 (features, tools, refactoring and API changes) and stage 3 (Optimizing the code, minimizing garbage) will start and hopefully our first release of 3.0 will become a reality.

Aug 15, 2009 at 3:15 AM

Very exciting! So is the new broadphase collider a quadtree implementation or something like that? I suspect this should provide the most benefit when objects are not evenly dispersed across the level.

Am I correct to assume that FP 3.0 cannot be seen as just an upgrade to FP 2, and thus would require a nontrivial amount of work to convert a game from one version to the other?

It's great to see the progress on this; it should be rewarding to have a shared codebase as well as documentation and learning resources with Box2D(X).

Aug 15, 2009 at 3:28 AM

Hey genbox I was just wondering what 3.0 being more flexible exactly meant.

I was wondering if I could request a feature or two.

1. I was wondering if it would be possible to disable the entire narrow phase, basically turning it from a physics engine to a fast collision detection engine.
2. Would it be possible to have point geoms or something that could be used for particles? I would imagine that there could be a lot of optimizations for these as they would be a lot simpler.
3. I believe that we already have point gravity's (are these controller based and have to iterate through all world objects or do they use the broad phase?) but I was wondering if we could get boxes with gravity so you can create gravity areas that could overlap.

Obviously these would come way after 3.0 but I was just wondering if I could suggest them and get an idea from you if they would be put in or not, or if they are things that are not wanted in farseer.

Anyway its really good to get an update every week or so, keep up the great work.

Aug 15, 2009 at 4:15 AM

I suppose if you don't want a narrow phase right now, you could implement your own narrow phase that does the minimum necessary, or implement your own broad phase that leaves no arbiters for the narrow phase to deal with. One of those implementations could even be included as part of the library if there is enough demand for it.

Yeah, the fact that the current GravityController does not use the broad phase collider makes me think it won't handle large particle systems as well as it could. I haven't tested its performance though and maybe I should...

Point types need to be handled a bit differently than geometries. For one, tunnelling is much more likely, so raycasting (against geometries, not other points) is probably necessary. I'm not sure what the engine could do to make this sort of thing more performant. It's certainly doable now, and I know soft body simulation has been done with Box2D in the past.

What do you mean by boxes with gravity? Do you mean you want different regions of your game to have different gravities? If that's the case, you should be able to set up some sensor geometries and use the OnCollision event to apply forces to objects in the area.

Aug 15, 2009 at 11:03 AM
"Different regions of your game to have different gravities? If that's the case, you should be able to set up some sensor geometries and use the OnCollision event to apply forces to objects in the area." Yes pritty much but if the object has say the left 20% of it in a field with inverse gravity then the oject would rotate clockwise and slow its decent. if you know what i mean. i dont know how i would do the rotation stuff with sensors i imagine i could get velocity working but yer. Sorry for the crappy post im doing it from my phone. thanks for the help thou.
Aug 15, 2009 at 2:42 PM

@Cowdozer: It is a simple tree that contains all the AABBs of the world - quadtree is a little more complex in that it partition the space into quads. The dynamic tree sorts the AABBs after cost and then insert them into the tree. It has very fast add and removal routines and stuff like raycasting into the tree is also very fast. It was implemented to get rid of some of the limitations of Box2D. One was the World AABB that limited the size of the active world, another was some internals like the pair manager. Getting rid of all that stuff made the engine a lot simpler and easier to work with.

In 3.0 we will try to maintain some API compatibility with 2.x. It should be possible to remove the old reference, insert the new and after a few adjustments it should work again.

It is very rewarding indeed. Box2D has a huge user base and a lot of advanced users. Any bugs that might sneak into the engine will automatically get fixed (unless we fix it first ;) ) and there is a lot of documentation on Box2D. We won't have API compatibility with Box2D, so a lot of tutorials and code related to Box2D will not work out of the box

@Danthekilla: All suggestions are welcome. The flexibility means that you can exchange implementations in the engine by setting some flags. One example is Time Of Impact algorithms that does some subroutines to make sure tunneling does not happen. You can turn off the TOI implementation in Box2D, but it still reaches into the implementation and it still has a "if (TOIenabled)" check. We will still have the same things, but we will provide a NOTOI flag that will compile the engine without TOI at all.

The benefits of this is lower memory usage, higher performance (minor) and higher flexibility. You can do this with stuff like sleeping bodies too.

1. The current collision callback system is different to what we provide. I'm not sure what implementation we go with yet, but I'll make sure that you can skip the whole narrow phase. (Return false in the OnBroadPhaseCollision event in FPE 2.x will skip the narrow phase).

2. We are actually moving away from good particle algorithms. Stuff like the dynamic tree is not optimal for particles. In my opinion, a Hgrid broadphase and a distance grid is the best implementation for a particle-based physics engine. Not to worry tho - all our implementations will be public in the sense that you can use all the parts of the engine separately. If you need a fast algorithm to check if a point is inside a geometry, you can just that exact algorithm from our engine in your code.

3. The current gravity controller was contributed by RCIX and since then updated by another user. It iterates all the geometries in a brute force manner, but since the code is low impact, that is ok. For now we concentrate on the engine itself and not the contributions or tools - I might take a look at implementing a broadphase-based gravity controller in the future if it is needed.

Sep 15, 2009 at 4:32 AM

Hay genbox,

Im making a tanks game where the terrain deforms to make craters... Got that working but need to update the vertices on the Geom.
This is how im updating it at the moment:

Vertices verts = TextureToVertices(terrainTexture);

I know that this isnt a good idea but thats all i could find.
It slows things down because it needs to calculate all vertices for the whole terrain again and not the area with the new crater :S

Possible to add something to do this sort of thing? Or is there something already? :/ (im sort of new to xna)

Sounds like your making some awesome updates, cant wait!


Sep 15, 2009 at 1:26 PM

A faster way might be to use the subtract method in the Vertices class. The Vertices class contains all sorts of tools for manipulating polygons.

Sep 18, 2009 at 4:39 PM

I just can't wait for 3.0 to be out :-)

BTW, I wanted to try Box2D a while ago, and the first thing I've noticed is that they use VERY small units, to be much more realistic than using pixels (which corresponded to using skyscrapers like size units IIRC). How do you plan to integrate those with Farseer? Will you auto-convert to pixels or will we need to rework every objects/poly in our games?

Also, while knowing that of course it's going to break a few things, do you expect a lot of work to port a game from Farseer 2.x to 3.0?


Sep 18, 2009 at 6:53 PM

Indeed. Box2D uses meters as the default value. Erin had his reasons for using meters instead of pixels. One of them was that a lot of the developers that use Box2D also use OpenGL or other graphics abstraction layers that also use meters. Meters are also more coherent to the math used compared to pixels.

We will most likely also use meters, but we will also have a ConvertUnits class that can convert meters to pixels (or close to it).

As for the porting: I hope to change the Box2DX code into good old Body/Geom separation. Erin switched to using Fixtures that uses a similar approach, so it should be possible. Anyway, I want to let you know that I will be working on backwards compatibility and I'll try to make sure the least amount of changes are needed to use the the FPE.