(from the manual:)

“Box2D works with floating point numbers, so some tolerances have to be used to make Box2D perform well. These tolerance have been tuned to work well with meters-kilogram-second (MKS) units. In particular, Box2D has been tuned to work well with moving objects between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well.”

“Being a 2D physics engine it is tempting to use pixels as your units. Unfortunately this will lead to a poor simulation and possibly weird behavior. An object of length 200 pixels would be seen by Box2D as the size of a 45 story building. Imagine trying to simulate the movement of a high-rise building with an engine that is tuned to simulate ragdolls and barrels. It isn’t pretty.”

I think if you’re using code from the TestBed or HelloWorld as a base for your examples you are going to see 30-pixel units. I think this is a legacy situation and not something that is built into the engine. I have not seen this for the code I’ve written where all the 30x multipliers have been removed, although it just may be that I haven’t hit that instance yet. I have been very confused by the references to “meters” in the code comments (and the random multipliers in the HelloWorld example), but nothing I’ve seen seems to suggest that they are in anything but pixels.

In the TestBed Test.as, you have the following line:

dbgDraw.m_drawScale = 30.0

which again suggests that everything is getting scaled.

You’ll see that the HelloWorld userData sprite width and height gets multiplied by 30 on lines 71 and 72 of HelloWorld.as

Now, I’m willing to submit that this is because it makes it simpler to work with meter measurements that exist elsewhere in the engine, but my code hasn’t shown this to be true.

I also just grep-ed the engine source files and found only two mentions of the number 30 — both in comments, neither in any statements, which again suggests that the Box2D flash version defaults to pixels, or at the least does not have any 30xPixel measurement. Still I’ll admit haven’t done enough digging to see that this is truly the case. I’d love to see a definitive answer on this, though, if there are measurements in Box2D that are taking unusual units, it’d probably save me a lot of frustration if I knew about them.

In the helloWorld update loop you have this happening:

bb.m_userData.x = bb.GetPosition().x * 30;
bb.m_userData.y = bb.GetPosition().y * 30;

which suggests to me that the coords are getting multiplied by a factor of 30. When I did my own loop, I removed the *30 and otherwise kept the stanza the same, and got pixel based units.

In the helloWorld and Test bed when setting the width and height of userData property its in pixels but everything else is in meters. This is because userData provides access to the actual Sprite or MC in the userData.

The testbed and helloWorld Sprites are all scaled 30x, for some reason — is this what you’re thinking of?

I can’t find confirmation about this (the AS3 Box2D port has pretty limited documentation, as you know), but searching around, I think here’s what might be the situation:

*Box2D used meters until version 1.4.3, then switched to pixels (might it have switched back? not sure!)
* Instead of rewriting the demo and testbed, the code was modified so it still worked (ie, everything was multiplied by 30). I think this is likely because you can see other places in the demo where old code has simply been commented out as the engine has been updated (for example, it’s clear that the debugDraw stuff used to be done ‘by hand’, until the engine was able to internalize it — that code is still in the testbed, just commented out). This would actually explain something that has been confusing me for awhile — why the demos scale everything by 30!

If someone knows, please correct me if I’m wrong on this. Thanks!

BTW, great info in these blog posts about Box2D! Thanks for taking the time to make them.