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

Farseer Physics Engine 3.5 Features

Oct 28, 2012 at 1:00 AM
Edited Oct 28, 2012 at 1:10 AM

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.

Oct 28, 2012 at 1:19 PM

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.


Oct 28, 2012 at 1:29 PM

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.

Oct 28, 2012 at 5:49 PM

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.

Nov 2, 2012 at 5:07 AM

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)


Nov 2, 2012 at 6:42 AM

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 :  "Speculative contacts". 

Anyways thanks again for coordinating this stuff..


Nov 2, 2012 at 4:48 PM
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.

Nov 3, 2012 at 7:50 AM
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 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.

Nov 8, 2012 at 3:32 PM
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:

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.

Nov 9, 2012 at 12:59 AM

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.

Nov 25, 2012 at 4:01 AM

I was working on a 2D port of Jitter Physics. It's still very far from finished, but the basic framework is there!

Nov 25, 2012 at 10:54 PM
Edited Nov 25, 2012 at 10:54 PM

Good to see that you are still alive Matt :)

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

Nov 27, 2012 at 2:51 AM

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.

Nov 28, 2012 at 1:53 AM
Edited Nov 28, 2012 at 1:56 AM

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.

Nov 28, 2012 at 3:06 PM
Edited Nov 28, 2012 at 3:08 PM

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

Nov 29, 2012 at 1:40 AM

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!

Nov 29, 2012 at 2:22 AM

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.

Jan 28, 2013 at 5:33 PM

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

Jan 29, 2013 at 2:58 AM

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.

Jan 29, 2013 at 8:24 AM

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

Apr 19, 2013 at 7:23 PM
I completely support your decision, however, few things I have to mention.

Please keep in mind that most of the indie developers do not have steady income from the work they are doing.

If everything costs a lot in the beginning, things won't get done at all.

Let's take an example, If I want to start working with a .NET Monogame/XNA based game for Android now. I must pay about 300 bucks to get the Xamarin license first, then comes the needed frameworks.... It's an awfully steep step for many developers.

However, as you said, you'd keep the basic framework free, while charging for the advanced features. That would work if the basic framework is free and usable in commercial games. This will enable indie game developers to gain some leverage (read: cash) to pay for the commercial product which will again bring more value for the dev and you. (You scratch my back, I scratch your back...)

I for sure will pay for Farseer, it's only been like 2 weeks for me doing XNA based code with Farseer Physics. I have nothing commercial yet, but I am planning to do some. And btw, I have a long background as a developer and manager in non-gaming sw engineering world...

Good work!
May 13, 2013 at 2:22 AM
I like the idea of scalability with this engine. It's not uncommon for me to have 500+ bodies on the screen at one time. This includes NPC entities, player and map tiles (integrated with xTile). There is a very good chance that my game will be running with this many bodies regularly, so anything to reduce payloads is welcome with open arms!

FYI - I agree with those stating that a front up fee will be detrimental to development. After playing with the engine I'll happily pay to use the full version, but if there was a cost up front to just have a look... I would have kept walking and found something else.

Hopefully this feedback helps :D
Jul 9, 2013 at 9:04 PM
Any update on the ETA for 3.5 please?

Loving this engine and can't wait to get hold of the new version with all the improvements and SPH :)

On the commercialisation side I've no problem at all with paying for all your hard work. But maybe a licence type like Xamarin have done with Mono? Full access to everything in dev mode but if you want to publish anything big you have to get the pro licence.

Thanks again for an awesome product.
Jul 9, 2013 at 9:09 PM
I never got SPH to work as intended; it has been removed from the engine until further notice. I will probably try again when I have the resources and know-how necessary.

As for an ETA: I'm very close to a release, still need to fix a couple of bugs, tweaks and cleanup. It will be released towards the end of the month.
Jul 10, 2013 at 12:43 AM
Edited Jul 10, 2013 at 12:45 AM
I was trying SPH a while back and it really is a hard topic. I manage to get something like 20-30 particles on the phone ,after that it became very unstable. What I was trying to do was to put a sensor at each particle and let farseer give me a list of nearby particles but that didn't turn out well.

One of the implementations I saw was using a grid, -a 2D table-, and first thing with each run it put the particles on that grid.
Then it perform the calculations only between particles that are on the same or near cells. That way it scale better and kept the complexity low, which with the standard algorithm is of 2*n^2 or something.

With farseer the grid could be a hash table, or for performance reason just let the developer define the grid area.
Jul 10, 2013 at 8:44 PM
Thanks for the update Genbox.

Sad to hear about SPH, I had a couple of good ideas for using it. I wish I could help but that kind of maths makes stuff dribble out of my ears.

Great news on the closeness of the next release, can't wait to see the code.

Thanks again
Jul 26, 2013 at 4:39 PM
My plan was to be finished with the development now and start performance tweaking. However, there is more bugs and features than I anticipated. I've been working at it for a couple of days straight now, but I'm still not reached a stage where I can stop development.

