# Getting Bodies to go “Super Fast” in Box2D

I am making a breakout game in Android using the LibGDX version of Box2D. I have a ball that I am applying a force to with the following code...

getBody().applyForceToCenter(-10000000000.0f, -10000000000.0f);


This makes the ball move properly, but it never seems to gain a lot of speed (and I want to make it go super fast). I tried adding an accelerate method where I applied the force 40 times, but again it doesn't seem to move that fast. What is a good way to make a Body go "Super fast" in Box2D?

If there is acceleration I would like it to be as short as possible.

World.setVelocityThreshold(1000000.0f);


But now the ball doesn't seem to "bounce" off walls, do I need to raise my restitution or something?

• there is an speed limit somewhere in the box2d configurations which you might alter. But in their manual, they indicated that max speed should not be very large. check this question – Ali1S232 Jan 23 '13 at 16:54
• Any idea where the maxTranslation is in LibGDX? – Jackie Jan 23 '13 at 16:58
• I've got no idea even what libGDX is but a google search pointed me towards this – Ali1S232 Jan 23 '13 at 17:03
• Nice thats exactly what I was looking for let me check it out (BTW LibGDX is a game engine for android that comes with a jni "wrapped" version of Box2D – Jackie Jan 23 '13 at 17:05
• Box2D is designed for static scenes (as in nothing removed or created, movement is fine) and realistic simulations. Using it for something like breakout may very well be more complicated than creating your own very simple physics engine. – ClassicThunder Jan 23 '13 at 18:16

Tried also to create a breakout clone, but stopped for now, for some other reasons... anyway this is what I learned so far, during development.

1. Use Meters instead of Pixels, Box2D uses MKS (meters, kilograms, and seconds) so when you have a Viewport of e.g. 1280x720 , this would be a length 1,28km. Then your Ball must have an outrageous speed to be "fast" in this long distance. Better use meters e.g. 50x20 (or something like that) => http://box2d.org/2011/12/pixels/
2. If you don't use Meters, but a higher BOX_STEP (e.g. 1/500f) and more BOX_VELOCITY_ITERATIONS during each render()-call, then you can speed up on a Desktop, but on Android it just gets down to 3FPS which isn't really "fast".
3. "Fix your timestep" => http://gafferongames.com/game-physics/fix-your-timestep/ (for this there are some other Stackoverflow Entries, which currently couldn't find)

The TL;DR-Version: Use Meters instead Pixels, then you don't have to use such an high force / velocity, and it will be fast on android and desktop.

Best Regards and hoping this helped a bit

• Thanks I will try these and give you the check in a bit! – Jackie Jan 24 '13 at 15:12

I see that there is already an accepted answer to this question. While it is in my opinion a helpful answer, it is not an answer to the original question of how to get bodies to go "super fast" and it does not address the use of setVelocityThreshold.

Regarding the question of how to make bodies go "super fast"...

There are two parts to understand for making bodies go faster:

1. The obvious: give the body a "super fast" velocity by one of the ways recognized. I.e. by applying the force/impulse/velocity necessary for the body to go as fast as needed.
2. There is a maximum translation setting(s) (b2_maxTranslation and b2_maxTranslationSquared) that puts an upper bound on how fast any body will actually go per time step. This limit is not in meters per second but in meters per time step. So at world steps of 1/60th of a second, a max translation of 2, is 120 meters per second.

As for part two of how to make bodies go super fast, given that the maximum translation amounts are per time step, one can either increase the steps per second (and say do world steps of 1/120th of a second instead of 1/60th of a second), or increase these maximums. With increasing these maximums however, note that there's a comment from the C++ sources for Box2D on GitHub which says:

The maximum linear velocity of a body. This limit is very large and is used to prevent numerical problems. You shouldn't need to adjust this.

Based on my experimenting with this setting in my own fork of Box2D where I've updated the Testbed to allow per-step configuration of things like the max translation amount, I can elaborate on this comment.

Within the suggested size ranges for Box2D, a maximum translation setting of 4 looked okay with a frame rate of 60 frames a second. As one increases the body's speed and the max translation that it's capped at, the image visually appears more jumpy as it moves across the screen. Short of increasing the frame rate and decreasing the per-step time simulated, jumpier and jumpier is how it will appear to anyone as the body's speed goes faster. Eventually a fast enough body won't show up on more than a single frame (if at all). A single frame of course can't make a body look like it moved at all - just that it suddenly appeared and disappeared in a single spot.

Insofar as numerical problems are concerned, there are always numerical problems when using limited-precission floating point arithmetic as Box2D does and other physics engines also do. It's whether or not the numerical problems are visually noticeable that's the bar, practically speaking, that we can be concerned with.

From this perspective, as speed is increased the visually apparent problems that I'd expect to increasingly occur are:

• Unexpected tunneling (even with bullet enabled or in collisions with static bodies).
• Having to go beyond the ranges that Box2D is "tuned" for and causing everything to need to be reconsidered from a scaling and visualization perspective.

Numerical problems is an area that I continue to look into with interest however.

Here's a relevant excerpt from the Box2D 2.3.2 manual regarding the library's tuning:

In particular, Box2D has been tuned to work well with moving shapes between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well. Static shapes may be up to 50 meters long without trouble.

Regarding using setVelocityThreshold...

The velocity threshold has to do with the minimum speed a body has to be moving in order for the physics engine to have it bounce off of other bodies that it collides with; not with a maximum speed that bodies can go.

The comment for the velocity threshold settings reads as follows:

A velocity threshold for elastic collisions. Any collision with a relative linear velocity below this threshold will be treated as inelastic.