I have very little experience with box2d, but basically it seems to me that it is possible to attach to it a sprite (that is, a bounding box enclosing the sprite itself) and let box2d to check for collisions.

Now, suppose that our animation is composed of N sprite (for example, a character walking) and that the sprites are not equal in terms of width and/or height of their minimal bounding box.

How do you do with box2d? Compute an average box to enclose the sprites or change the box width/height at every sprite change? The first method seems to fit well only those situations where the sprites bounding boxes are similar.

If that is not the case, the second way is surely the most precise, but I wonder if that is computationally heavy (I mean, to change the size of a box everytime we change the animation frame).

Any advice/ideas are welcome!

  • \$\begingroup\$ Your second idea is certainly right. Its a good practice to get accurate results in the simulation. It isn't heavy at all, you can do it several times per frame without harm, just don't overdo it. Even in the worst case, that you create a new body for it, its doable in realtime. Just have attention to one thing, changing the bodies in realtime like that can lead to some glitches, such as body overlap or possibly crossing of the shapes, but i really am not sure of this. \$\endgroup\$
    – Grimshaw
    Feb 14, 2012 at 0:28

2 Answers 2


It depends on the game. In most cases you'll be fine with just some simple shapes that average the sprite over all animation frames. Something as shown here (image from Ray Wenderlichs/Andreas Loews MonkeyJump tutorial) :

sprite collision shapes

You see that three circle shapes are good enough as average for this sprite (the two small circles left and right are just sensors to see at which side a collision happened).

If your sprites do extrem transformations from one stage of animation to another, or if you really need a high accuracy (think a beat-em-up, or some slow-motion close-up), then you should create separate bodies per frame (or animation phase). Then you add/remove the physics bodies at the appropriate time of your animation.

  • \$\begingroup\$ Ok, so a way to handle this situation right would be: start with frame 1, compute automatically or manually a shape for it and assign that shape to it; for the next frame IF their difference is small enough, don't do anything, otherwise remove body of frame 1, and use body of frame 2. But i wonder what happens with velocity/acceleration. How to 'transfer' it to the new body seamlessy? \$\endgroup\$
    – lukeluke
    Feb 14, 2012 at 9:33
  • \$\begingroup\$ @lukeluke Hmm that might pose a problem.. but it will generally be an issue, because the new shape might have another mass and behave differently in the physics simulation than the previous shape. \$\endgroup\$
    – bummzack
    Feb 14, 2012 at 10:14
  • \$\begingroup\$ bummzack, i never tried that so i can't say anything for sure. I would only change shape (fixtures and body would be the same). Otherwise how would you handle this? \$\endgroup\$
    – lukeluke
    Feb 14, 2012 at 10:32
  • \$\begingroup\$ I am a little confused, sorry. We have shapes (a polygon + mass) and bodies (the dynamical properties, like linear velocity and on). Given two frames i and i+1, what i would like to change, if necessary, is their shape (that is, the polygon enclosing it or whatever), since the frame i+1 could be too different (for example, the character is giving a kick) from the frame i to use the same bounding box. What confuses me about your answer is that you speak of changing bodies but not shapes...i would do the converse. Consider the fact that the frame i could be subject to external forces... \$\endgroup\$
    – lukeluke
    Feb 14, 2012 at 10:49
  • \$\begingroup\$ @lukeluke You can't remove/add shapes in Box2D without recreating the fixture. So the other option would be to destroy/recreate fixtures. Using something like this for a character-kick seems to be overkill though. Why not have a sensor (or separate shape) at the foot-position and check for collisions this way? \$\endgroup\$
    – bummzack
    Feb 14, 2012 at 12:39

If that is not the case, the second way is surely the most precise, but i wonder if that is computationally heavy (i mean, to change the size of a box everytime we change the animation frame).

Boxes in Box.2D are represented as polygons. You can easily alter the size by getting the Fixture of the Body and then the Shape of the Fixture. The PolygonShape has a property that lets you access of the polygon data representing the shape and alter it however you need.

I do this often with ~100 bodies and have had no performance issues so far.

Edit: Bummzack is correct. However, after a bit of Googling about, if you call ResetMassData() and then relocate the box to its current rotation/position both the AABB and Mass data will be recalculated. Probably still faster and more flexible than swapping out new fixtures constantly.

Body.SetTransform(Body.Position, Body.Rotation);

Example manipulation of verts. Remember that they are represented in local space around the position of the body.

var poly1 = (PolygonShape)Body.FixtureList[0].Shape;
var poly2 = (PolygonShape)Body.FixtureList[1].Shape;

poly1.Vertices[0] = End + perpNormal - center + normal;
poly1.Vertices[1] = End - perpNormal - center + normal;
poly1.Vertices[2] = Start + perpNormal - center - normal;

poly2.Vertices[0] = Start + perpNormal - center - normal;
poly2.Vertices[1] = Start - perpNormal - center - normal;
poly2.Vertices[2] = End - perpNormal - center + normal;
  • \$\begingroup\$ You shouldn't do that, as physics properties will no longer be correct (eg. mass, center of mass, etc.). The "correct" way would be to define shapes for each frame and then add/remove them to the world when required. \$\endgroup\$
    – bummzack
    Feb 14, 2012 at 8:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .