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

Performance Questions - Number of bodies etc.

Topics: Developer Forum
May 24, 2011 at 3:10 AM

In one of my other side projects I am experimenting with large numbers of tiles.

I have a few questions I can't really see answers for on the forums or in the documentation.

1. If I have a large number of static bodies would I make them share the same body but with multiple fixtures? If so how far do you go with that, at some point do you need to divide into more bodies?

2. Would you then add and remove fixtures based on whether they are currently on screen?

3. Or is it better to have lots of bodies and then disable/enable them when needed?

Any help is much appreciated.

Jun 15, 2011 at 6:39 AM

I've run into this same problem with the game I have been working on.

I can't answer 1 or 3, because I am mostly familiar with Farseer 2.x (which did not have sleeping bodies or fixtures) and only recently upgraded to 3.2.

As for two, this method works fine for me. Unfortunately, there is no copy constructor for a new Body, meaning you have to call BodyFactory every time you want to create a new body. It seems like enabling/disabling might be more efficient. There was a copy constructor for Body in 2.x, but it was removed in 3.x.

Outside of your question, though, there is a crippling problem with continuous rectangular bodies. The collision detection, although awesome, can fail at the intersection of two bodies. So, if you have a square or circular "player" body that moves along these tiles, they may occasionally fall through and nick the edge of an oncoming rectangle, causing the body hop a little bit as it is forced out of the body it was suddenly inside of. This causes problems when you want to let a body "jump" or when a body speeds towards a cliff of tiles.

I was hoping this was fixed in 3.2, but it looks like it is still around =( The effect is decreased if you increase the world.Step() sensitivity, but I can't find a real workaround.

Jun 17, 2011 at 9:24 PM

I've done a little more testing, and I can answer question 3 you had now.

Creating a body using the BodyFactory is more processor-intensive than simply re-enabling a body. However, the simulator (for me) seemed to get bogged down after about 2000 bodies were in the simulator at one time, even if most of them were asleep.

In other words, if you have a small number of bodies (< ~300) in the simulator max, then sleeping/waking up bodies is more efficient than creating and destroying bodies. Otherwise, destroying/creating bodies seems to be more efficient.

My machine is mediocre, so results may vary.

Jun 17, 2011 at 9:27 PM

EricCosky has added some optimizations to sleeping bodies in later changesets. If you need a lot of bodies sleeping ,you might want to take a look at it.

Jun 23, 2011 at 6:56 AM

I'm also running into performance problems when I reach about 800-900 active bodies in the simulation.  In my game I've got a bunch of bullets flying around.  (The bullets are not using CCD.)

I've done some performance analysis and the bulk of the time is being spend in the solver.  Has anyone managed to find ways to improve the engine so it can handle upwards of 2000 bodies?

Mar 8, 2014 at 7:08 PM
Edited May 6, 2014 at 3:44 PM