Check the changelog for progress on the development.
Jul 31, 2013 at 5:09 PM
Ok, thanks Genbox.

Just out of interest will the upgrade to the new version be relatively painless or has a lot changed in terms of classes / naming?

Good luck with the bug hunt :)
Jul 31, 2013 at 7:54 PM
It will not be easy to upgrade. I've had to take out some features (fixed joints, quadtree) as well as reorder some method arguments of the same type, which will fail silently. Triangulation have also changed and it will break in an upgrade, as sanitation is no longer done by default. However, joints are probably going to cause the most problems due to local vs. world coordinates.
Aug 7, 2013 at 10:40 PM
To give an update to what has happened so far:
  • Better insertion performance in the broad phase - Done
  • Updated triangulation tools - Done
  • Convex hull on all polygons - Done
  • Better performance when creating bodies - Done
  • Full serialization of World and other objects - Done
  • Improvements to joints should should give better performance - Done
What is missing?
  • Smoothed Particle Hydrodynamics (SPH - means water particles)
  • Less garbage generation for mobile devices
  • Official support for Android and iPhones
The SPH won't be implemented this time, as it consumes too much of my time, and I'm unable to develop a good performance vs. stability implementation. At the current state, the engine is pretty much done in terms of features, and this is what I will be working on next:
  1. More comments and explanations in code
  2. MonoGame solution files (this will also take care of iPhone and Android support)
  3. Enable and test a large performance improvement patch submitted by EricCosky
You should expect the 3.5 release within the next 2 weeks.
Aug 8, 2013 at 6:54 AM
Sounds great! Really looking forward to it! Amazing work!
Aug 8, 2013 at 9:50 AM
That's pretty awesome!

MonoGame should be an easy switch. I was able to use DebugView right out of the box in MonoGame.
Aug 17, 2013 at 2:14 PM
Edited Aug 17, 2013 at 2:15 PM
I'm curious if there is an plan for commercial farseer plugin for unity3d?

Yes I know there exist now an free plugin for unity. But it doesn't looks like actively developed.
And there is an relative gap in 2d physics plugin for unity.

So probably new version of farseer could be good start for unity?

Aug 20, 2013 at 9:52 PM
There are no plans for that so far. Do the existing solutions not work?
Aug 21, 2013 at 4:44 AM
camel82106 wrote:
I'm curious if there is an plan for commercial farseer plugin for unity3d?

Yes I know there exist now an free plugin for unity. But it doesn't looks like actively developed.
And there is an relative gap in 2d physics plugin for unity.

So probably new version of farseer could be good start for unity?

Peter Chipmunk apparently supports unity now. Have you considered that? I know you have to pay for it, but it's a start at least.
Aug 21, 2013 at 6:10 AM
genbox wrote:
There are no plans for that so far. Do the existing solutions not work?
In fact existing solution FarseerUnity works nicely:

And I'm using it for prototyping. But I'm simple missing an feeling that I'm using something that is not dead. Not sure about further support of this plugin. For example if new version of farseer will be there.

This is why I'm considering all solutions. In the meantime I have found some rumours about box2d support in unity in next version.

I know about Chipmunk2d, and price is not an problem, but I'm still missing some information about it.
But I'll try to ask them. It's still very very new plugin for unity.
(and there is an disadvantage that I'm home in farseer so there is some learning curve for start)
Aug 29, 2013 at 8:09 AM
Dude, you released it? You must announce it!

How much work will it be to upgrade?

I'm kinda scared because I'm afraid it'll set me back quite a chunk of time. But the improvements look nice! (if you announce it on the forum, this question should go in the announcement thread instead)
Aug 29, 2013 at 2:07 PM
I did a quick announce on Facebook, but that is about it. The improvements are probably not worth upgrading for, since they are mainly focused on usability and stability.
Sure, a lot of bugs have been fixed, but if you experience no problems, save this version for your next project instead.
Aug 29, 2013 at 2:10 PM
Just a quick reminder: Be sure to submit any bugs you find, and rate the release :)
Aug 29, 2013 at 2:11 PM
I'll wait to upgrade - I will probably need the wheel joint. And I will, of course, report any bugs I find ;)
Aug 29, 2013 at 2:13 PM
The wheel joint is pretty nice. Unfortunately the whole joint system has been updated to be more cache coherent (in theory), which makes it a non-trivial job to back-port it. I appreciate the bug reports you have made so far, they helped a lot.
Sep 2, 2013 at 4:25 PM
Congrats on release...

I have just (about) completed my game engine and the physics part uses farseer 3.3. I was very excited specifically by:

•Better insertion performance in the broad phase
•Better performance when creating bodies
•Less garbage generation for mobile devices

You mention that back porting is tough...

I am keen for any performance boost... so my question is

