This is an excerpt taken from my OneNote page regarding Box2D. If anything, it shows that I took a lengthy hiatus from this library and I wanted to get back into using it. However I hit the same wall I hit before which was determining a sane pixel-to-meter scalar which is required for a proper implementation. Also, it clearly outlines that I’m not a physicist in any way and that I write in a very wordy manner.


Something that I’ve always had trouble with regarding the usage of this library is the scalar for pixels-to-meters. The official notes from the library developer state that it’s really dependent upon the game as to what value this scalar should be. However that response always struck me as odd; why should this value be so volatile as to not have some standard that works for a majority of cases so that you can at least get started using it? I always thought there would have to be some common expression of this scalar that could be applied to any rigid body in a simulation unit. As it turns out, there may be one although I’ve only been able to catch glimpses of it here and there on the internet.

One site in particular, run by an Italian ActionScript developer, makes a claim of an “unwritten rule” that 1m is equivalent to roughly 30px. ( I have seen this claim on a few other fringe sites that have appeared in the recesses of Google searches however there has been nothing that has substantiated this claim by any leading developers or physicists who use this library for simulation purposes.

The core of the issue stems from the units that Box2D uses to express rigid bodies. Relying on the MKS (meter-kilometer-second) system, a 1/1 ratio between meter and pixel doesn’t exist. Knowing that the conversion factor of a meter to a foot is 1/3.28, if a 1/1 ratio between pixels and meters existed, a 320px X 64px image would be 320m X 64m (1049.6ft X 209.92ft) which would most likely not translate to a real-world object that we would want to exist in the simulation.  Furthermore, the force that would need to be applied to that body to get it to move, assuming it were a non-static body, would be immense.

There is a small paragraph on the official wiki for Box2D which is effectively a FAQ. One of the questions is as follows:


There are a few things to take into consideration while reading this example:

  • The scalar chosen in the example (0.01) appears to be entirely arbitrary. There is no real rhyme or reason as to why it was used instead of another arbitrary scalar like 0.25.
  • The scalar is applied not only to the dimensions of the sprite (measured 100px X 100px thus making its rigid body representation 1m X 1m (100 * 0.01)), but also to the coordinate system as well in order to accurately reflect the body’s relative location. In the example, the sprite starts at Pixel Coordinates (345, 679). To Box2D, and based on the chosen scalar, it would actually be located at (3.45, 6.79) as a result of ((345 * 0.01), (679 * 0.01)). Upon moving, the sprite is then located at (2.31, 4.98) in Box2D Coordinates. The translation to Pixel Coordinates requires the inverse operation of the scalar applied ((2.31 / 0.01), (4.98 / 0.01)) which would place the sprite at (231, 498) in Pixel Coordinates.
  • The example clearly does not state or even remotely lean to an “unwritten rule” that would be indicative of the 1m/30px ratio. Instead it leaves it up to the reader’s interpretation as to what the scalar should be.

Clearly there will have to be some investigation as to what would work well. The information that I’ve been able to find here should be sufficient enough to get started with a simulation to play with.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s