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

Will Farseer ever have multithreading support?

Topics: Developer Forum, User Forum
May 24, 2011 at 11:47 PM
Edited May 24, 2011 at 11:49 PM

I'm currently working on getting Farseer to run in its own thread, the reason I'm doing this is that I'm finding there is a very significant performance boost from multithreading on WP7 (though it's barely noticable on PC/Silverlight). This is naturally resulting in bugs as I'm sometimes performing raycasts, creating and sometimes even deleting bodies, while Farseer is in the process of doing a step. However the performance benefits are simply too great for me to pass up which is why I'm trying to work around these issues. Currently looking into having a messaging system with the engine, for example if I want to performa raycast I send a message to the engine that I want to do a raycast, when the thread responsible for stepping the physics isn't updating the physics it will perform raycast operations and such it has accumiliated through the messages and send the result back to the class interested in the functions result.

This obviously has a few design issues and makes the code a bit more bloated than it needs to be...

I'm not saying Farseer must do physics in a seperate thread however the performance benefits of doing so is huge and in the case of a mobile platform it actually has noticable differences so much so I'm willing to re-write parts of my engine so that it can be more stable in a multithreaded scenario.

May 27, 2011 at 4:10 PM

I'am interested in using multiple threads too. 
How exacly have your setup your system and how much performance gain have you seen?

The idea of runing farseer step in parrallel with the update logic however doesn't sound right.

I have seen at one of my games that most time is spend inside EndDraw() where i believe GPU catch up
by rendering commands that were queued during draw().

I was thinking that I could start a thread to run farseer.step() at the end of Draw() and wait for it to finish at the start of update.
That way i could take advantace of the time spent inside EndDraw which i bellive is mostly GPU related.







Jun 1, 2011 at 2:33 AM

In my experience it's best to run Farseer entirely on it's own thread and maintain thread-safe state objects holding the position, rotation, velocity...  Run it on a timer to make it fixed step (best) or just run it as variable step (good for some situations). I even interpolated between the previous and current positions/rotations to achieve smooth motion even when Farseer was bogged down to 10 steps per second my rendering easily held 100+ fps. Note that using interpolation will introduce some artifacts, especially on fast moving objects, but will generally provide 10x smoother looking physics in harsh situations.

Jun 1, 2011 at 5:59 AM

That is an interesting system. Do you know, does that work on win phone 7 as well? I have a game called 7bomb which lags part way through and I think that added smoothing might help the players to keep functioning in choppier situations. Could you explain some more how you achieve this smoother motion? I am very interested.

Jun 1, 2011 at 9:53 AM
Edited Jun 1, 2011 at 9:54 AM

In the new version of farseer you are able to add/remove bodies and change properties like rotation/position etc while the farseer is inside Step(). 
Farseer will integrate those changes the next time step is called. This was done so you can change the world during a onCollision event or for similar situations.

I don't know how farseer will react if you run it in a different thread , and try to change the world  from another thread...
As i said before, making changes to the world while farseer is still runing doesn't make much sence. 
I would however run farseer in another thread if i could do something else non CPU related, like GPU related stuff.

In any case it's up to the programmer to sync the threads (that's allways the case). Farseer can't support all possible senarios.

A more relevant question is, whether farseer will support multiple cores. Right now my interest falls into WP7, 
and while many say that multiple CPU cores are too much for a phone, it seems that the smartphone market goes down that road anyway..
so, why not take advance of it.




Jun 1, 2011 at 10:58 PM

Currently there are no plans to support internal threading of the engine. The properties of the World/Body/Fixture are not thread-safe, they are just safe to change from inside the callbacks.

@oragamster: Interpolation is a very simple technique. I'm pretty sure this blog touches on this.

@nkast: To better answer your question about performance - here is a YouTube of one of my early implementations. Note that this was taken before a lot of optimizations to Farseer were made.

I totally agree with the fact that Farseer simply cannot support more then one scenario. We are just a bunch of part-time/hobby developers and can only provide so much time to the development of this engine. I personally am thinking about working on a brand new physics engine based on Jitter, but for 2D only. Sometime in the future (date not set) after I have a working prototype, I will start recruiting help.

Some features will be -

  • Speculative Contacts - for speed and continuous collision.
  • Full multi-threading support built-in - I.E.- thread-safe properties, assign how many cores (threads) to use.
  • A simple interface much like Jitter.

So feel free to start applying now, that would really boost my motivation ;)

Jun 3, 2011 at 7:54 PM

If threading is ever added to Farseer, I would highly recommend going with something that internally threads very specific operations and not a general purpose "make Farseer support multithread in all kinds of situations" goal. 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. Matt's thread-safe system to decouple physics state from rendering described above can smooth things out substantially, and specific threading optimizations can possibly help with the real bottlenecks without introducing lots of risk & complexity to things that aren't really part of the performance problem.