As you might have seen, FPE 3.5 is under development. I'm working weekends on trying to implement the latest feature requests and fixing bugs. Here is a list of changes that is going to be implemented in version 3.5:

• Better insertion performance in the broad phase
• Updated triangulation tools
• Convex hull on all polygons
• Better performance when creating bodies
• Full serialization of World and other objects
• Improvements to joints should should give better performance
• Smoothed Particle Hydrodynamics (SPH - means water particles)
• Less garbage generation for mobile devices
• Official support for Android and iPhones

I am considering converting the engine to a commercial product. See here for more details.

Hello, the feature list is good..   seems like a ton of work though.  

but  features I would pay for more are performance improvements  in collision detection and especially piling of bullets.

Possible use of parallel threading:  ( detect # cores, and divide up work)

Eirk Cosky suggested earlier "Making the solver spread island solving across threads for instance would be a reasonable thing and could help where the perf is needed most, but making the entire system thread-safe is almost certainly not worth the trouble."

Also I  was wondering, if X, and Y collision intervals can be separated into 2 threads.. ( one for X intervals and one for Y intervals)  , either in the broad phase or narrow phase , in polygon collision.  Just  An idea I had long ago looking into a physics engine. 

I am able to do ray casts from other threads, but Step is all one thread last i checked.   An so maybe even on a  2 core system, it might not be fully loaded.

And thanks for your work.  I've been through 4 engines and haven't looked further since I found this a few years back.

Thanks damian999 for the kind words.

I played around with multithreading in the engine about 2 years ago. I tried to multithread the broadphase, the velocity integration and a few other places - I got it to work reasonable stable, but it had become slower than before due to the overhead of threading.

One have to think of threading not like a performance improvement, but as a scalability improvement. That is, more work can be done in the same amount of time. I can't speed up a solver that takes less than a millisecond to run on 100 bodies, I can however make the engine capable of running 150 bodies in same time.

That being said, thanks for the suggestions and I will reconsider implementing multithreading again.

Thanks for considering it, my only real issue is that  piling is fast enough, but piling of even 50 or so bullets can bog , and i've got to use bullets.

My results on an N core are pretty much N x faster, silverlight 5,  when i divide up my particles which each use a ray..   so yea, come on xbox 720 with 16 cores  (rumour).  But i'm tasking  scaling up big jobs like you said,  1000 particle into 2 jobs of 500.  not cutting up small pieces.   And with a threadpool and simple Join at the end, no significant overhead.

i'm curious if Y intervals  and X ones can be done in parallel somewhere since they separate dimensions, but I admit i don't know the detail of the current phases implementation to know if this idea is relevant.  Even many phones have got 2 cores and decent GPU

On aside,  one  idea for your monetization on the other thread .. a flat license fee if the game is published for commercial use.  Even indies have to pay up front a few hundred bucks to put their thing in certain app stores or even for certain dev kits.  That way they can develop for free and see if they can use the code.

An then if they publish and  don't pay you and it looks like they haven't made even  $1000 you don't bother threatening to sue them since they probably don't have any $ left or food or shoes.

But if a Rovio or someone uses it they'd better pay you.  And companies with multiple employees tend to play by the rules.

Hey Genbox, you should have a look at how Bepu does its multithreading as it has a very small overhead from a programming standpoint and many of the techniques could be applyed to farseer fairly easy. The only issue I have with farseer is scalability once object counts get into the 200+ range, I think that multithreading (expesially on the 360 with its 3 slow cores) could greatly speed things up.

Bepu has managed to get nearly a 300% speedup in certain simulations on 3 threads (1 per core) on the 360, now while it would be harder to get the same perf improvements in farseer because you have 1 less axis to partition/split the work up with i do think that in certain simulations (ones with 3+ simulation islands) you could get a very nice speedup.

That feature list is very nice however, its strange to think that as good as farseer is it can still be made to be better. And with all the new platforms/apis/engines using C# farseers future is looking very bright indeed. (Monogame, Paradox Engine, Windows RT, sunburn, unity, xna, and all the platforms that these run on)

Hello again.  little more on your proposed 3.5 goodness.

You wrote:

*-Better insertion performance in the broad phase."    -that would be great if possible .. i have to keep allot of items ( particles especially ) out of the tree for this reason,  and the time to update  them  in the tree is costly as well.

one possible solution:

ODE allows multiple different sorting spaces to collide together..  such as a HashSpace ( faster to move or add, but slower to query), colliding with a Tree space,

Tree being  faster to query, but  slower to add or move inside).   Even multiple moving trees could be useful ( first bloadphase the  AABB of whole  tree , then do the inside of  the tree pairs if entire tree spaces might collide) 

