News Mar 20: R.U.B.E v1.7 released. Instanciable objects!
Feb 21: Added RUBE sample loader for Cocos2d-X v3.4.
Feb 17: Funny Fists released in iOS App store and Google Play store. (YouTube video)
May 25: R.U.B.E v1.6 released. Samplers!
May 12: "On-the-fly" resource updating for Cocos2d-x
Apr 22: New blog post: Inverted pendulum control
Apr 7: On-screen logging class for Cocos2d-x
Mar 22: Downhill Supreme 2 released for iOS and Android
Jan 2: YouTube video: Making soft-body wheels in RUBE
Oct 6: Check out Supplyfront RTS, my 7dRTS entry continued.
Sep 26: R.U.B.E v1.5 released. Customizable item labels, snap-to-grid, export filtering, full-text help search.
Sep 18: Added RUBE sample loader for Cocos2d-X.
Sep 16: Updated RUBE sample loader for Cocos2d v2.
Aug 12: RUBE loader for Nape by Zeh Fernando
Aug 7: Added RUBE sample loader for SFML.
Jul 30: Try my MiniLD 7dRTS entry.
Jul 24: Added physics-driven particles tutorial.
Jul 20: New blog post: rendering solid ground (as in Downhill Supreme)
Jul 18: R.U.B.E v1.4 released. Command-line interface for batch jobs, hotkeys for scripts, better script management.
May 22: Downhill Supreme is out now! (iOS)
Apr 2: R.U.B.E v1.3 released. Collision bitplane editing, Cocos2d-iphone loader, usability improvements.
Mar 11: R.U.B.E v1.2 released. Now supports weld, friction, motor joints and automatic image reloading.
Mar 10: RUBE loader for libGDX by Tim Scott
Jan 28: New blog post: a functional combustion engine!
Jan 22: New blog post: wind tunnel
Jan 20: Added explosions tutorial.
Jan 16: Added buoyancy tutorial.
Jan 16: AndEngine sample project to load RUBE scene by Bart Hirst
Jan 14: R.U.B.E v1.1 released, now supports custom properties.
Jan 1: All basic tutorials are now available in Chinese at Huge thankyou to @OhCoder!
Dec 23: Discussion forums have been set up
Dec 4: R.U.B.E v1.0 is ready !
Dec 2: YouTube video: Box2D pendulum clock
Nov 26: New blog post: rocket platform thingy
Nov 25: Video of R.U.B.E scenes in Chipmunk.
Nov 23: A sample project to load R.U.B.E scenes into Chipmunk physics! Details here.
Nov 14: An XCode sample project to load R.U.B.E scenes on iOS is now available. Details here.
Nov 11: A Java version of b2dJson is now available, based on JBox2D.
Nov 6: A Javascript version of b2dJson based on box2dweb is now available. Demo here!
Nov 2: The full specification of the JSON format used by b2dJson can be found here: b2dJson file structure
Oct 28: YouTube video: 2-minute ragdoll in R.U.B.E Box2D editor
Sep 29: YouTube video: R.U.B.E Box2D editor usage example

Box2D C++ tutorials - Removing bodies safely

Last edited: July 14 2013

Chinese version -> 中文

Removing bodies safely

Unless you are making a very basic game, you will probably want to remove some bodies from the scene at some point. This could be for example if the player kills an enemy, the bullets they fire need to be cleaned up, or two objects collide and one breaks, etc. The actual code to remove a body is dead simple - you just say world->DestroyBody(b2Body*), and if you are removing the body outside the timestep that's all there is to it. The problem comes when you want to remove a body as a result of something that happened within a timestep, usually a collision callback. If we remind ourselves of the timing of collision callbacks, we see that we cannot remove a body inside a collision callback, because the world is right in the middle of performing a physics step, and removing the data it is working with is a bad idea. Removing bodies safely A very similar situation is encountered if you use threads or timers to remove bodies, for example if you want a body to be removed a few seconds after some event in the game. If the timer fires while the world is stepping, this can also cause problems.

The solution to this is quite simple. When you get a collision callback which means a body should be removed, just add the body to a list of bodies scheduled for removal, and remove them all together after the time step has finished.


As an example, let's set up a demonstration where bodies will be removed from the scene at runtime depending on the collisions between them. We will bring back the friendly smiley faces from the collision callbacks topic to help us with this. In fact, we can pick up right where we left off at the end of that topic. To recap, we had a situation where one ball was red, and when it bounced against another ball the red state would swap between them as if they were playing tag and the red ball was 'it': Removing bodies safely This time, lets imagine that the red ball has caught a deadly virus and is about to die, but not until it has infected one other ball first. As soon as the virus has been passed to another ball by a collision, the first ball with the virus will be removed from the world.

There are only a few small changes we need to make to accomplish this. We'll need a list to store the bodies to remove from the world after the timestep, and the collision callback should be changed to put the already infected ball into that list. To actually delete a ball properly we should add a destructor to the Ball class and inside it, we will remove the physics body from the Box2D world.
  //at global scope
  std::set<Ball*> ballsScheduledForRemoval;
  //revised handleContact function
  void handleContact( Ball* b1, Ball* b2 ) {
    if ( ! outbreak )
    if ( b1->m_imIt ) {
        b2->m_imIt = true;
    else if ( b2->m_imIt ) {
        b1->m_imIt = true;
  //implement Ball class destructor
    m_body->GetWorld()->DestroyBody( m_body );
The 'outbreak' variable is optional, I just added this as a global variable initially set to false so that I can use the Keyboard function to start the infection spreading when I choose - otherwise the balls are too bunched up in the beginning and most of them get infected and die in the blink of an eye which is no fun. You could also just space them out more to start with I guess, it's up to you.

Now in the Step() function, after calling Test::Step() and before rendering the scene, we'll need to process the entities that got scheduled for removal.
  //process list for deletion
  std::set<Ball*>::iterator it = ballsScheduledForRemoval.begin();
  std::set<Ball*>::iterator end = ballsScheduledForRemoval.end();
  for (; it!=end; ++it) {
      Ball* dyingBall = *it;
      //delete ball... physics body is destroyed here
      delete dyingBall;
      //... and remove it from main list of balls
      std::vector<Ball*>::iterator it = std::find(balls.begin(), balls.end(), dyingBall);
      if ( it != balls.end() )
          balls.erase( it );
  //clear this list for next time
Now you should see just one red ball in the scene, infecting another ball and dying when it collides with it.

Dealing with the removal bodies as a result of a thread or timing routine is very similar, just gather all the bodies to be deleted in a list, and deal with them when you can be sure that the world is not stepping. One simple method for implementing a 'timed removal', that is for example if you want to wait a certain time before deleting something, is just to calculate how many time steps that would be for your game loop (eg. 2 seconds is 120 time steps at 60fps), set that value in the entity and then decrement it every frame until it gets to zero, then remove it.

By the way, although this topic has focused on removing bodies since that is the most common case to cause problems, the creation of new bodies, and the creation and removal of fixtures must be dealt with in the same way.