I am currently writing a little game, but have run into some performance slowdowns, if I start creating a lot of objects.

So I made the decision, that bullets and other similar objects shouldn't be able to collide with each other, to save performance.So I implemented a BroadphaseFilter which immidiately discards all objects which are both bullets. It increased my performance a lot, but it is still pretty slow. So I thought about the optimisation of putting all "bullet-like" objects in one lists, and all "normal" objects in another. So I just have to test the (normally pretty small) list of normal objects with each other, and then just the "bullets" with the normal objects.

I looked through the documentation, but haven't found anything regarding this technique. Before I reinvent the wheel I just wanted to ask, if this already possible, or if I should implement it myself, and maybe share it with you, if it turns out okay and gives the expected performance boost for such situations?

Skypr wrote:So I made the decision, that bullets and other similar objects shouldn't be able to collide with each other, to save performance.So I implemented a BroadphaseFilter which immidiately discards all objects which are both bullets. It increased my performance a lot, but it is still pretty slow.

Did you extend the DetectBroadphaseFilter class or just implement the BroadphaseFilter interface? Make sure to do the former to ensure the default filtering is included.

Have you tried using the CategoryFilter class? This should at least avoid subclassing/implementing a BroadphaseFilter (the default broadphase filter checks the fixture filters) given what you are trying to do.

Skypr wrote:So I thought about the optimisation of putting all "bullet-like" objects in one lists, and all "normal" objects in another. So I just have to test the (normally pretty small) list of normal objects with each other, and then just the "bullets" with the normal objects.

I looked through the documentation, but haven't found anything regarding this technique. Before I reinvent the wheel I just wanted to ask, if this already possible, or if I should implement it myself, and maybe share it with you, if it turns out okay and gives the expected performance boost for such situations?

No, there's no facility to break these into different lists. Sure, let me know what you end up doing and I'll consider it for inclusion.

I would like to know how many bodies/fixtures you are working with (and what shape types) that cause the slow down. 100, 500, 1000, or? It might be worth it to explain what your simulation is doing so that other suggestions could be made. I've had simulations running fine with 600 bodies.