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

The state of 3.0

Topics: Developer Forum, Project Management Forum, User Forum
Jul 23, 2009 at 4:26 PM

Hey genbox i was just wondering if you could give us an update on how 3.0 is going.

I know its still quite a while away but i was just wondering what kind of stuff had been done, how it feels so far, if you have had any cool ideas for it or new features your thinking of etc...

Anyway keep up the great work.

Jul 23, 2009 at 7:16 PM
Edited Jul 23, 2009 at 7:18 PM

You are right, It has been a long time since I made a update summery of 3.0. So here goes:

The porting is currently paused. We ported over the latest C++ code from Box2D (revision 220) and we are just waiting for Erin Catto to update his source control with some new changes they have planned, before we can proceed.

They have some really big changes planned, and we will automatically get those changes in Farseer Physics Engine since they are better than the old version. Just to give an idea of what they have planned:

1. New broadphase collider

The broadphase collider Box2D has is a very efficient and optimized Sweep And Prune based algorithm. In fact it was too optimized in my opinion. I was in charge of porting over the broadphase and it took me several days to get it right. It is simply too complex and very large. Erin has now found a new broadphase collider that works with dynamic trees instead. It is supposed to be simpler, more efficient and can handle a higher number of geometries. The good thing is that he separated the implementation of the broadphase and the dynamictree algorithm in such a way that you will be able to use the dynamictree algorithm for other purposes in your game than the physics engine.

2. New CCD (Continuous Collision Detection) algorithm

The old algorithm used Conservative Advancement where you sweep the geometry along the path until it reaches something. That is all great, but it has some limitations and it is very CPU intensive. The new algorithm uses the radius of geometries (actually everything is based on radii in the new Box2D) so everything the CCD solver sees is radii. That is much simpler than CA, but it also has some limitations. We will have to wait and see what those are, but if they are too limiting, we will implement some other CCD algorithm.

3. Decoupled physics and collision system

They are working on something called Fixture. That is a system that takes in a physics object and a collision object and fix them together. This might sound a lot like Bodies and Geometries, and that is exactly what it is. Farseer Physics have had that system since the birth of the engine. We will wait to the fixture system is complete to see if it is better than bodies and geometries and use that instead if that is the case.


Now, that is the changes that is happening in Box2D, we of course have some changes too, but they are only ideas for the moment because we need to wait until the changes in Box2D are done before we can start.

Here is a list of the changes - but have in mind that they might change or be completely omitted from the implementation.

1. Multithreaded world

Being a physics engine we are bound by the power of the CPU. A faster CPU means more geometries. Problem is that CPUs does not get faster, they get more cores. This means that we need to implement a system that uses those cores in an efficient way.

Problem is that it is not an easy task, both because multi threading requires the data to be capable of being processed in parallel and then there is the problem of race conditions and the like. The good news is that physics engines by design can be parallelized in large parts of the engine and we plan to take advantage of that.

Matthew has done some tests with multi threading and he thinks there might be a great potential there. We will give it our best try, but time will tell if it is worth it.

2. More caching

One thing that we always look away from is caching. We always try to optimize for memory and CPU time, but nowadays it is simply better to optimize for CPU time only and use a lot more ram. We plan to find places where we can cache values that have been calculated already and reuse it instead of calculating it on new.

That being said, there are places where the gain is very little and places where caching actually will hurt performance, so don't expect too much, but we hope to get a good amount of caching implemented.

3. Optimization, optimization and more optimizations

We have targeted the Xbox360 as a platform for Farseer Physics Engine 3.0. Currently we only support the platform by having a few optimizations for Xbox360 and providing you with a project file.

In 3.0 we will make sure that performance on Xbox360 can compare to that of the PC. We will do that by making sure the JIT compiler and CLR on Xbox360 in general is satisfied. That means minimal garbage generation, less allocations (Example: caching can hurt Xbox360 while it improves performance on PC) of course use some of the many threads on Xbox360.

Another thing is that we will support a fixed point (contra floating point) version of the engine. Since many devices does not have a FPU (Floating Point Unit) and thus are slow at floating point operations, we will have the opportunity of calculating in fixed point, thus improving performance.

Another thing that a fixed point version does, is that it can improve determinability of the engine across platforms and versions. Try running a physics engine in release mode and debug mode (with debugger on) - You will get two different outcomes for the same simulation. This is because of optimizations to the floating point design. Floating point operations are also not the same on different platforms.

4. More tools

It is important to remember that we are a physics engine and we deal with physics and collision detection only. But it is also important for us to provide some tools that makes it easier to create games that uses a physics engine.

A good example is the texture-to-vertices tool that is included in the engine. It has nothing to do with the physics engine itself, but it is priceless to many people because it makes it possible for them to create a dynamic physics world without having to code everything themselves.

In 3.0 we will provide you with several different algorithms. Some triangulate, some decompose concave geometries to convex, some find convex hulls and others simply tells you the distance between two points using a bezier curve. We will put all those tools into a physics engine context and make use of them as good as we cal. Another good example is the Path Generator that Matthew built. He uses a range off tools to create dynamic chains, rope and even the tracks for the tank in the Advance Samples.


What I've presented here is only the "headlines". There is a lot of stuff that gets improved and a lot of new functionality. In the end, all we want to for you to get a better physics engine in all areas; performance, stability, accuracy, support and tools.

Edit: Updated the discussion name to reflect the content a little more.

Jul 27, 2009 at 1:15 PM

Thanks for the great update. It all looks good.
Did you get enough in the end for the 360?