Bodies with large number of fixtures

Topics: Developer Forum
Jul 8, 2013 at 7:32 AM

I'm hacking away on a simple little game. More info at address below to get a sense of the mechanics.

My problem is that I need a lot of fixtures at the moment and when you reach > 150 fixtures the CreateCompoundPolygon breaks down performance wise. From what I see there is no possibility to create the fixtures on another thread since the CreateCompoundPolygon calls methods in the World object. NOTE I'm not well versed in the inner workings of Farseer.

The reason that I need so many fixtures is that each block in the objects are editable and it was a simple solution to create each block as a fixture.

My options so far

1) Somehow improve performance to be able to add larger structures. Perhaps by trying to create whatever data structure needed on another thread.

2) Try to combine multiple bodies with < 100 fixtures and arrange them as one object. This will probably be a very hacky solution.

3) Realize the fact that the large number of fixture approach isn't working and redo the core mechanics of the game. Perhaps with a custom build physics engine that will work for what I need. I really don't want to do that but it might be the only way. My physics is kinda simple since its no gravity and simple floating-in-space objects. :)

// Johan
Jul 16, 2013 at 3:06 AM
This might be due to the broadphase, and the systematic adding of fixtures. The DynamicTree that is currently implemented, has a worst-case that is basically what you are doing. This has been improved in FPE 3.5 with a small fix, which you could backport if needed.
Dec 6, 2013 at 4:37 PM
I'm working with a very similar problem myself. My game has spaceships that the player builds from modules, and a performance target would be to allow at least few 200+ module ships, or a couple of dozen smaller ones battling at a time. I probably won't need full ship to ship collisions, but having reliable collision code for projectiles and laserbeams is why I'm using this fully featured physics engine.

My ideas for getting the performance required are:
  1. Use only a single body per ship. The module structure is considered rigid, so none of the fancier stuff such as (breakable, swiveling) joints between modules.
  2. The ships can only collide with other bodies at the edges, so only the edge modules need to have fixtures.
    -When modules are destroyed, new fixtures need to be added.
    -Penetrating shots etc. can be handled by transforming the projectile position to ship's coordinates and consulting a 2D array of all modules.
  3. Most modules have a very simple rectangle fixture - These can be merged to form larger rectangular fixtures if needed.
  4. A concave polygon of the ship's outline could be generated and then decomposited for fixtures with the tools provided by FarseerPhysics. The outline generation can be quite difficult, though.
All of these have the downside that the ship's mass, center of mass and inertia need to be calculated and updated manually. The fixtures also need to be updated when the shape of the ship changes, which can be quite expensive operation. Currently I'm working on ideas 1-3. Number 4 can be quite difficult to implement as I don't want to restrict the possible shapes of modules to rectangles only.
Dec 9, 2013 at 12:31 PM
In my recent tests with up to 2000 fixtures on about 100 dynamic bodies, that don't collide with each other, the cost of updating the fixture AABB's and positions becomes the limiting factor. In a setup where I have 77 bodies awake but not colliding and a total of 1721 fixtures, Fixture.Synchronize() takes 83%, and Fixture.ComputeAABB alone takes 68% of the whole FPE.Step() execution time. All fixtures are very simple polygons, at least 90% being rectangles, and the rest are triangles. I'm still running version 3.3.1, would the 3.5 be any faster in this case?

That got me thinking about using a single bounding-box type sensor fixture for each body (ship), and only updating the positions of the numerous real fixtures for that body only when needed. Basically it would be broadphase checking, but at the body level. Would this give an overall performance benefit, or does the engine do something similar already?