Hi everyone! I'm not having any major problems with Box2D, rather I'm reaching out to see if anyone has any general advice or ideas on how to optimize my game and/or Box2D so that I can push the scale of it even farther than I already am.
In my game, players can build 2D space ships by placing modules onto a grid, in just about any shape, and they can get quite large. Every ship has a single body, and then the game generates a bunch of fixtures to match whatever shape the player has created. As a result, my game has what I imagine to be an unusually large number of fixtures relative to a fairly small number of bodies. Some bodies can have hundreds of fixtures attached. Here's an example of what I mean:
The pink lines are a debug layer indicating where all the fixtures got generated. The above ship has about 380 fixtures attached to a single body. Note that I'm already doing some amount of work to combine fixtures for adjacent modules into single larger fixtures, though that's limited somewhat by the facts that some modules need to be on different collision layers and that the fixture-combining algorithm only knows how to combine rectangular grid-aligned fixtures.
All in all, this is actually working okay... better than I would expect, even. But ideally I'd like to push the scale and complexity of ships even further than I already am, and so I'm trying to figure out ways that I can improve the performance of Box2D for my scenario, without reducing the geometric complexity of the ships. I have some ideas of my own that I'd appreciate getting feedback on, and if you have any of your own to add, that'd be great too!
Here are my possible ideas for optimizing Box2D for my scenario:
1. Most of the fixtures in my game are rectangles that are axis-aligned in their body's local coordinate system, but under the hood these rectangles are just regular Box2D polygons. Perhaps I can create a special axis-aligned rectangle shape that's cheaper to do collisions against than the standard polygons? (However, I think that most of the performance hit is during the broad phase and updating the dynamic tree, where I don't think a cheaper kind of shape would help.)
2. Those rectangular fixtures aren't just axis-aligned, they also always use whole-numbered coordinates, due to the fact that modules are placed on a grid. Perhaps there's some way to take advantage of that?
3. Improve the fixture-combining algorithm so that it can generate and combine non-rectangular fixtures. This may be computationally more expensive than I want (it needs to be fast enough that I can update fixtures in real-time as modules are destroyed), and given the requirement that polygons be convex, I'm not sure how much more of an improvement it would actually be.
4. Create some sort of new "meta-shape" or "compound-shape" that can itself contain arbitrary sub-shapes. The idea being that this meta-shape would only be 1 node in the dynamic tree, which would radically improve broad-phase performance. Of course, this would make the actual collision detection between meta-shapes far more complex and expensive, but possibly still worth it? Each meta-shape would probably need to have its own dynamic tree of sub-shapes. (I actually spent a few hours trying this approach, and got some basic stuff working, but ran into some issues figuring out how to generate a collision manifold from multiple sub-shape collisions, and even bigger problems trying to figure out a not-horribly-inefficient way to do TOI solving.)
5. In the dynamic tree, add a b2Body* pointer that will point to a body if all of the fixtures in that sub-tree are attached to that body. That way entire sub-trees can be culled if their contacts would be discarded anyway due to belonging to the same body.
Anyway, thanks for reading! Any thoughts or ideas would be greatly appreciated!
Here's the place to get help and discuss features. The focus is on the C++ version, but generic questions are welcome.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 3 guests