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

Concept suggestions needed - a lot of fixtures in a body

Topics: Developer Forum
Jan 9, 2013 at 9:57 AM
Edited Jan 9, 2013 at 10:00 AM


I'm playing around with Farseer to prototype a small game. Look at the following image.

I've got everything working from a functional view, but it's poorly implemented from my side.. :) Each box is a body with alot of fixtures. I understand that this is not the optimal way and that's why I'm looking for inspiration on how to do it another way. 

The problem (probably expected) that I'm having now is that the simulation runs fine for 20-30 seconds. But if pushing the bigger block (with maaany fixtures) it starts to lag. Not always, but often.

My requirements are

* Objects built by blocks by a given size. (today 1x1 in the farseer coordinate system)
* Each block must be destructable (hence the use of a fixture per block)
* The whole thing texturized (got that working so no problem, just a req)
* Somewhat realistic physics, that's why I choose farseer.

Thoughts from my side

* Disable inner fixtures to avoid collision detection (is that possible)
* What is causing the slow down? Are fixtures within the same body collision checked with each other? Can this be disabled? I'm having trouble profiling since VS2012 cannot load the pdf-file (probably something with metro, I'll set up a standard win version instead later on).

Sorry for the lengthy post, but I felt it was best to include as many details as possible.

// AnkMannen

Jan 9, 2013 at 6:34 PM

Multiple fixtures of a body are not checked for collisions against each other (it would not make sense anyway). That's why they are useful for making composite rigid objects. One detail from your description is that if your fixtures are 1x1 this is huge scale because it means one meter per one meter. So the big body becomes like a small ship. You should scale down your simulation by a considerable factor to improve stability.

Another thing you have to find a way to figure out what causes the slowdown. Perhaps the body has issues with the terrain. Check at least the internal debug panel for number of contacts etc.

You can "disable" the inner fixtures by setting their collision categories to collide with nothing and see if that helps.

Jan 9, 2013 at 6:46 PM
Edited Jan 10, 2013 at 3:43 PM

Thanks for your reply!

I managed to get the profiling working. I'll try to scale down and playing with the collision categories. Everything is stable if I don't go over 10x10 (100 fixtures) at the moment.

The hot path is  

FarseerPhysics.Dynamics.Fixture.Synchronize (52%)

with FarseerPhysics.Collision.AABB.Combine as the single most heavy operation @14%

It only appears when the larger structures are moving. Might it have something to do with moving data from one leaf to another in some kind of tree-like thingy and the data is spanning several leafs? (I almost have no idea what I'm saying here :) )


(I'll post my findings as edit in this post)


I scaled down and it's much more stable. It still doesn't like high speed impacts though, makes it stutter for a couple of seconds.


Running without a debugger attach made all the difference in the world. No stutter or any sign of FPS drop. CPU at 15% (25% max since quad core).


Large structures (>200 blocks) are made Kinematic, saving alot of calc Power. Even larger (>500) are made Static. Down at 5% CPU at gameplay. DebugView has to be turned off as well.

// AnkMannen