And as others have said.. the Islands or Axis parallelism  might be just the easiest to do.,  i think folks might pay something for this version.

One other thing, but which may be way out of scope, is to consider this form of CCD :   http://jitter-physics.com/wordpress/:  "Speculative contacts". 

Anyways thanks again for coordinating this stuff..

Danthekilla wrote:

you should have a look at how Bepu does its multithreading

Thanks for the suggestion. I will take a look at their implementation.

Danthekilla wrote:

I think that multithreading (expesially on the 360 with its 3 slow cores) could greatly speed things up. 

I still have the Xbox that was donated to the project a while back. However, I no longer have a developer license for it. I'll contact Microsoft and see if they will donate a license to me so that I can test it on the 3 core Xbox 360.

Danthekilla wrote:

That feature list is very nice however, its strange to think that as good as farseer is it can still be made to be better.

Personally I think it has a very good core, but it needs some consistency and more stable tools. It is really hard to implement a picky algorithm that will have anything from 0 to millions of vertices as inputs in invalid formats. So I think there is a lot of improvements to be made on Farseer, but one step at the time :)

Danthekilla wrote:

And with all the new platforms/apis/engines using C# farseers future is looking very bright indeed. (Monogame, Paradox Engine, Windows RT, sunburn, unity, xna, and all the platforms that these run on)

That reminds me, are there any new physics engines on the .net platform since a year ago? I have not been following the developments in the field for nearly a year. Back then, it seemed that Farseer was the engine of choice, I hope to make that happen again.

Genbox wrote:

That reminds me, are there any new physics engines on the .net platform since a year ago? I have not been following the developments in the field for nearly a year. Back then, it seemed that Farseer was the engine of choice, I hope to make that happen again.

The only physics engines that are relevant these days for .net seem to be Farseer for 2D and Bepu or DigitalRune for 3D.

There are a few more in the 3D space that have come out in the last few years, like sunburns (which they have now dropped for Bepu) and like http://www.mataliphysics.com/ but so far it is still limited.

For 2D there is nothing better than Farseer :)

I have a XNA account if you ever need some things profiled/tested on xbox or a multicore windows phone 8 device.

Genbox wrote:
That reminds me, are there any new physics engines on the .net platform since a year ago? I have not been following the developments in the field for nearly a year. Back then, it seemed that Farseer was the engine of choice, I hope to make that happen again.

I'd say it's still the engine of choice if you're ok with managed .NET. My eye caught another promising 2d physics engine in development:

http://www.youtube.com/watch?v=X37pXHi5u-Y&list=PLCC033D0F8172A917&index=1&feature=plpp_video

http://www.chrisacoder.com/category/gemini-physics/

I'm not sure if it's still being actively developed, it's plan was to have c# bindings at first, and a port to native c# at a later time.

Considering that he only have the testbed, I would say that I have accomplished a lot with that small engine. I tried the testbed, and it seems to work fine, but as he says, it is really optimized for speed, and not accuracy. There is no CCD and the solver is really unrealistic (both due to the lack of friction, the tunneling and lack of restitution).

However, he has integrated it nicely and have really good performance. I would sure like to take a look into the engine and see if I could learn from it, and perhaps integrate some of the features into FPE, but unfortunately, he has only made the testbed available as a binary.

I was working on a 2D port of Jitter Physics. http://code.google.com/p/jitterphysics/source/browse/#svn%2Ftrunk%2FOther%2FJitter2D It's still very far from finished, but the basic framework is there!

Good to see that you are still alive Matt :)

What is your perspective on Jitter Physics; is there anything we can learn from?

Thx, Ian good to see your still working on Farseer!

Well mostly just multi-threading setup. It uses a job/task style and makes for easy handling of multiple cores/threads.

Also it uses Minkowski Portal Refinement as it's only narrow phase collision algorithm and it kicks ass! It gives you any convex shape you can think of and can find the collision point and normal extremely fast compared to SAT when dealing with larger sets of vertices.