Do you have any quantifiable benchmarks on what sort of performance improvements we get (i know woul dbe hardwarde / implementation dependent, but if its like 50% generally then im in)

secondly, although i've wrapped up all the current 3.3 join types in my engine interface, im not using them yet. If it's just a case of ripping out my joint code and recoding the new ones i can do that. But would you say the back port issues extend far outside of the joints?

I wont be able to look at the new code for a few days, so sorry about the questions i could answer myself with testing.
Sep 2, 2013 at 4:39 PM
psst... your donation link doesn't work again.
Sep 2, 2013 at 6:43 PM
The performance boost in the broad phase is around 1000x - I don't even need to measure it, I have a test in the Testbed (Tiles) that demo the issue, and what took seconds before, now takes around 50 ms or less.

I have not measured the garbage generated in the newest release, and only a few methods have been improved. FPE 3.3.1 already have very little garbage generation. I've also not measured the performance increase with the new joints, and it might even be a decrease in performance; we are talking ~1% if any.

If you just wrapped the joints, there should be a few to no issues upgrading to 3.5. A new joint have been introduced, otherwise all the joints (with the exception of MotorJoint I think) should have the same interface as before. Note that the fixed joints have been removed since they contained errors I was unable to find.

Thanks for pointing out the donations link was broken. I have fixed it.
Sep 2, 2013 at 7:50 PM
Cool, sounds like i'll be upgrading! Shame about the fixed joints, but no bother, as I guess you just need to add a static body at one end now.

Timed quite well (or bad, for me) with the release of SharpDX 3.50 also in the past week, looks like this weekend will involve the two api updates and bug fixing / refactoring.

Thanks again.
Sep 2, 2013 at 8:11 PM
Edited Sep 2, 2013 at 8:13 PM
I liked the fixed joints as well, but correctness comes over convenience. I do have plans for adding them again, but I hope to push the change to Box2D first, in which case everyone gets the convenience, and not just FPE users. I also hope to release version 3.5.1 at some point, that will have many performance improvements, unfortunately I found errors among the improvements, so they never made it to version 3.5.

Edit: They are actually included in 3.5, but just turned off. Advanced users, or people with severe performance issues can turn them on for a nice little boost, but I can't guarantee a stable simulation.
Sep 2, 2013 at 8:14 PM
By the way, feel free to post a link to your game engine if you like. Every and all projects that use Farseer Physics Engine are welcome here.
Sep 2, 2013 at 8:35 PM
Thanks, will do :)
Sep 3, 2013 at 9:07 AM

I'll definitly upgrade to 3.5 since I need some of the new features! Great work! And if you're interested, here's the link to the project I'm working on.

There is a lot more done than what shows in the video and I'll try to get a version out with 3.5 as soon as possible.

Keep up the good work!
Sep 3, 2013 at 4:20 PM
Edited Sep 3, 2013 at 5:36 PM
I was incorrect - the joint limits still work the same, but when moving from a fixed revolute joint to a non-fixed revolute joint with a static body, the static body comes second and the non-static body comes first. That's probably why the joint limits behaved counter-intuitively on fixed revolute joints?

Gaah, you changed how joint limits works. It took me forever to get them to work correctly before (probably because they were borked) and now I'll have to do it again. Hopefully it'll make more sense now, so it should be faster.

Otherwise, the migration was very pain free!
Sep 3, 2013 at 6:40 PM
Hello, thanks for the update. I have so many customizations in my branch I can't decide yet, and my systems are mostly already tuned so fixes might require me to retune.
but I have four questions maybe you know so I don't have to benchmark A vs B..

•Better insertion performance in the broad phase.

-Is there any improvement in moving existing Fixtures in the broad phase tree?
-For ray casts, Is there any improvement in the query times?

•Convex hull on all polygons.

-I get some slow framerates when piling over 40 of bullet objects, in the CCD. Any near phase or CCD improvements?

-And, are revolute joints more accurate ( less separation) with the same # of iterations.. For now I carefully tune the Mass ratios of the joined bodies ( more than 1:2 causes allot of separation, instability)

Sep 3, 2013 at 7:52 PM
I had some major performance issues on iOS/MonoGame, and updated FPE today to 3.5.
Wow, major difference in performance, it runs really smooth now!

Sep 3, 2013 at 8:17 PM
@dhallbauer: No and no are the answers to your first two questions. I have done very little performance work since the 3.3.1 release in that area.
CCD will always take up a lot of resources, and no changes have been done in that area in regards of performance.

Joints are the same when it comes to iterations. They are soft by design; a lower timestep, more joints, higher iterations or changes to the frequency (if the joint have it) all contribute to the stiffness of the joint. If you have many joints linked together, like in chains, bridges or the like, you would want to look at the rope joint to help with the stiffness.

@aheydeck: Good to hear it works out for you! Feel free to post your game here so we all can take a look at it.