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:
- 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.
- 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.
Hope this answer adds usefully from what's already been accepted as the answer.