I know Farseer isn't really setup for custom collision algorithms so a lot of this stuff probably won't or can't be added without modifying the engine dramatically. This is one of the reasons I took to porting Jitter to 2D. I'm also considering starting my own engine from scratch based on all I have learned from Farseer, Box2D and Jitter.

Thanks Matt!

It is good to see you still hang around the forums! You made some really awesome stuff for Farseer, so I am confident that you are able to cook up an awesome engine.

Oh, it uses MPR. I remember talking to the guy behind Blaze, and he mentioned MPR at some point. It was years ago, but I remember he made an implementation of the MPR for 2D shapes. I'll see if I can find it somewhere. If I remember correctly, I would get in trouble trying to implement it in Farseer, as it did not provide the distance between the convex polygons. I could abstract the implementation if needed, just like I did with the broad phase in Farseer.

As for the multithreading, I'm am 100% for trying to do it again, and if I can see some clever usage from Jitter, I might look into it before diving in. I have some pretty good ideas on how a small architecture can result in a large speedup on MP/MC systems, but it would only provide overhead on single processor/core systems - so I am not quite sure if it is worth it.

Edit: Found the MPR here.

Edit2: Wow, MPR is a lot simpler than I remember. I should definitely look into it.

Hello,   just sharing my results for threading particles using rays casts,  in parallel on  farseer

regarding threading overhead, in our code we use a thread pool and use Environment.ProcessorCount  to decide to use just one , two, or more threads,, if  Environment.ProcessorCount  is not multiplatform it could go in settings,  so no overhead would be incurred if set to 1 for a 1 core system.

We do not count a hyperthread as a core, since its has no separate floating point unit, and didn't show us any improvement on our tests.

 something like ThreadWorkItem[] arrayWorkItems = new ThreadWorkItem[Environment.ProcessorCount- 1];

this might not be relevant to the core stuff ( X / Y interval threading)   but to split bodies for particles we even found it was faster to do more threads than physical cores.  ( we break the particle set into N equal sets of particles where  N is # threads or work items) 

I'm guessing this is because some of the particle chunks take longer than others .. and  splitting out more threads gives the ones finishing easy chunks early the chance to go and help with the harder jobs still running, if the OS's scheduler is decent

Yes, MPR is really simple! It can be hard to implement a very robust and fast version though. There is a lot of edge cases to cover. Jitter has a very solid implementation and I recommend rewriting the code using full vectors and overloaded operators to get a better understanding of it. I still haven't found the time to get my 2D version working correctly. 

Be sure to check out Threading.cs and CollisionSystemBrute.cs from Jitter. In the Detect(bool multithread) method you can see a great implementation of how to add multithreading to the broadphase while only adding a single if statement of overhead.

Most of the methods used in Jitter will not easily fit Box2D's structure. A lot of abstraction has already been done, but a lot more would have to be done before this could work well. I have faith you can get it done though!

Also I am looking for good names for my new physics engine.

Currently I'm running with Sharp Physics. If anyone has any suggestions please message me directly, I don't want to clog up the Farseer forums.

What's the timeframe for the 3.5 release? I would gladly help out if you need someone to test it. I'm using the current version in my poc-game and I'm not really missing anything except being able to insert new objects faster than I'm able to do right now.

// AnkMannen

Not only can you insert objects faster into the world, but there is a general speedup of everything else as well. Commonly used methods have been optimized and they are generally doing their work a bit more clever, so I would expect all whom upgrade to 3.5 to have a faster simulation, less memory use and no garbage generation.

As for the expected release data; I'm unable to give a date at the moment. I'm working in the area of 60 hours each week besides FPE. I'm posting this at 4:00 AM, and as you can see from my commit log, I usually work on Farseer Physics at night instead of sleeping :). Doing what I can to get it finished within a reasonable time frame.

That being said, I am currently 1/3 done with the engine and tools, I have yet to work on the samples, but it seems that Elsch is having fun with that. (Thanks Elsch!)

When the engine and tools are finished, I need to build tests, do profiling and optimization. Usually that does not take much more than ~2 weeks.

I have no doubt that you are working with this as fast as you can and I'm impressed at the time you put into it. You should definitely create a commercial version of farseer.

I got most of my fixture creation issues sorted out last night. I just cannot create more than 100 fixtures at a time. For my game, that is a limitation. (see my other thread).

Keep up the good work.

// AnkMannen